Stefano Mazzocchi wrote:
> Gianugo Rabellino wrote:
>
>
>>I have a basic concern here. URLs are, as the name suggests *locators*
>>or *identifiers*. The idea is that via a URL you can locate (identify)
>>data and fetch them: they were not designed to handle the opposite case
>>where you have to send data to them. The HTTP POST is a workaround which
>>is HTTP specific and goes way beyon the URL concept: there is no way to
>>express in the URL syntax the *direction* of the data flow. And if you
>>can't tell, looking at a URI, if it's "read" or "write" you will end up
>>with troubles using it in an intermixed way.
>>
>
> Great analysis. In fact, I believe that the sense of "outward biasing"
> of the Cocoon internal pipelines if a reflection of this lack of
> direction information for URIs.
>
> Now, I believe that URI should *NOT* have any direction information
> because it's up to another concern islands to come up with this (like
> HTTP does).
>
> For example, I was impressed by the elegance of the first servlet I saw
> that used the toGet() method to generate the form, the doPost() method
> to process it and a doError() method to generate the form with error
> indications (called by the doPost() method directly).
>
> [I want this elegance to be percepted from the statemap as well!]
Let me throw a _very_rough_ overview of how Axis handles it's pipeline.
For the uninitiated, SOAP applications need to have an inbound pipeline,
and an outbound pipeline. This way, you can process header information
to authenticate users of a service, charge for the privelege of using
the service, etc. I thought a variation of this concept would be beneficial
to Cocoon.
In Axis there is the ominous Handler. A Handler is anything in the pipeline.
A Handler can perform Actions based on the header or body markup. It can
also alter the header and markup sections at will. Because it is simply a
"Handler", there is no distinction between Generator, Transformer, and Sink.
The pipeline works something like this:
SOAP-IN
+-----Transport Input Pipeline
+-----Global Input Pipeline
+-------+
Service
+-------+
+-----Global Output Pipeline
+-----Transport Output Pipeline
SOAP-OUT
Each Pipeline can have 0..n Handlers, that all affect the transaction in
some way. At first I did not like the genericness of this approach, but
sometimes such an approach is extremely powerful and flexible. As with
all things generic there can be abuses. However, it is clear that the SOAP
paradigm will forever change the way we think about how the web should work.
In fact, I would love to have Cocoon as a SOAP service provider. I was
originally investigating this before I got put on another project (small
companies are not condusive to R&D).
Cocoon already has a great deal of complexity, so any solution that is
elegant enough to reduce the apparent complexity (there is a distinction
between apparent and real complexity) will be favorable to me.
My thoughts (in keeping with the Cocoon architecture and bi-directional
pipelines) at the time required a change in the way we think about the
whole Request/Response approach.
Cocoon is insanely great at dealing with XML. In fact this is something
I really like about it. However, the environment is very Servlet based.
This is not a derogatory statement, just the facts as they currently are.
What happens when we have a change in the type of message received by
the web server (i.e. Content-Type: text/xml). XForms and SOAP both require
the server to understand an XML input. Also, the typical Request object
can be represented as XML.
Here is where we can have a richer environment, that is not as dependant
on the Servlet spec, provides the bidirectional pipelines, and adds a user
experience that should ease development. After all Cocoon users are
developers...
The first step is to represent the input request as XML. By doing this,
the Generator concept is different. The input stream is always converted
to XML. For Content-Type: text/xml, only a wrapper element is required
to express the requested URI and other HTTP meta-information. The subset
of information we are willing to support should work the same regardless
of the true environment.
The Sitemap now becomes the "Transformer/Sink" that assembles the rest of
the pipeline. Sessions can be managed automatically by the environment,
or more specialized session handling (that incorporates back-button proofing
your site) can be employed. All actions performed before final serialization
are transforms on the input.
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.
The pipelines are still declared in a central location (i.e. Sitemap/Statemap).
The Sitemap can declare a rather lengthy series of handlers that can both
alter the request information or store the request information. At some point,
we need the ability to read our XML from the webapp folder, and this can be done
with a specialized Handler that now drops the incoming body of the message,
and replaces the body with the one we are transforming.
However, the Environment objects did have something going for them that this
approach does not handle: the ability to quickly and easily access request
info by a natural Java interface. There is an inherent simplicity in that.
However, I think the intrafaces we have are too general for web applications.
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.
Now that I have completely confused the hell out of myself and everyone else
(because I was writing in the stream of consciousness), hopefully somebody
will get something out of the ideas I presented.
Fire away!
--
"Those who would trade liberty for
temporary security deserve neither"
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
