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.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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: [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]
