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]
