On Fri, 2003-01-24 at 22:41, Mike Oliver wrote: > 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.
I do see your point about the HTTP flaw. And with an application as an Actor, the "view of the VIEW" can take some expanding. > > 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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
