Oh and BTW I believe you are taking a too narrow view of VIEW, so at least on that point we disagree. I would define view as the presentation layer as you do, but the consumer dictates what the presentation layer needs to be, a Cell phone won't have the same needs as a user and an application won't have the same needs as a Cell phone....they are all accessors of the View into a Model via a controller. As it happens a soap response is XML and the HTML you return to a user in a web browser is a subset of XML with the HTML tag subset. I can take a Soap Response and put a Stylesheet reference on it and display it just like an HTML page....so your analogy to HTTP is flawed and JSP is just a way to generate HTML, OR XML, so I humbly disagree.
Michael Oliver AppsAsPeers LLC 7391 S. Bullrider Ave. Tucson, AZ 85747 Phone:(520)574-1150 Fax:(520)844-1036 -----Original Message----- From: Benjamin Tomasini [mailto:[EMAIL PROTECTED]] Sent: Friday, January 24, 2003 7:36 PM To: Struts Developers List Subject: RE: [AXIS4STRUTS] The old In and Out I don't mean to sound overly negative. I think the idea is interesting, and am looking forward to seeing creative solutions to some of these issues. :) I could be missing the point. Most of my comments are from an XML-RPC perspective, where types are more rigid. Document type services may be more flexible. On Fri, 2003-01-24 at 18:51, Mike Oliver wrote: > Ben, > > When I say, "An Actor posts a request to Struts, the data passed in the > request is used to determine what action to take, execute the action and > return a response to the requesting Actor". > > In the above statement am I talking about a User on a Browser or an > Application as the "Actor"? Yes, for a simple, predictable request - response cycle, that is clear. XML-RPC is a good match for that. But Struts provides so much more, multiple forwards, validation, redirect vs. forward etc ... The application logic could easily fall outside of the confines of an XML-RPC call, unless you exposed some of these features of struts back to the client - extending the controller back to the client. > > If as you say Axis doesn't provide a "View" then what does it provide? > It accepts requests for action and returns a response. The business > logic in a web service isn't in the Axis layer, nor should it be, no > more than should the business logic be in the JSPs for Struts > Applications. So I must disagree, all Axis does is provide a View, it > certainly isn't an application's Controller or Model, it is an Interface > and therefore a View. The view is generally referred to as the presentation and UI. Like JSPs, Velocity, etc... You can't click on a SOAP message, enter data into a SOAP message, or change the color or font. The SOAP message would be used by another view technology to create a UI. SOAP exposes an object's interface as XML, and provides a standard communication mechanism. Like HTTP. HTTP isn't a view either, but HTML is, as is JSP, etc.... > > I am afraid I don't understand why you think the use of Axis to provide > another view requires us to "dumb down the server app". Refer to my > paragraph #1 No, I only said if you do not beef up the client. Things like action errors, validation, forwards, etc ... can be handed by the client, but that would require a return type that would encapsulate these things, which could be a rather complex class to pass back from an RPC call. I am sure there will be some tradeoffs. > > Michael Oliver > AppsAsPeers LLC > 7391 S. Bullrider Ave. > Tucson, AZ 85747 > Phone:(520)574-1150 > Fax:(520)844-1036 > > > -----Original Message----- > From: Benjamin Tomasini [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 24, 2003 3:38 PM > To: Struts Developers List > Subject: RE: [AXIS4STRUTS] The old In and Out > > True. But somehow, to leverage what struts really is, you would need to > communicate some kind of instructions from the server side controller. > > I think the core of what I am saying is that Axis does *not* provide a > view. And therefore you would have controller functions on the other > side of the web service. So you dupliate what Struts does, you would > need to bridge communications between the two controllers. > > That is where I see the problem. Simple XML-RPC of "view/model" objects > with Struts doesn't leverage core Struts features to the client > controller. So you either dumb down the server app, or beef up the > client controller. > > On Fri, 2003-01-24 at 17:31, [EMAIL PROTECTED] wrote: > > > > > > > > > > > ** You may find more utility in creating set of client side proxys > for > > > Struts server side controller contructs. In other words, RPC the > > > selected controller components. ActionForms would be user defined, > but > > > the ActionForward, ActionErrors, etc ... could be proxy objects. > > > > I like this idea - but doesn't this assume that the client is Java? > > > > > > > > > ------------------------------------------------------------------------ > --- > > This e-mail message (including attachments, if any) is intended for > the use > > of the individual or entity to which it is addressed and may contain > > information that is privileged, proprietary , confidential and exempt > from > > disclosure. If you are not the intended recipient, you are notified > that > > any dissemination, distribution or copying of this communication is > > strictly prohibited. If you have received this communication in > error, > > please notify the sender and erase this e-mail message immediately. > > > ------------------------------------------------------------------------ > --- > > > > > > > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
