struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Oliver" <ol...@appsaspeers.com>
Subject RE: [AXIS4STRUTS] The old In and Out
Date Sat, 25 Jan 2003 04:16:42 GMT
It was a bad pun..."view of the VIEW", sorry.

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:btomasini@neteverything.com] 
Sent: Friday, January 24, 2003 8:46 PM
To: Struts Developers List
Subject: RE: [AXIS4STRUTS] The old In and Out

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:btomasini@neteverything.com] 
> 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:btomasini@neteverything.com] 
> > 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, Kevin.Bedell@sunlife.com 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:struts-dev-unsubscribe@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <mailto:struts-dev-help@jakarta.apache.org>
> > > 
> > 
> > 
> > 
> > --
> > To unsubscribe, e-mail:
> > <mailto:struts-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> > <mailto:struts-dev-help@jakarta.apache.org>
> > 
> > 
> > --
> > To unsubscribe, e-mail:
> <mailto:struts-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> <mailto:struts-dev-help@jakarta.apache.org>
> > 
> 
> 
> 
> --
> To unsubscribe, e-mail:
> <mailto:struts-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:struts-dev-help@jakarta.apache.org>
> 
> 
> --
> To unsubscribe, e-mail:
<mailto:struts-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:struts-dev-help@jakarta.apache.org>
> 



--
To unsubscribe, e-mail:
<mailto:struts-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:struts-dev-help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@jakarta.apache.org>


Mime
View raw message