<snip/>
> So, if we have an error in a transformer that writes on a database, we > don't have to 'write this information inside the pipeline' in order for > a subsequent selector to get it and behave consequently. If my intuition is remotely correct I would think that in the near future, people will often want to plug in the pipe web services calls (via SOAP transformer) instead of direct calls to custom Java classes (in the form of Transformers or Actions). This will allow them to reuse WS interfaces for both human computer interaction and automatic calls. Will save them testing time, etc. Let's take a sample pipeline: <pipeline> <action desc="Handle Last Page of a Form Wizard: populate and validate last phase"/> <transformer type="castor|jaxb|betwix|?" desc="Make the output of the action available in the request"/> <transformer type="soap" src="http://some/WebSerice/target"; desc="Make a SOAP call sending the SAX input as body"> <select type="xpath"> <when test="/envelope/header/error/500"/> <transform desc="show Bugs Bunny. WS is not availabe!"/> </when> <when test="/envelope/body/purchase/result/complete"/> <transform desc="go to the next stage"/> </when> <when test="/envelope/body/purchase/result/cardDenied"/> <transform desc="go back to the page in the wizard whith the Credit Card input fields"/> </when> </select> </pipeline> There is a clean separation in my mind between xpath selectors and transformers . The former act as bugzilla moderators. They look at a bug and assign a developer to it. The latter transform one sort of document (bug) into another (patch). > > I'm perfectly aware of the fact that components must pass information > one another, but, why in hell should they use something so ackword as > SAX events to write and XPath queries to read when they can simply do an > hashtable lookup? Maybe it will never be as fast as a hashmap lookup, but as you said if its valuable enough, the community will eventually make it sufficiently fast. Without putting too much thinking, one simple possible optimization that comes to mind is: when the document preceding the selector is cached then the selector does not need to evaluate the tests. It'll know the answer. So if a web service responds with the same content, i.e. reports that the result didn't change, then you can imagine that the selector is going to be pretty fast. > > Do you pipe-aware selector fans see my point? I totally support your efforts to challange anything new to the extreme, before it makes it in CVS. This is one certain way to ensure that Cocoon will not explode before its 5th birthday. Cheers, Ivelin > > -- > Stefano Mazzocchi One must still have chaos in oneself to be > able to give birth to a dancing star. > <[EMAIL PROTECTED]> Friedrich Nietzsche > -------------------------------------------------------------------- > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
