cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <gkossakow...@apache.org>
Subject Re: Unified expression handling and unified object model
Date Thu, 22 Mar 2007 14:53:22 GMT
Peter Hunsberger napisaƂ(a):
> 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?

I haven't look into the code too but documentation and samples do not
use result of this function so I think it's not likely there is no
result ;-)
For explanation status code see below.

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

I think that we are saying the same thing. Let me show the possible
scenerio:
1. forms being submitted some <map:match/> in the sitemap catches the
request from the browser
2. flow function "check()" is called
it looks like:
function check() {

  var validationResult = _validate(...);
  if (validationResult == true) cocoon.sendPage("succesPage");
  else cocoon.sendPage("sendFormAgainAndShowValidationErrors", {
validation : validationResult});

}
3. from _validate function pipeline "run/_validate/something" is called
and it looks like:
<map:match pattern="run/_validate/*">
  <map:generate src="..." type="..."/> <!-- obtain the data to be
checked -->
  <map:transform src="..." type="..."/> <!-- here data is validated,
HTTP status code is set for this pipeline according to the result of
validation, report of validation is what this transformer returns as
SAX-stream -->
  <map:serialize type="xml"/> <!-- serialize the report so flowscript
can catch it -->
</map:match>
4. now it's the time for decision what to do next if validationResult ==
true then call pipeline "succesPage" which can look like this one:
<map:match pattern="succesPage">
  <map:generate src="thankYouForFillingTheFormCorrectly.jx" type="jx"/>
  <map:serialize type="html"/>
</map:match>

OR validation failed so "sendFormAgainAndShowValidationErrors" pipeline
is called and report of validation is passed in "validation" variable:
<map:match pattern="sendFormAgainAndShowValidationErrors">
  <map:generate src="xmodule:flowscript:validation"/> <!-- actually
flowscript module does not exist but it's not that important -->
  <!-- do some formatting on the report -->
  <map:serialize type="html"/>
</map:match>

The last pipeline is going to be more complicated of course. You
probably would like to aggregate the form data and display validation
errors in form's context but it's not important here.

One more remark: I've used xmodule and non-existing flowscript
InputModule but it's only to show the idea, with new expression
implementation it would be a little bit different.

This should eliminate all doubts.

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

Serialization/deserialization step can be omitted the same way as it's
done now with the "cocoon:/" protocol calls. And it's worth to pass the
XML because at the end it's exactly you need...
Example above shows that "run/_validate/*" pipeline does not contribute
to the original request from the browser.

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

This new way does not forbid you to store objects in request attribute
or extend Object Model and put them there. The point is that I can
hardly see valid use case where you create some objects in side pipeline
and want pass them to another pipeline. Cocoon's pipelines are about XML
(SAX streams) not Objects/beans/pojos.
I think that in use case you showed you'll be fine to just get XML form
of report and no objects.

As I said earlier the overhead wouldn't be that much with little effort
of extending current code. Actually SAX pipelines, cocoon: protocol
implementation and other similar stuff is to make the overhead minimal,
doesn't it?

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


Mime
View raw message