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 22:10:10 GMT
Peter Hunsberger napisał(a):
> On 3/21/07, Grzegorz Kossakowski <> wrote:
>> Peter Hunsberger napisał(a):
>> > On 3/21/07, Grzegorz Kossakowski <> 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.

Thanks for the info. Now I think it's clear that object model should be
extensible that way we can cover such a use case. It means that you
should be able to both iterate through your POJOs and even write
something like this:
<map:parameter name="valueFromMyPojo"
value="{myPojos/pojo1/pojo2/name}"/> or sort of.

> 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  {
   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?

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

Can be done in similar way to the above.

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

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

We are talking about 2.2. What I showed above is not even possible with
current trunk but this thread is about stuff that would be probably
implemented. Given that, it's worth to consider if it's good idea to
have such functionality.

Grzegorz Kossakowski

View raw message