Regarding the i18n issue, we have the following problem: We have one average sized application which we deploy many times.
For every deployment, labels and other i18n related information changes. For every installation we have to go through a re-build. Even worse, today an installation uses only English, tomorrow it might have French (when I have the translation) and a few months down the road Spanish.. A recompile, and a re-install is required every time.. Spring MVC, has a very nice way to handle this: Just put the properties file in a specific directory and everything works more or less ok... You want a specific installation to have different labels/messages? Just change this specific installation.. So IMHO there is need for server side i18n in GWT. I was actually wondering if there is an implementation around, and if not, if someone would care to start such a project... The only drawback I have found so far, for such an implementation is that you either have to use sync RPC to load and block while loading, OR you have to load all your messages in you host page (like Dictionary does it), to have all messages available when running the app.. The last approach is somewhat safer, faster but it does require that you load ALL your messages beforehand... On Mon, May 24, 2010 at 6:13 PM, Stefan Bachert <[email protected]>wrote: > Hi, > > I don't use Spring MVC AND GWT in one project. What I have tried to > express is that my concept of MVC especially the controller differs > from that what Spring MVC is considering MVC. > (My MVC: C->M->V (and a weak C->V as performance short cut), Spring > MVC V<->C<->M) > > Any way, I disadvice to mix GWT and Spring MVC in one project. > When you need a RIA for user input use GWT. > When you need a search engine friendly set of documents (i am > hesitating to use the term "application") use JSP with Spring MVC. > Both can access the same model / domain objects and may run on the > same server (farm) > And both have their own way to deal with i18n. > > Stefan Bachert > http://gwtworld.de > > On 24 Mai, 15:11, dmen <[email protected]> wrote: > > Hi Stefan, > > By coincidence I use Spring MVC along with GWT. Spring controllers do > > not have to handle business logic. > > For example in my current app I have the following architecture: > > > > Model: Domain + Services > > View: GWT + JSP (i18n and other stuff) > > Controller: GWT event handlers (client) <-> Spring MVC controllers > > (server) > > > > Like VladS said, you can't abstract the i18n aspect completely from > > the server. Besides that, my point was that > > compiling the whole code base per browser * locale, just doesn't feel > > right. So why not do the whole thing > > in one place and more efficiently? :) > > > > On May 23, 6:00 pm, Stefan Bachert <[email protected]> wrote: > > > > > > > > > Hi, > > > > > I do not agree with you. > > > > > First of all, my concept of an application is the "ingenious" variant > > > of MVC. In the ingenious variant "control" means taking users input > > > (That is not the same role as Spring Web MVC perceives a Controller > > > where Controller means marshalling and doing business logic. The first > > > is trivial, the second is just wrong). However, regarding to your > > > topic this difference is not really important. > > > > > Control is user input, gathering data > > > View is presentation of data for the user > > > Model is/are the domain object(s) > > > > > Control and View live on the client > > > Model live on the server. > > > > > So for me i18n is in general a pure presentation affair which belongs > > > to the client. It is the client how decides which language is > > > appropriate, not the server. > > > In my application view server side is heavily related with the domain > > > object, and they do in general not depend in users locale. > > > > > So it is perfectly OK to apply i18n on the client. And this approach > > > is quite fast. > > > > > On the other hand, you don't have to use the GWT i18n mechanism at > > > all. > > > And you could use the Constants-Interface and implement it by a class > > > which ask the server for values. This might be appropriate when you > > > for some reason are not able to supply stable translations of your > > > labels and titles. However, your application startup will slow down. > > > > > Stefan Bacherthttp://gwtworld.de > > > > > On 23 Mai, 04:46, dmen <[email protected]> wrote: > > > > > > I wanted to start a discussion about this as I usually get this ugly > > > > feeling when ever I take on GWT i18n . To begin with, I believe that > > > > internationalization is, inherently, a server side issue, so solving > > > > it on the client is the wrong way to do it. Moreover, the way it is > > > > done, by compiling the whole app separately per browser and per > > > > locale, screams overkill. In general, I think that GWT's feature of > > > > deferred binding should be used with more chariness than it currently > > > > is. What do you think? > > > > > > -- > > > > You received this message because you are subscribed to the Google > Groups "Google Web Toolkit" group. > > > > To post to this group, send email to > [email protected]. > > > > To unsubscribe from this group, send email to > [email protected]<google-web-toolkit%[email protected]> > . > > > > For more options, visit this group athttp:// > groups.google.com/group/google-web-toolkit?hl=en. > > > > > -- > > > You received this message because you are subscribed to the Google > Groups "Google Web Toolkit" group. > > > To post to this group, send email to > [email protected]. > > > To unsubscribe from this group, send email to > [email protected]<google-web-toolkit%[email protected]> > . > > > For more options, visit this group athttp:// > groups.google.com/group/google-web-toolkit?hl=en. > > > > -- > > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > > To post to this group, send email to [email protected] > . > > To unsubscribe from this group, send email to > [email protected]<google-web-toolkit%[email protected]> > . > > For more options, visit this group athttp:// > groups.google.com/group/google-web-toolkit?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<google-web-toolkit%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
