cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Hunsberger" <>
Subject Re: Unified expression handling and unified object model
Date Thu, 22 Mar 2007 02:44:54 GMT
On 3/21/07, Grzegorz Kossakowski <> wrote:


> >
> > 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.
> I'll elaborate on my proposition and rework your code:
> function _validate( page, args ) {
>    var sourceURI = "run/_validate/"+page;
>    var destinationURI = "xmodule:request-attr:validate";
>    var resolver = null;
>    var destination = null;
>    try  {
>        var validation = new SaxBuffer;
>        var output = new SaxOutputStream(validation);
>        var statusCode = cocoon.processPipelineTo( sourceURI, {}, output);
>    }
>    finally  {
>        output.close();
>    }
>    if ( statusCode >= 400 )   { //validation failed
>        return validation;
>    } else {
>        return true;
>    }
>    return null;
> }
> Now you could do this:
> function someFlow() {
>   //showing form here
>   var validationResult = _validate(...);
>   if (validationResult == true) cocoon.sendPage("succesPage");
>   else cocoon.sendPage("sendFormAgainAndShowValidationErrors", {
> validation : validationResult});
> }
> Isn't it what you wanted to achieve?

That is essentially what we are already doing.  The issue isn't how to
deal with the results (true or false) of the validation pipeline.  The
issue is how to run the validation pipeline and get the results in the
first place.  The difference of whether you can get at the status code
or whether you get an attribute is more-or-less orthogonal to the real
problem (though it helps clean things up a little). What you need to
focus on is how do your fork a process in the middle of an action and
run a pipeline and then reuse the results of that pipeline in the
generation process that follows the action.

Currently you can't capture directly into a SaxBuffer (more on that
below), so that would be a good way to clean up a bit of the code bse.
 However, I think you'd have to create a new function and deprecate
the current processPipelineTo for backwards compatibility?


> >
> > 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?
> I don't understand, show it could be to have "null" serializer? What
> does it mean?

Currently, with a positive validation (true) you can just trash the
results of the validation.  If you have errors we capture them in an
object that latter essentially replays them as SAX events. (We don't
directly capture the Sax events, rather we capture the error text in
an object, but it's more or less the same thing). At no point do we
ever serialize the results of the side pipeline and then deserialize
them to aggregate them back into another pipeline.  As a result the
side pipeline doesn't have a normal Cocoon life cycle, the serializer
does nothing, no headers are built, no output is generated, the side
pipeline was run and SAX events were examined but that's the end of
it. I think this is what you're more-or-less proposing but in a little
cleaner way (and the code comes with the Cocoon base).

Peter Hunsberger

View raw message