You can use GWT standalone, but it also makes sense to use it for rich components embedded in a normal web page. For example, you could use it to implement an AJAX table component which can sort columns and page-by-page iterate.
As for using XWork on the server side, I personally wouldn't do it because I like type checking and dislike XML. Bob On 6/27/06, Ian Roughley <[EMAIL PROTECTED]> wrote:
Martin - I think we are saying the same thing - and I think you confirm this in your last paragraph. Rather than web frameworks, using GWT I think developers are more likely to integrate directly with XWork (as a generic command infrastructure, rather than a web front controller), Spring or the business logic directly. This avoids adding abstraction layers to the design/architecture that don't contribute anything useful in the way of functionality. /Ian Martin Cooper wrote: > On 6/23/06, Ian Roughley <[EMAIL PROTECTED]> wrote: >> >> I have been thinking about this a lot lately, and I would say that GWT >> is more likely to replace web frameworks than work with them. > > > I wouldn't phrase it quite like that. It's more like AJAX in general > changes > the way in which we build the server side of web apps, and GWT > demonstrates > that more dramatically than many people have seen before. > > If you really buy into the AJAX way of building web apps (i.e. not just > adding tweaky bits to existing apps), then the most dramatic change is > that > you find yourself writing very little server side code. (I'm not talking > about the "business logic" here, only what sits on top of it.) Once > you have > something in place that deserialises requests and serialises responses > (which GWT provides with their RemoteServiceServlet), then almost all you > have left to do is implement CRUD operations on top of the business > logic. > > At my last company (meaning up until a week ago), perhaps only 10% of the > code we wrote for our newest app is server side Java code. I did put > Struts > 1.3 in place early on, but we ended up with exactly two action > mappings for > the entire app. (We have two only because we're using two different > client-side technologies; one mapping would be the norm.) > > As for using Struts with GWT, I'm not sure that I see the point. You > could, > yes, but why would you? You'd either have to provide your own code to > do all > of what their RemoteServiceServlet does, or you'd have to futz with the > client side code so that it doesn't use it, and basically reinvent the > way > in which RemoteServiceServlet works anyway. On the surface, that might > not > seem so hard, but if Google has done its job properly, there's a lot > more to > it that there might appear. > > -- > Martin Cooper > > > /Ian >> >> -- >> From Down & Around, Inc. >> Innovative IT Solutions >> Software Architecture * Design * Development >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> web: www.fdar.com >> email [EMAIL PROTECTED] >> phone: 617.821.5430 >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> >> >> Michael Jouravlev wrote: >> >> From another thread: >> > >> > On 6/23/06, Sean Schofield <[EMAIL PROTECTED]> wrote: >> >> JSF is a major shift in the way we've been doing things. >> >> It will take a while for everyone to understand JSF enough >> >> before they are ready for Shale. >> > >> > I think that it should not be too complex to combine GWT front end >> > with Struts backend. I haven't tried it yet but does it really matter, >> > pure servlet or Struts Action, it is just a URL after all. GWT is new >> > and fun, yet it might allow to reuse existing skills if not code. >> > Struts would be used for server-side validation, model/database >> > access/update, state management. >> > >> > Looking into Ajax future I think that from both developer and user >> > perspective GWT/Struts can be a sensible option for rich web >> > applications in comparison with JSF/Shale/ICEFaces/whatnot. Opinions? >> > >> > I know, I know, "It is up to you to make it happen" ;-) >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
