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]

Reply via email to