cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: Unified expression handling and unified object model
Date Wed, 21 Mar 2007 20:11:59 GMT
Peter Hunsberger napisaƂ(a):
> On 3/21/07, Grzegorz Kossakowski <> wrote:
> We sort of have a version of this in our code; we have a factory
> implementation that discovers any class in a particular package so
> it's not completely generalized (no Spring here, we started this with
> Cocoon 2.3 or so) but it's pretty handy for simple lists of values and
> even simple trees (we recognize an additional interface that allows
> for building the hierarchy).
> In our case, we essentially have a sort of
> "ObjectModelWalkingGenerator" that makes it trivial to generate random
> XML fragments (really SAX events); create a class with some standard
> interface and bang, any pipeline that includes such a generator will
> walk a class (perhaps determined by an argument to the generator) and
> create name value pairs in some standard way (it's more general than
> that but I think you get the idea)..
> In our case we feed this into XSLT and avoid using any custom
> templating or custom expression language, but really I think it's the
> same thing in the end?

To be sure that I understand your use case I'm going to ask additional
1. What kind of data is stored in these beans? One pulled from config
failes, or maybe pulled from database?
2. Are these beans (I guess classes you walk through are beans)
generated every request or generated once on startup?

> I don't have a SOAP example, here's a stripped down version of the
> flow code for our Schematron evaluation:
> function _validate( page, args ) {
>    var sourceURI = "run/_validate/"+page;
>    var destinationURI = "xmodule:request-attr:validate";
>    var resolver = null;
>    var destination = null;
>    try  {
>        resolver = cocoon.getComponent(
> );
>        destination = resolver.resolveURI( destinationURI );
>        var output = destination.getOutputStream();
>        cocoon.processPipelineTo( sourceURI, {}, output );
>        output.close();
>        if ( cocoon.request.getAttribute( "validationErrorLevel" ) == 0
> )   {
>            return true;
>        }
>    }
>    finally  {
>        if (destination != null)   {
>            resolver.release( destination );
>        }
>        cocoon.releaseComponent( resolver );
>    }
>    return false;
> }
> Basically, we do a sendPageAndWait on a form and then run this
> function after it returns to validate the form results.  If the
> function returns false we are going to reshow the page and we can grab
> the errors from the validation pipeline and show them on the page
> along with everything else (via aggregated XML from multiple
> generators).
> The key here is that you can run a pipeline in the middle of running
> some flow logic and examine the results of the pipeline to determine
> what the flow logic is going to do next.
> This will probably raise more questions than it answers, but feel free
> to ask away if you see a need...

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

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.

Grzegorz Kossakowski

View raw message