Re: Cayenne in i18n applications

From: Cris Daniluk (cris.danilu..mail.com)
Date: Mon Dec 19 2005 - 08:46:21 EST

  • Next message: Gentry, Michael \(Contractor\): "RE: Looks and Feels?"

    Rather than rely on reflection, you should make a news_translation
    table that keys off of a third language table, whose pk corresponds to
    the locale key. You can then use a method similar to Java's
    ResourceBundle locator to find the appropriate language - I usually
    shove it in the user's session so its only done once.

    Change the news and news_translation tables to inherit from some
    common translatable and translation root and voila... you can abstract
    your translation entirely.

    In fact, we go a step further and put the language into a ThreadLocal.
    A simple getTranslatedValue() method on the TranslatableEntity root
    and not only is translation abstracted, but you don't even realize its
    happening in your code.

    By the way... one "quirk" of this design is that there is no "default"
    translation. We have a lot of tables that end up being nothing more
    than a pk, as a stub reference to the translation tables that contain
    all the data. You would have to relocate the English translations to
    the news_translation table for it to make any sense.

    To contrast it to the reflection example you gave, I would say the
    overview I gave is more flexible. With the reflection strategy, you
    are going to find it difficult to add new languages because each one
    requires a modeler change. You were worried about a code change, so I
    think a modeler change deserves equal consideration. The other thing
    is that I would consider what you are doing a bit of a hack, diverting
    Cayenne's design, as opposed to this method which embraces it (you can
    do similar things in Hibernate, etc, but its not nearly as seemless
    and cool).. though even as a hack, I expect it to continue working for
    a long time, as readProperty is a pretty stable method :)

    Cris

    On 12/19/05, Gary Jarrel <garyjarre..mail.com> wrote:
    > Hi All!
    >
    > I need to use Cayenne for a multi-lingual application that I'm
    > currently working on.
    >
    > My main concern was to come up with a way to be able to get data from
    > the DB without explicitely stating that the translated data should
    > come from a different tables.
    >
    > For example I've got two tables news and news_ru. I wanted to have a
    > system whereby the user sets the locale when he/she enters the site,
    > and the respected data is retrieved automatically.
    >
    > So I've come up with a small framework that works. I've used a
    > one-to-one relationship from news to news_ru table, assuming that
    > there will ever be one or none Russian translation for any given
    > record in the news table.
    >
    > I've then overrode the readProperty method of the DataObject in what I
    > called LocalAwareCayenneDataObject. So the News object extends the
    > LocalAwareCayenneDataObject, while the NewsRu extends DataObject. If I
    > retrieve a news entry from the DB, hence I have News object, then I
    > call a getBody method (body field in the database) the system checks
    > whether there is a predefined Locale associated with a thread. In case
    > there is a Ru locale it will actually return a value in Russian from
    > the news_ru table.
    >
    > Basically it uses reflection to find whether there is a method that
    > returns NewsRu and if so it then checks whether there is a body field
    > in the news_ru DbEntity, and if so returns that instead of the English
    > translation which normally lives in the news table.
    >
    > Now this seems to work really well, under my "ideal" test cases :)
    > however in overriding the readProperty method, I'm wondering what
    > implications this may have have on Cayenne functionality, what else
    > should I be testing for?
    >
    > Thanks in advance
    >
    > Gary
    >



    This archive was generated by hypermail 2.0.0 : Mon Dec 19 2005 - 08:46:23 EST