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 Thu, 22 Mar 2007 14:11:33 GMT
On 3/22/07, Grzegorz Kossakowski <gkossakowski@apache.org> wrote:
> > 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?
>
> I don't think that any incompatibility would be introduced. The only
> change that is needed is to return status code as result of
> processPipelineTo. Now, AFAIK this result value is just undefined so
> nobody relays on it. Nothing else would be changed.

I haven't looked at the code but it sounds like you're saying it
currently returns a void? If so and the existing code will function
properly than sounds good.  The question is where does this status
code come from?

> >
> > 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).
>
> I'm lost here now.
> I propose to use _valid_ Cocoon's pipeline for validation but internal
> one, invoked from flowscript. Validation report would be included in XML
> returned by this pipeline.

We might be saying the same thing, but I'm not sure. How is the
validation report going to be included in the an internal pipeline
invoked from the flowscript? It's not just simply a case of
aggregating the normal forms creation with some data from a validation
step.  You need to invoke the validation pipeline and examine it's
output _before_ you know what internal pipeline is going to be
invoked.  So you run a pipeline, look at the results, then you decide
what internal pipeline is going to run; the key is you don't need a
complete valid pipeline to do this, you only need access to the SAX
events that it creates.

> So you have to have normal serializer at the
> end of your validating pipeline to serialize report.

No, the  validation is purely an internal process that in theory may
not contribute anything to  the current pipeline (other than a true or
false in the flow).  Consider the validation step as a call to a third
party library function of some kind (but one that happens to be
running Cocoon) that is going to create an object for you that you can
examine.  Yes you could go to all the trouble of making this external
library serialize XML and then you could deserialize it and look at
it, but why bother if you can instead simply pass objects back and
forth?

> Also status code is
> set according the result of validation (failed/succeed) so the caller
> could easily decide what to do next without investigating into details
> of actual report.
> If validation succeed it's usually no report to return so validation
> pipeline would just return dummy:
> <validationSucceed/> XML fragment.

Yes, we can serialize the call to the other pipeline as XML, include
HTTP headers and use all the extra metadata if we want to.  However, I
don't see why we need the extra overhead in this case?  What we really
need is to have access to the SAX stream of the external process so
that you can examine it and maybe capture some parts of it for reuse
somewhere else.

> My main point was, that you can achieve exactly the same effect without
> the use of output modules and correct pipeline (not missing e.g.
> serializer). Don't you?

I think so, the question is at what cost?  If the new way of doing
things is going to force me to always run a complete pipeline and only
access the results via serialization and deserialization with no way
to pass objects between the side pipeline call and the main pipeline
then I think the overhead is too high.  If there is some way to invoke
a side pipeline and later discover an object (a SAX buffer would be a
great generalization) that was created as a result of running it in
some extended object model (without worrying about whether anything
ever got serialized) then I'm fine with that...

-- 
Peter Hunsberger

Mime
View raw message