struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank Zammetti" <fzamm...@hotmail.com>
Subject Re: Struts Web Services Enablement Project
Date Mon, 07 Jun 2004 17:22:52 GMT
I'm looking at that now Don.  Seems like that might be a good way to go.  
Thanks for making me aware of it!

Frank


>From: Don Brown <mrdon@twdata.org>
>Reply-To: "Struts Developers List" <dev@struts.apache.org>
>To: Struts Developers List <dev@struts.apache.org>
>Subject: Re: Struts Web Services Enablement Project
>Date: Mon, 07 Jun 2004 12:36:36 -0400
>
>What about starting a sub-project on struts.sf.net?  Let the features and 
>stability mature, then if people are using it, talk about migrating it to 
>be a sub-project for Struts.
>
>Don
>
>Frank Zammetti wrote:
>
>>That's exactly what my approach is now Ted.  But, I've been seeing a lot 
>>of suggestions that I think would move this thing to the next level of 
>>complexity, and I didn't want to seem like I was ignoring anyone by 
>>continuing what I'm doing.  I'm definitely listening to what everyone has 
>>to say and considering it all, even those things that I don't immediately 
>>understand I'm trying to research to see if it really fits in with the 
>>goals I had when I started.  But if there really is an underlying current 
>>of wanting to do a true Web Service component to Struts, I'm not so sure 
>>what I'm doing ever could be the foundation for that, so I wanted to raise 
>>the idea of starting a more "official" project now with that express goal.
>>
>>Frank
>>
>>>From: Ted Husted <husted@apache.org>
>>>Reply-To: "Struts Developers List" <dev@struts.apache.org>
>>>To: Struts Developers List <dev@struts.apache.org>
>>>Subject: Re: Struts Web Services Enablement Project
>>>Date: Mon, 7 Jun 2004 12:25:00 -0400
>>>
>>>I'd suggest sticking to your original vision, Frank, and first do the 
>>>"simplest thing that can possibly work".
>>>
>>>Try it for 1.2.x as well as for the Struts-Chain request processor that 
>>>is slated for 1.3.x, to be sure the approach will be forwardly 
>>>compatible, and get it out there where people can try it. It will 
>>>probably be more useful with the Strut-Chain RP, since there will be 
>>>conflicts with the other custom RPs that are popping up.
>>>
>>>If what you start works, and other people use it, then, sure, it could 
>>>become the kernel of a Struts Web Services subproject. That's how Tiles, 
>>>Validator, declarative exception handling, and declarative security all 
>>>started.
>>>
>>>But, first things first, build something that suits the needs of your own 
>>>application, and then we can see what patches people offer up.
>>>
>>>-Ted.
>>>
>>>On Sun, 06 Jun 2004 19:38:51 -0400, Frank Zammetti wrote:
>>> > You raise some good points, as have a lot of people on the list.  I
>>> > keep coming back to the same bottom-line point though... Most of
>>> > the suggestions get into something alot bigger than I started with,
>>> > and that's a good thing, but I'm not sure I'm ready to tackle it
>>> > myself yet.
>>> >
>>> > I think the one underlying point that is coming through is that
>>> > there seems to be a desire, maybe even a need, for a "real" Web
>>> > Service capability built in to Struts.  There's been a lot of
>>> > different ideas about what form it should take, what capabilities
>>> > are important, and how it should ultimately be implemented.  If for
>>> > no other reason, I think bringing that point to light (if it wasn't
>>> > already!) was a good result of my little project.
>>> >
>>> > But, when I examine where I am now, how I've personally chosen to
>>> > do things, and I ask the question of whether I think it could
>>> > really be the basis for a grander vision, I think I lean towards
>>> > the answer being no.  I think I've put forth a couple of decent
>>> > ideas, maybe shown people a way to do things that is if not
>>> > original than maybe not a common method, but I don't for a second
>>> > think it's the be-all and end-all of Web Services in Struts, and I
>>> > suspect it probably never could be.
>>> >
>>> > So, in the short-term, my little package can probably be useful to
>>> > some folks, and that's cool.  Over a relatively short period of
>>> > time I can probably expand it and polish it so it's useful to even
>>> > more people, and maybe even be useful enough and polished enough to
>>> > be included in the Struts distro at some point.  But to turn into a
>>> > whole generally useful to everyone Web Service component of Struts?
>>> >  My gut says no, so I'm a bit hesitant to start down that road,
>>> > especially considering how much I frankly have to learn myself to
>>> > go down that road.
>>> >
>>> > What I do wonder though is if we're coming to a point where maybe
>>> > we can get some people together and start a Struts sub-project (or
>>> > whatever the proper terminology would be) to really do something
>>> > more capable?  I don't think I can pull off something like that
>>> > alone, not short-term anyway, but I'd certainly be interested in
>>> > being a part of such an effort.  So, does anyone else see that as a
>>> > viable thing to do, and if so, how do we go about actually doing it?
>>> >
>>> > Frank
>>> >
>>> >
>>> >> From: robert burrell donkin <rdonkin@apache.org>
>>> >> Reply-To: "Struts Developers List" <dev@struts.apache.org> To:
>>> >> "Struts Developers List" <dev@struts.apache.org> Subject: Re:
>>> >> Struts Web Services Enablement Project Date: Sun, 6 Jun 2004
>>> >> 08:54:26 +0100
>>> >>
>>> >> On 4 Jun 2004, at 22:56, Frank Zammetti wrote:
>>> >>
>>> >>
>>> >> <snip>
>>> >>
>>> >>
>>> >>> After that, I'm thinking that a .04 release maybe a week later
>>> >>> seems reasonable, and with that my main goal is implementing
>>> >>> the pre- and post-transformations suggested here.  I haven't
>>> >>> thought this through yet entirely, but what I think this
>>> >>> amounts to is not much more than adding an xslt-in and xslt-out
>>> >>> attributes to the mappings in webservices-config.xml that, if
>>> >>> present will trigger processing of the incoming and outgoing
>>> >>> XML via these transformations.  The incoming side of things
>>> >>> seems relatively straight-forward to me, but the outbound side
>>> >>> I can't see as clearly right now because as it currently
>>> >>> stands, a JSP renders the XML, so how can I run the resultant
>>> >>> XML through an XSL transformation and return the result to the
>>> >>> client?  One possibility is a new class that would create the
>>> >>> XML and THEN run it through the transformation.  In addition to
>>> >>> that, I would probably add an attribute to the <service>
>>> >>> mappings that would specify whether a JSP is going to render
>>> >>> the output, or it will be the result of a transformation.  This
>>> >>> is just rough thinking at the moment, at least as far as the
>>> >>> outbound side goes.
>>> >>>
>>> >>
>>> >> 1 if you want inspiration about pipelining, then take a look at
>>> >> cocoon: they've been successfully doing this kind of thing for
>>> >> years!
>>> >>
>>> >> 2 the problem with transformations is that (if you want to make
>>> >> them perform), the framework needs to be build with them in mind.
>>> >> typically, this means using something like a SAX pipeline.
>>> >>
>>> >> 3 using a SAX pipeline restricts the choice of object-xml binders
>>> >> that can be used. having a choice is object-xml binders is
>>> >> important.
>>> >>
>>> >> 4 IMHO the most elegant solution would be to replace the entire
>>> >> rendering layer (jsp's etc) with a configurable component-based
>>> >> object-xml lightweight binding framework. the actions take and
>>> >> produce objects which are then rendered to and from xml by the
>>> >> framework. any transformations should be done within this layer
>>> >> rather than without allowing different components to support them
>>> >> in different ways (or not at all).
>>> >>
>>> >> - robert
>>> >>
>>> >>
>>> >> ------------------------------------------------------------------
>>> >> --- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
>>> >> additional commands, e-mail: dev-help@struts.apache.org
>>> >>
>>> >
>>> > _________________________________________________________________
>>> > Stop worrying about overloading your inbox - get MSN Hotmail Extra
>>> > Storage! http://join.msn.click-url.com/go/onm00200362ave/direct/01/
>>> >
>>> >
>>> > --------------------------------------------------------------------
>>> > - To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
>>> > additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>
>>_________________________________________________________________
>>Is your PC infected? Get a FREE online computer virus scan from McAfeeŽ 
>>Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>For additional commands, e-mail: dev-help@struts.apache.org
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>

_________________________________________________________________
Looking to buy a house? Get informed with the Home Buying Guide from MSN 
House & Home. http://coldwellbanker.msn.com/


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


Mime
View raw message