cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Hunsberger" <peter.hunsber...@gmail.com>
Subject Re: Unified expression handling and unified object model
Date Wed, 21 Mar 2007 21:05:18 GMT
On 3/21/07, Grzegorz Kossakowski <gkossakowski@apache.org> wrote:
> Peter Hunsberger napisaƂ(a):
> > On 3/21/07, Grzegorz Kossakowski <gkossakowski@apache.org> wrote:

<snip/>

> To be sure that I understand your use case I'm going to ask additional
> questions:
> 1. What kind of data is stored in these beans? One pulled from config
> failes, or maybe pulled from database?

Mostly from the database, sometimes from interfaces to external
systems.  Often  massaged by procedural logic so it's not just a
normal database call.

> 2. Are these beans (I guess classes you walk through are beans)
> generated every request or generated once on startup?

We have a variety of creation patterns, depends on the caching and
usage requirements.  Some are pretty static, generated at system start
up, some refresh on daily cycles and others are very dynamic.  We have
our own interface that these classes have to conform to in order to
avoid using introspection, but they are essentially just POJOs.

<snip/>

> Yes, I need to ask additional questions. I would like to know why
> wouldn't you just grab XML (in whatever representation DOM/stream of SAX
> events) from validation pipeline and return as result of the function
> _validate if validation failed.
> If it was successful you could return
> just null value as indicator. Now logic calling _validate function can
> pass the XML with validation report to the pipeline that is going to
> show the report. This way you avoid using "magical black box" in form of
> request attributes.

With Schematron you've got to dynamically create the actual XSLT
that's going to be used to validate the form at the time of
validation; you need an entire pipeline just to do the validation.  As
such, there's no way to get the resultant XML back into the original
pipeline without this pattern.  Note that you're running the
Schematron in the middle of a flow action, you haven't actually
started to generate anything to send back to the user yet; you're not
even sure what page you're going to be sending back to the user until
_after_ the validation completes.

If I understand the SOAP case it's sort of similar; you're in the
middle of parsing a chunk of XML that's been sent to you and now
you've got to determine what you are going to send back to the user.
It might be an error or some other type of response, but you won't
know until after you've run the other pipeline.  The parser is
triggering an action that is going to be used by the parser to
determine how to continue.

> Now, I wonder about validationErrorLevel attribute... Wouldn't it be
> enough to just set appropriate HTTP status code in validating pipeline
> and gather it in flowscript? I think that your validation pipeline is
> sort of service and I think that we already agreed that service pipeline
> should be as HTTP-compliant as possible. Using HTTP status code is a way
> to achieve this.

You could pass the simple status around that way. However, with the
input/output module you're not actually doing any HTTP so you avoid a
couple of layers of extra overhead, you can essentially have a null
serializer. More importantly, is how you get the Schematron error
report (or the results of the call to the encapsulated system in a
SOAP request) back into the original calling pipeline?

> To be clear: I do not try to say that your solution is in any way worse
> than mine. All I want to say that there is different way of solving this
> problem that does not demands existence of any output module and would
> like to hear opinion on it.

There might be going forward (that's what I want to ensure), I don't
think there is a way to avoid it in the 2.1 code base...

-- 
Peter Hunsberger
Mime
View raw message