the way my client side api would expect to see that data would be like so. <proxy-object> <class-object name="java.lang.String"> <accountHolders> <accountHolder> <firstName>Frank</firstName> <lastName>Zammetti</lastName> <accountBalance>$1,000,000,000,000.00</accountBalance> </accountHoldeR> </accountHolders> </class-object> </proxy-object>
More than likely the user would simply return a lazy version of the accountHolders object in which case the <class-object> would go on to describe the <method-object>'s and so on as preparation for the next method call. My api is built on the concept that you are writing an application and not a web page, however using web pages as a struts application would be a really handy way of returning static html for forms and such. I'll think on that a while and see what I come up with. I appreciate the collaboration, you are an easy architect to understand. Bryan ---------- Original Message ----------- From: "Frank W. Zammetti" <[EMAIL PROTECTED]> To: "Struts Developers List" <dev@struts.apache.org> Cc: "Struts Developers List" <dev@struts.apache.org> Sent: Wed, 1 Feb 2006 15:43:57 -0500 (EST) Subject: Re: Help adding Struts to AJAX impl > On Wed, February 1, 2006 3:35 pm, [EMAIL PROTECTED] said: > > I would need to write an AJAXAction that could in turn be extended by the > > code r so that I could control the response back from the servlet. Ok I > > just > > thought of a gotcha for this approach. If the client is expecting a > > specific > > xml response I am not sure how I would allow the user to forward to other > > actions and still maintain control unless all actions were extended from > > AJAXAction and I really don't like that way that implies a re-write of an > > existing application. > > I would say that what is likely to be generating the data that forms your > XML response in a properly-architected application is not likely to be in > the Actions, and hence forwarding isn't a concern. > > As an example, and understand that I'm not familiar with your library so > I'm going to perhaps not a complete understanding... let's say I want the > response from the server to represent a list of account holders: > > <accountHolders> > <accountHolder> > <firstName>Frank</firstName> > <lastName>Zammetti</lastName> > <accountBalance>$1,000,000,000,000.00</accountBalance> > </accountHoldeR> > </accountHolders> > > (Oh how I WISH!! LOL) > > Anyway... if things are written as is generally accepted as being best, > the data in there, which maybe comes from a database, is retrieved not > directly from the Action but from some business delegate. So, your > AJAXAction should not dispatch an incoming request to another Action that > just so happens to use that delegate, but it should instead call on the > business delegate directly. > > So, in my mind at least, a developer wouldn't have to extend AJAXAction > because only a single AJAXAction instance would be present in the app, and > it would be the target of all the incoming AJAX requests. Unless your > thinking is that the Action would be responsible for creating the XML, in > which case you might want to let the developer be in control of that, then > extending AJAXAction is probaly the right answer. In that case, I would > simply say that either (a) forwards are not allowed, which implies the XML > must be formed in the Action itself or (b) forwards to JSPs that render > the XML are all that are allowed (this is demonstrated in AjaxTags in Java > Web Parts by the way). > > It of course comes down to how your library works, and how you want it to > work. > > > Thoughts? > > Those above :) And that I'm getting hungry ;) > > > Bryan LaPlante > > Frank > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] ------- End of Original Message ------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]