struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Roughley <>
Subject Re: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
Date Thu, 25 May 2006 17:59:49 GMT

Brian Dittmer wrote:
> Ian Roughley wrote:
>> So, you are saying that your preference would be to include no ajax 
>> integration and leave the framework and let users integrate this as 
>> required - either directly in the HTML or by creating custom themes?
>> /Ian
> No, I definitely would love to see ajax support...I just think it 
> needs to be done right.  Integrating DWR looks like it might get a bit 
> messy.  Taking ideas from DWR, maybe even some of the code and/or the 
> js libs, and building the support directly into SAF2 would be a better 
> option.  That way the look and feel of writing ajax enabled actions is 
> the same as writing other actions.  
But this IS the goal.  The action will be exactly the same as writing 
non-ajax called actions - the data may potentially be populated 
> This keeps the SAF2 code simple (e.g. you don't need to worry about 
> the glue holding together SAF2 and DWR breaking when a new version of 
> DWR comes out, developers don't need to jump between the DWR codebase 
> and SAF2 codebase) 
We will use DWR under-the-covers to provide the glue - it is mentioned 
here only because it is the dev list and those on the list are most 
likely interested in the enabling technology. The problem found with 
using dojo is that the user is pulled into the dojo source, and way too 
often.  I'm not sure that re-inventing the wheel is a good idea, but we 
will control the integration and upgrades to DWR and work closely with 
Joe to ensure that the are no issues with releases.
> and will be easier for users when configuring their apps (everything 
> is configured in xwork.xml or annotations, no dwr.xml, no servlet 
> extra config in web.xml, etc.).  
This is also the case - my reading the package/action configuration 
there is NO additional DWR configuration on a per action case.  There 
may be an additional web.xml servlet entry, but I think this is acceptable.
> That's just my two cents, I know it's kind of reinventing the wheel 
> but I think it would definitely pay off in the end.
> Brian
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message