Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <46027FDC.4050208@apache.org>
Date: Thu, 22 Mar 2007 14:08:44 +0100
From: Grzegorz Kossakowski <gkossakowski@apache.org>
User-Agent: Thunderbird 1.5.0.10 (X11/20060911)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Unified expression handling and unified object model
References: <46002200.6080709@apache.org>
 <4600762F.3080909@nada.kth.se>	 <cc159a4a0703210747q69bc28c5v9b42e16beed3e829@mail.gmail.com>
	 <46014996.3090301@apache.org>
	 <cc159a4a0703211211l4037f13cre769753893d2a742@mail.gmail.com>
	 <4601918F.4060703@apache.org>
	 <cc159a4a0703211405u6324380ei7fbb51580f4bd863@mail.gmail.com>
	 <4601AD42.7030805@apache.org>
 <cc159a4a0703211944y1a90152mbd7a3dfcf0ddea74@mail.gmail.com>
In-Reply-To: <cc159a4a0703211944y1a90152mbd7a3dfcf0ddea74@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Peter Hunsberger napisał(a):
> On 3/21/07, Grzegorz Kossakowski <gkossakowski@apache.org> wrote:
>
> 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?

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.

>
> 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. So you have to have normal serializer at the
end of your validating pipeline to serialize report. 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.

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?

-- 
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/