On Thursday 29 November 2001 02:18 pm, you wrote: > In essence, we are merging concepts of Cocoon with the Handler concept of > Axis. There is now no distinction between an Action and a Transformer that > acts on the request markup. By arranging the order of these > Transformer/Handlers we can elegantly create powerful web applications. > This might be more inline with the reactor pattern--but nothing like Cocoon > 1.
Let's take the classic posting data to a form example, how would this work in a bidirectional XML pipeline? User posts data to the webserver, this is then transformed into an XML request and an incoming pipeline to the service(generator) is constructed. Would the Transformers on that pipeline be destructive? That is removing data from the XML request and applying it to the external store? (The opposite of a transformer that watches for tags and reads from the external store). Should the incoming pipeline whittle the XML request down to nothing by the time it reaches the service, or does the XML go through the service, with the service acting as the U-turn point? The other thing is how would caching play into such a beast? I think that's an important concept to thing about up front. With SOAP its not really an issue since more often than not you don't want to cache function calls, but for web content caching is king. I guess if the input pipeline and output pipeline are separate, then the output pipeline can still be partially cacheable similar to how cocoon acts today? For webapps, this could be *very* powerful if attached to something like XML-Schema, since you could then have an input transformer that does datatype validation. > While I can appreciate the difference between Session and Request > variables, there are just too many access points to worry about. > Environment simplification is another matter altogether. I enjoy having two different places to stick things now, as by making Request attributes, I know they will all start as null on the next request. Of course you could make the Environment have multiple setAttributes, one for persistent attributes and one for the current active transaction. > (because I was writing in the stream of consciousness), hopefully somebody > will get something out of the ideas I presented. Slowly processing :) My comments might not make a ton of sense either, but its important to get words tossed around. -pete -- peter royal -> [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
