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 <[EMAIL PROTECTED]> >> Reply-To: "Struts Developers List" <[EMAIL PROTECTED]> To: >> "Struts Developers List" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For >> additional commands, e-mail: [EMAIL PROTECTED] >> > > _________________________________________________________________ > 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: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
