cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivelin Ivanov" <>
Subject Re: [status & RT] design challenges
Date Sat, 06 Apr 2002 04:56:09 GMT


> 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:

  <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 test="/envelope/body/purchase/result/complete"/>
        <transform desc="go to the next stage"/>
     <when test="/envelope/body/purchase/result/cardDenied"/>
        <transform desc="go back to the page in the wizard whith the Credit
Card input fields"/>

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.



> --
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <>                             Friedrich Nietzsche
> --------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

To unsubscribe, e-mail:
For additional commands, email:

View raw message