Not specifically, no... although, both of my books go into this sort of
thing, and the first one includes a DWR-based project.
I'm also in the midst of a third book which will very definitely cover
this topic in detail right lots of practical examples... due out in,
roughly, this coming January.
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.comAIM/Yahoo: fzammetti
MSN:
fzammetti@...
Author of "Practical Ajax Projects With Java Technology"
(2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
(2007, Apress, ISBN 1-59059-816-4)
Java Web Parts -
http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it!
On Wed, August 8, 2007 12:58 pm, Asthana, Rahul wrote:
> Hi Ted/Frank,
> Is there a more detailed post/article that you have done regarding this
> architecture?
> Thanks
> Rahul
>
> -----Original Message-----
> From:
ted.husted@... [mailto:
ted.husted@...]On Behalf Of Ted
> Husted
> Sent: Wednesday, August 08, 2007 12:27 PM
> To: Struts Users Mailing List
> Subject: Re: struts1 or struts 2?
>
>
> On 8/7/07, Frank W. Zammetti <
fzlists@...> wrote:
>> Then again, if I *really* had my druthers, I'd use DWR for everything on
>> the back-end and pick best-of-breed widgets on the UI to construct my
>> own
>> client-side framework... the last project I did more or less did this,
>> although we used S1 and not DWR, but it worked out tremendously well, so
>> in my mind the approach is more than sound, it's close to ideal...
>> standard enough that a decent developer can get up to speed quick, but
>> custom enough to fit the problem domain like a glove.
>
> +1
>
> My team did our last project using the same sort of architecture, but
> since the backend was on .NET, we used Jayrock instead of DWR. Works
> great, and it also seems like the ideal mix to me. We had to roll our
> own solution for the server-side validation and type conversion, but
> we based that work on a chain of command, and it's layered so we can
> reuse it with multiple front end applications.
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
user-unsubscribe@...
> For additional commands, e-mail:
user-help@...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
user-unsubscribe@...
> For additional commands, e-mail:
user-help@...
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail:
user-unsubscribe@...
For additional commands, e-mail:
user-help@...