struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Roughley <...@fdar.com>
Subject Re: [Friday] GWT/Struts - does it make sense?
Date Wed, 28 Jun 2006 00:50:22 GMT
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 <ian@fdar.com> 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     ian@fdar.com
>> phone:    617.821.5430
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>
>>
>> Michael Jouravlev wrote:
>> >> From another thread:
>> >
>> > On 6/23/06, Sean Schofield <sean.schofield@gmail.com> 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: dev-unsubscribe@struts.apache.org
>> > For additional commands, e-mail: dev-help@struts.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message