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]

Reply via email to