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]. > > > 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]. > > 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]. > 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]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
