Announcement Announcement Module
Collapse
No announcement yet.
i18n and the database, multiLocale object, AOP proxy? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • i18n and the database, multiLocale object, AOP proxy?

    I am not sure if this is the right place to discuss this since it is kind of AOP related, but I'll give it a try anyway.

    We have a multi language web application. It is using Hibernate for the mapping with the db and Spring to manage it.
    Our database design is the following: any language sensitive entitiy X has a dependent entity (let's call it Xdetail) containing a record per language supported in the application. (I wish I'd be an expert in ASCII art and could draw the model... ). It is arguably the most flexible design, especially if you plan on supporting more languages in the future. It's also a pretty cumbersome one to work with.
    As for the Java layer, those language dependent entities are mapped to business object like this. object X has a map of Xdetail object indexed by Locale. (Map<Locale, XDetail>). This is pretty neat but not easy to play with.

    To access the name property of a language sensitive X object, you'd do the following: X.getXDetail().get(Locale.ENGLISH).getName(). I don't even want to mention creation of such an object...

    Nevertheless, I still quite like the database design here. And I don't see any better mapping than this Map. So what can I do to simplify language sensitive object access?

    My idea would be to create a proxy that would use the session or database stored User Locale preference to return or set the right language detail of a property upon access to a getter/setter method.
    AOP seems particularly adapted for that matter. I'm only a novice in manipulating the concepts of Advice and Pointcut and particularly as for their implementation in Spring.

    What I imagine is the following:
    A proxy for any language sensitive Detail object would need to be dynamically generated. Every call to 'get*' and 'set*' on this proxy would be resolved through a Locale preference (say from Session) to the appropriate Detail instance.

    My question would be am I dreaming here or something like this is really possible? That would avoid manually creating a Proxy class for each of those language sensitive objects.
    And what would be a possible implementation using Spring AOP???

    cheers,
    Jean

  • #2
    Would this work?
    Code:
    public class X {
      public String getName(Locale locale) {
        return getXDetails().get(locale).getName();
      }
    }
    Or if you don't mind binding the current user's locale to the thread local, it can be eliminated from the getName signature, and name becomes a normal bean property.

    Comment


    • #3
      Hello Jing Xue, thanks for the answer. This would work pretty well of course. But I'd rather find an elegant, generic way of solving this issue.
      The goal would precisely be to avoid manually implementing getters and setters for detail objects. All the more since those are Hibernate generated objects.

      Since we have quite a lot of those language sensitive entities, I believe an advice on that kind of object would be the perfect solution.
      I knew I would have to go through the Spring manual AOP section one day...

      Comment


      • #4
        Jean, I see, yeah, it'd be a pain to manually implement each accessor if you have a lot o them.

        My only concern with an AOP-based approach is that there might be too much magic in it, as in this case these objects have to be adviced for them to make any sense - versus in most cases advices are more likely "optional" layers of concerns on top of some core logic.

        That being said, the "magic tolerance threshold" is subjective, so if you don't mind the concern, AOP does appear to be an elegant solution. I would actually suggest using aspecj instead of Spring AOP, because proxying a lot of domain objects isn't likely going to be very performant. The aspectj aspects can still have first-class wiring support from Spring 2.0, so integration wouldn't be a big issue at all.

        Comment


        • #5
          Hi Jing Xue.

          thanks for your wise advices and sorry for late reply.
          I glad to know that AOP could be an elegant solutions.
          I knew already it was possible to use Aspectj in Spring.
          I gave it a try, but I'm definitely to much of a novice in that field to assess my 'magic tolerance level'.
          I hope I'll find the time to study and implement something, that seems to be a good case where AOP is useful.

          btw, if you don't mind the personal question: your name seems to indicate that your are Chinese. Is that a correct guess? I myself live in Beijing.

          Best,
          Jean

          Comment


          • #6
            Originally posted by Jean View Post
            btw, if you don't mind the personal question: your name seems to indicate that your are Chinese. Is that a correct guess? I myself live in Beijing.
            I am originally from Beijing. Good luck on your project.

            Comment

            Working...
            X