You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@apache.org> on 2003/11/10 21:15:34 UTC
[vote] forbidding flowscripts with no sendpage redirects (was Re:
Saving pipeline output to a temp file...)
Let's reformulate this into a proper vote.
Do you want to enforce the fact that flowscript calls (either "function"
or "continuation") *must* redirect using sendPage, sendPageAndWait or
redirectTo and that, should it not be the case, a ProcessingException be
raised?
[ ] no, let the sitemap execution continue after the <map:call> if there
was no redirect.
[ ] yes, enforce it in 2.1.3
[ ] yes, enforce it in 2.1.4
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [RT] Is flowscript polluting sitemap readability?
Posted by Joerg Heinicke <jh...@virbus.de>.
On 12.11.2003 23:01, Marc Portier wrote:
>>> Only a random thought: why there is no FlowScriptSelector calling the
>>> flow script and evaluating the String return type? This would remove
>>> the sitemap calls flow script calls sitemap and is more like a
>>> function call. You will have only one pipeline, not two.
>>
>
> this sounds like the struts way of returning some action-exit-code?
Yes, similar. Struts actions return an ActionForward object, which can
either be mapped to a view (i.e. JSP) or can directly specify a view
(with the last part I am unsure).
> which admittedly makes more sense then the alternative suggestion of
> injecting the URI's into the script-function as parameters to read
Absolutely, because how to pass multiple selection URIs? Multiple
map:parameter's?
> but I couldn't help thinking: isn't that precisely the role the
> URI-string argument in sendPage{AndWait}("uri") is taking up?
Yes.
> I see how it adds to readability, but can't we see the sitemap's core
> function of siwtching on 'URI' as enough for doing this?
>
> this introduces an extra mapping layer that only seems to buy us the
> ability to reuse flowscripts-functions regardless of the changed
> URI-mapping on the server
"Only"?? This is the main reason (and why other people don't want to
enforce sendPage{AndWait}(), because they use flow script action-like).
> (hm, that does sound like a useful gain of a typical SoC operation, ah
> well, have to think some more)
>
>>
>> Hmmmmm, hmmm, hmmm
>>
>> you are onto something here....
>>
>
> yep, I had that feeling already in Joerg's previous post ;-)
Thanks :-)
> (well, it's not a real secret that I've been struggling with how flow
> and sitemap are touching each other myself)
Ah, I'm not the only one.
>> Stefano, gone to the whiteboard
>
> -marc= (just animating the audience while Stefano is scetching...)
After the GT we know your capabilities in this area - you were great :-)
Joerg
Re: [RT] Is flowscript polluting sitemap readability?
Posted by Marc Portier <mp...@outerthought.org>.
Stefano Mazzocchi wrote:
>
> On 12 Nov 2003, at 19:49, Joerg Heinicke wrote:
>
>> Only a random thought: why there is no FlowScriptSelector calling the
>> flow script and evaluating the String return type? This would remove
>> the sitemap calls flow script calls sitemap and is more like a
>> function call. You will have only one pipeline, not two.
>
this sounds like the struts way of returning some action-exit-code?
which admittedly makes more sense then the alternative suggestion of
injecting the URI's into the script-function as parameters to read
but I couldn't help thinking: isn't that precisely the role the
URI-string argument in sendPage{AndWait}("uri") is taking up?
I see how it adds to readability, but can't we see the sitemap's core
function of siwtching on 'URI' as enough for doing this?
this introduces an extra mapping layer that only seems to buy us the
ability to reuse flowscripts-functions regardless of the changed
URI-mapping on the server
(hm, that does sound like a useful gain of a typical SoC operation, ah
well, have to think some more)
>
> Hmmmmm, hmmm, hmmm
>
> you are onto something here....
>
yep, I had that feeling already in Joerg's previous post ;-)
(well, it's not a real secret that I've been struggling with how flow
and sitemap are touching each other myself)
> --
> Stefano, gone to the whiteboard
>
-marc= (just animating the audience while Stefano is scetching...)
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
Re: [RT] Is flowscript polluting sitemap readability?
Posted by Stefano Mazzocchi <st...@apache.org>.
On 12 Nov 2003, at 19:49, Joerg Heinicke wrote:
> Only a random thought: why there is no FlowScriptSelector calling the
> flow script and evaluating the String return type? This would remove
> the sitemap calls flow script calls sitemap and is more like a
> function call. You will have only one pipeline, not two.
Hmmmmm, hmmm, hmmm
you are onto something here....
hmmmm hmmmm
--
Stefano, gone to the whiteboard
Re: [RT] Is flowscript polluting sitemap readability?
Posted by Joerg Heinicke <jh...@virbus.de>.
On 12.11.2003 14:39, Stefano Mazzocchi wrote:
>> I'm the same. In fact, I think that flow in some cases needlessly
>> complicates the composition of a pipeline. Now I have to have two
>> pipelines where I used to need one.
>
>
> wait wait wait. hold it.
>
> There are different issues on the table here:
>
> 1) applying the good old "strict first, open later if needed" pattern
> to flowscript/sitemap interaction
That's absolutely okay and I don't have any problems with it.
> 2) criticizing the sitemap/flowscript separation
But here ...
>> I have to have one that matches the external request and calls the
>> flow function, and another one for the default result of that
>> pipeline. So far this has felt like needless additional complexity to
>> me (and I think will to others).
>>
>> To try to make this point a little clearer:
>> Part of the beauty of the sitemap prior to flow was that you could at
>> a glance see what each request url was triggering.
>
>
> Look at this pipeline:
>
> <match pattern="**">
> <act type="my_own_action">
> <generate src="{param1}.{type1}"/>
> <transform src="{type1}2html.xslt"/>
> <serialize/>
> </act>
> <read src="error.html"/>
> </match>
>
> when is the error triggered? What is the above supposed to do? I know
> the example sounds rather artificial, but if you look around in the more
> complex uses of actions (the portal framework, for example, or Lenya)
> you see that 'readability' is not really improved the sitemap by itself.
No, the action flow is also not really good and obvious. It works only
if you know exactly what an action is doing. Good naming like
resourceExists does help, but not more. Naming conventions do not
replace the restrictiveness of a good approach as I already said in my
reply to Antonio's mail.
>> Now, I look at the sitemap, have to locate the flowscript, parse
>> through it for the various sendPage etc. and then back to the sitemap
>> to find where the action really happens. This could perhaps be
>> handled with some best practice naming conventions. Perhaps a
>> practice of passing in the various possible view uris to the
>> flowscript should be considered. I don't know.
>
>
> Flowscript makes the sitemap more declarative and allows to move the
> logic away from the sitemap and leaves the sitemap with pipelines that
> are either "called" by the servlet or from its internal.
>
> Note that not only flowscript allowed this "declaritization", but
> followed the "cocoon:" protocol in doing so.
>
> Is this intrinsically less readable than an action? no, it just moved
> the readability in another place.
>
> Vadim suggested the introduction of action-like syntax to allow to see
> exactly where you end up being...
No, I absolutely don't like it, in what form ever. We would introduce
the same problems as for actions.
<snip what="action-like syntax"/>
> It looks a lot like design patterns for XSLT: xslt is not hard to write
> *per se* (for a programmer, I mean, once you understand it)... but it's
> hard to find "good stylesheets" and it's hard to debug them because it's
> hard to see the "instruction flow"... since it's a declarative rule engine.
>
> The sitemap goes in that direction. It is becoming more and more
> declerative regarding request generation and the procedural part has
> been moved away, locked in the place where it should be easier to read.
>
> It is true, though, that currently, in the middle of the transition
> stage, more and more logic is done in the pipeline components that
> shouldn't be done there! There are tons of transformers and actions
> doing stuff that should be done at the flowscript level (from accessing
> a regular java component that gives a specific service)
>
> But I don't think the model is wrong... it's just that the current
> component set grew out of the pressure of a different environment with
> different limitations... flow is going to change this and will also make
> patterns emerge.
>
>> I'm not negative on flow, and not positive on actions - just pointing
>> out a loss of readability of the sitemap that has resulted from our
>> move forward.
>
>
> In italian we say this is the classic "problem of the small blanket":
> you can't cover everything with one solution, you cover one part and you
> uncover another.
>
> It is true that flow separates things and make it harder to understand
> what pipelines make action of a single resource production. the cocoon:
> protocol makes thing even worse.
>
> It is entirely possible to come up with a debugging view of the cocoon
> execution that shows the trace of all the stages that happened in the
> creation of a cocoon pipeline. This is something that we'll have to do,
> also to be able to do a serious "inverted cache".
Understanding code should be possible without debugging it.
> Also, the original sitemap readability is not compromised in case you
> don't need flow. And if you do, using actions will not make things more
> readable... just more limited. (it is entirely possible to come up with
> a flow equivalent of actions that is just as readable, by introducing a
> simple URI-space pattern for pipeline matching)
Some days ago you complained about bad things in the sitemap like
actions, resources and ... (don't remember). You suggested to use
selectors where appropriate and I can only agree with this, because they
make the sitemap flow really obvious.
Only a random thought: why there is no FlowScriptSelector calling the
flow script and evaluating the String return type? This would remove the
sitemap calls flow script calls sitemap and is more like a function
call. You will have only one pipeline, not two.
Joerg
Re: [RT] Is flowscript polluting sitemap readability?
Posted by Joerg Heinicke <jh...@virbus.de>.
On 12.11.2003 18:14, Andrzej Jan Taramina wrote:
> Stefano:
>
>>As a rule, we should restrict everything that we can't come up with a
>>reason to make it possible, then keep listening for people that could come up
>>with those reasons.
>
>
> Everything that is not explicitly allowed is disallowed?
Exactly.
> That sucks and, IMNSHO, will be the eventual death of innovation in Cocoon
> and projects that take a similar attitude.
No, it was almost always handled this way. It's restrictive and forces
you to think about your solutions. You will get clean concepts out of
it. Everything else can be abused easily as it is done often with
actions as Stefano pointed out in different threads and mails.
Joerg
Re: [RT] Is flowscript polluting sitemap readability?
Posted by Stefano Mazzocchi <st...@apache.org>.
On 12 Nov 2003, at 18:14, Andrzej Jan Taramina wrote:
> Stefano:
>
>> As a rule, we should restrict everything that we can't come up with a
>> reason to make it possible, then keep listening for people that could
>> come up
>> with those reasons.
>
> Everything that is not explicitly allowed is disallowed?
>
> That sucks and, IMNSHO, will be the eventual death of innovation in
> Cocoon
> and projects that take a similar attitude.
Pfff, we have been doing this since cocoon started. How about that for
lack of innovation?
--
Stefano.
Re: [RT] Is flowscript polluting sitemap readability?
Posted by Tony Collen <co...@umn.edu>.
Andrzej Jan Taramina wrote:
> Stefano:
>
>
>>As a rule, we should restrict everything that we can't come up with a
>>reason to make it possible, then keep listening for people that could come up
>>with those reasons.
>
>
> Everything that is not explicitly allowed is disallowed?
>
> That sucks and, IMNSHO, will be the eventual death of innovation in Cocoon
> and projects that take a similar attitude.
I thought it sucked at first. Look at the sitemap. A default sitemap is "closed" and you need to
open it up to serve anything. It's the inverse of how "normal" web servers work, but I think it
makes sense.
Don't be so quick to judge ;)
Tony
Re: [RT] Is flowscript polluting sitemap readability?
Posted by Andrzej Jan Taramina <an...@chaeron.com>.
Stefano:
> As a rule, we should restrict everything that we can't come up with a
> reason to make it possible, then keep listening for people that could come up
> with those reasons.
Everything that is not explicitly allowed is disallowed?
That sucks and, IMNSHO, will be the eventual death of innovation in Cocoon
and projects that take a similar attitude.
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com
[RT] Is flowscript polluting sitemap readability?
Posted by Stefano Mazzocchi <st...@apache.org>.
On 11 Nov 2003, at 15:48, Geoff Howard wrote:
> I'm the same. In fact, I think that flow in some cases needlessly
> complicates the composition of a pipeline. Now I have to have two
> pipelines where I used to need one.
wait wait wait. hold it.
There are different issues on the table here:
1) applying the good old "strict first, open later if needed" pattern
to flowscript/sitemap interaction
2) criticizing the sitemap/flowscript separation
As for the first one, I think we have consensus (no -1 were expressed):
it is better to tighten up sooner rather than later. We can always open
up later on. This makes transitions less painful for everyone.
As for #2, the issue is completely different and requires an entirely
different reasoning. But it's important so let's do it.
> I have to have one that matches the external request and calls the
> flow function, and another one for the default result of that
> pipeline. So far this has felt like needless additional complexity to
> me (and I think will to others).
>
> To try to make this point a little clearer:
> Part of the beauty of the sitemap prior to flow was that you could at
> a glance see what each request url was triggering.
Look at this pipeline:
<match pattern="**">
<act type="my_own_action">
<generate src="{param1}.{type1}"/>
<transform src="{type1}2html.xslt"/>
<serialize/>
</act>
<read src="error.html"/>
</match>
when is the error triggered? What is the above supposed to do? I know
the example sounds rather artificial, but if you look around in the
more complex uses of actions (the portal framework, for example, or
Lenya) you see that 'readability' is not really improved the sitemap by
itself.
> Now, I look at the sitemap, have to locate the flowscript, parse
> through it for the various sendPage etc. and then back to the sitemap
> to find where the action really happens. This could perhaps be
> handled with some best practice naming conventions. Perhaps a
> practice of passing in the various possible view uris to the
> flowscript should be considered. I don't know.
Flowscript makes the sitemap more declarative and allows to move the
logic away from the sitemap and leaves the sitemap with pipelines that
are either "called" by the servlet or from its internal.
Note that not only flowscript allowed this "declaritization", but
followed the "cocoon:" protocol in doing so.
Is this intrinsically less readable than an action? no, it just moved
the readability in another place.
Vadim suggested the introduction of action-like syntax to allow to see
exactly where you end up being...
<call function="blah">
<generate/>
<transform/>
<serialize/>
</call>
but this has one major limitation: the flow can call one and only one
pipeline. If we reintroduce the super-ugly action-like syntax and we
allow
<call function="blah">
<generate/>
<transform/>
<serialize/>
</call>
<read/>
then we allow the flow function to call "two" pipelines... but what
happens if the flow function calls sendPage*? the above gives a *false*
impression of readability... but the flow might be much more complex
than this (expecially with continuations!!).
An alternative could be
<call function="blah">
<pipelines>
<pipeline name="whatever">
...
</pipeline>
<pipeline name="something_else">
...
</pipeline>
...
</pipelines>
</call>
and then flow should be restricted from calling general pipelines but
would only be able to call the ones "scoped" inside its call. For sure
it would be more procedural... but would it be more readable? And what
if I want to share the same pipeline with more calls? we could create
pipeline symlinks for external ones
<call function="blah">
<pipelines>
<pipeline name="whatever">
...
</pipeline>
<pipeline name="something_else" maps-to-uri="foo/bar/{param}/>
...
</pipelines>
</call>
Doable. But would it help?
It looks a lot like design patterns for XSLT: xslt is not hard to write
*per se* (for a programmer, I mean, once you understand it)... but it's
hard to find "good stylesheets" and it's hard to debug them because
it's hard to see the "instruction flow"... since it's a declarative
rule engine.
The sitemap goes in that direction. It is becoming more and more
declerative regarding request generation and the procedural part has
been moved away, locked in the place where it should be easier to read.
It is true, though, that currently, in the middle of the transition
stage, more and more logic is done in the pipeline components that
shouldn't be done there! There are tons of transformers and actions
doing stuff that should be done at the flowscript level (from accessing
a regular java component that gives a specific service)
But I don't think the model is wrong... it's just that the current
component set grew out of the pressure of a different environment with
different limitations... flow is going to change this and will also
make patterns emerge.
> I'm not negative on flow, and not positive on actions - just pointing
> out a loss of readability of the sitemap that has resulted from our
> move forward.
In italian we say this is the classic "problem of the small blanket":
you can't cover everything with one solution, you cover one part and
you uncover another.
It is true that flow separates things and make it harder to understand
what pipelines make action of a single resource production. the cocoon:
protocol makes thing even worse.
It is entirely possible to come up with a debugging view of the cocoon
execution that shows the trace of all the stages that happened in the
creation of a cocoon pipeline. This is something that we'll have to do,
also to be able to do a serious "inverted cache".
Also, the original sitemap readability is not compromised in case you
don't need flow. And if you do, using actions will not make things more
readable... just more limited. (it is entirely possible to come up with
a flow equivalent of actions that is just as readable, by introducing a
simple URI-space pattern for pipeline matching)
> So actually, I'll say I'm -.5 on the need to enforce this at all.
As a rule, we should restrict everything that we can't come up with a
reason to make it possible, then keep listening for people that could
come up with those reasons.
Today, no reason has been proposed, so it's good to close it.
Allowing something just for the sake of freedom has harmed us in the
past (expecially in the migration to the treeprocessor), so we
shouldn't allow further harm.
> --
Stefano.
Using a generic sitemap + flow (was: Makes flow script the sitemap
ugly?)
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Hi:
I read the lastest comments about flow and I want to share with the rest
of you my own experiences.
We are developing database oriented webapp. We are using, well I will
repeat it again :-), Flow+Woody+OJB, JXGenerator and Druid.
And I think Flow help us in the SoC. I will try to explain it:
1-Main sitemap: Just declare all the components that the application need.
Here we have all the <map:components> + some pipelines that manage:
a) transition to business objects (subsitemaps)
b) All the common resources: images (*.gif, *.png), *.css, *.js (client).
c) Handle errors.
In the main sitemap you will not find any flow script at all.
2-"Business Object": They contains all the forms needed to manage the
particular object inside the webapp. Each Businnes Objects have the same
structure. Also they have the same sitemap. That way we don't need to
create a new sitemap every time we start one Business Object. You can also
have other forms (for example "list" not showed in the below sample). Here
is the structure of each business object:
ModuleName
+--- forms
| +--- create
| | +--- bind.xml
| | +--- definition.xml
| | +--- flow.js
| | +--- template.xml
| +--- search
| +--- remove
| +--- update
+---sitemap.xmap
Every business object has his own BOH (Business Object Handler) written in
Java. The BOH is used inside the flow. The BOH contains all the functions
needed to manipulate beans used in the forms of the Business Object. The
BOH must contains the CRUD operations related to the object.
All BOHs are almost similars thanks to OJB-JDO.
The underlying part of the O/R mapping is done using Druid (hey?! here is
again Druid!).
Here is some flow script:
**********************************************************************
Create:
**********************************************************************
function createform(form) {
form.showForm("create-form-display");
var factory = cocoon.getComponent(Packages.o.a.c....JdoPMF.ROLE);
var bean = new Packages.test.forms.area.Bean();
var handler = new Packages.test.forms.area.Handler();
form.save(bean);
handler.insert(bean, factory);
cocoon.releaseComponent(factory);
success("Areas", "Area procesada con éxito",
"¿Desea procesar una nueva área?","create");
}
**********************************************************************
Search:
**********************************************************************
function searchform(form) {
form.showForm("search-form-display");
cocoon.sendPage("list",
{"criteria" : form.getWidget("criteria").getValue()});
}
**********************************************************************
List:
**********************************************************************
function listform(form) {
var factory = cocoon.getComponent(Packages.o.a.c.....JdoPMF.ROLE);
var bean = new Packages.test.forms.area.List();
var handler = new Packages.test.forms.Handler();
var criteria = new String (cocoon.request.criteria);
handler.getList(bean, criteria, factory);
form.load(bean);
form.showForm("list-form-display");
var nuevoBean = new Packages.test.forms.area.List();
form.save(bean);
handler.setList(bean, criteria, factory);
cocoon.releaseComponent(factory);
success("Administración de Areas", "Actualización de Áreas",
"Todos los cambios se procesaron existosamente. ¿Desea volver a
procesar la lista de áreas?", "search");
}
The sitemap looks:
<map:flow language="javascript">
<map:script src="forms/create/flow.js"/>
<map:script src="forms/search/flow.js"/>
<map:script src="forms/list/flow.js"/>
</map:flow>
<map:pipelines>
<!-- Woody forms display -->
<map:pipeline internal-only="true">
<map:match pattern="*-form-display">
<map:generate src="forms/{1}/template.xml"/>
<map:transform type="woody"/>
<map:transform type="i18n"/>
<map:transform src="context://stylesheets/agssa.xslt"/>
<map:transform src="context://resources/woody/woody-styling.xsl"/>
<map:transform type="encodeURL"/>
<map:serialize/>
</map:match>
<!-- jx forms -->
<map:match pattern="ver-form">
<map:generate type="jx" src="forms/ver.xml"/>
<map:serialize/>
</map:match>
</map:pipeline>
<!-- Manejo de las continuaciones -->
<map:pipeline>
<map:match pattern="*.continue">
<map:call continuation="{1}"/>
</map:match>
<!-- Crea el flow -->
<map:match pattern="*">
<map:call function="woody">
<map:parameter name="function" value="{1}form"/>
<map:parameter name="form-definition"
value="forms/{1}/definition.xml"/>
<map:parameter name="bindingURI" value="forms/{1}/bind.xml"/>
<map:parameter name="attribute-name" value="{1}form"/>
</map:call>
</map:match>
</map:pipeline>
</map:pipelines>
We are still developing this idea. The "Business Objects" modules and the
best generic structure for them in any webapp.
If we found it, then we will try to develop a tool for building database
oriented webapp using Cocoon. We tought the start must be the form
definition. Based on the form definition the tool will generate the
database script, the woody forms, the java classes, the O/R mapping etc.
It would be very nice, is it? Here again, I see druid as an important part
of the overall tool helping us in the database arena.
We are now developing 2 webapp at the same time and we are trying to
follow some technics that will help us in the automatization of the code.
Under this approach we don't see to the sitemap as the most dynamic part
of the application. Or maybe?
As I told you I am lazy enough to write the same code over and over just
changing some names. :-D
Comments are welcome.
Best Regards,
Antonio Gallardo.
Re: Makes flow script the sitemap ugly?
Posted by Sylvain Wallez <sy...@apache.org>.
Joerg Heinicke wrote:
> On 11.11.2003 15:48, Geoff Howard wrote:
>
>> In fact, I think that flow in some cases needlessly complicates the
>> composition of a pipeline. Now I have to have two pipelines where I
>> used to need one. I have to have one that matches the external
>> request and calls the flow function, and another one for the default
>> result of that pipeline.
>
>
> I have exactly the same feeling about the flow. I talked about exactly
> the same with Sylvain in private communication (btw: Did you ignore my
> last email or didn't you receive it, Sylvain. I sent it on the day you
> had problems with Anywhere mail to your Apache account - which is
> probably forwarded to Anywhere :-( ).
I received it, but was so swamped with work and mail problems that I
failed to answer...
> In German slang I would call the flow "drangepappt". How can this be
> translated into English: The flow is not integrated into the sitemap
> very well and makes the sitemap flow somewhat opaque or obfusicated.
> How must look into the flow to understand what's going on in the
> sitemap. And if it is so why not integrating the flow script into the
> sitemap directly? No, I don't want to have Javascript in the sitemap,
> it's only a bad feeling about that. Especially because of the two-side
> dependency from sitemap to flow to sitemap.
>
>> So far this has felt like needless additional complexity to me (and I
>> think will to others).
>>
>> To try to make this point a little clearer:
>> Part of the beauty of the sitemap prior to flow was that you could at
>> a glance see what each request url was triggering. Now, I look at
>> the sitemap, have to locate the flowscript, parse through it for the
>> various sendPage etc. and then back to the sitemap to find where the
>> action really happens. This could perhaps be handled with some best
>> practice naming conventions. Perhaps a practice of passing in the
>> various possible view uris to the flowscript should be considered. I
>> don't know.
>
>
> Naming conventions is to weak to handle this IMHO.
Exactly. My personal way of doing things is very close to Antonio's:
here's a typical sitemap of my flow+woody applications:
<map:pipelines>
<!-- internal URIs -->
<map:pipeline internal-only="true">
<map:match pattern="_view-*.html">
....
</map:match>
</map:pipeline>
<!-- public URIs -->
<map:pipeline>
<map:match pattern="edit-*.html">
<map:select type="request-method">
<map:otherwise>
<map:call function="public_{1}"/>
</map:otherwise>
<map:when test="POST">
<map:call continuation="{request-param:continuation-id}"/>
</map:when>
</map:select>
</map:match>
.... other matchers...
</map:pipeline>
</map:pipelines>
Several noticeable things:
- internal pipeline is placed first. It makes things faster, as it's
checked first for internal request, and ignored for external ones
- "_" prefix for internal URIs avoids most name clashes with external URIs.
- prefixing externally-callable flow functions with the "public_" prefix
(or something else) prevents hackers to call non public flow functions
- Distinguishing call/continue with the request method allows to have
<form action="">. This is convenient when writing form templates and
keeps the browser location bar clean (the address doesn't change)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Makes flow script the sitemap ugly? (was: Re: [vote] forbidding flowscripts
with no sendpage redirects)
Posted by Joerg Heinicke <jh...@virbus.de>.
On 11.11.2003 15:48, Geoff Howard wrote:
> In fact, I think that flow in some cases needlessly
> complicates the composition of a pipeline. Now I have to have two
> pipelines where I used to need one. I have to have one that matches the
> external request and calls the flow function, and another one for the
> default result of that pipeline.
I have exactly the same feeling about the flow. I talked about exactly
the same with Sylvain in private communication (btw: Did you ignore my
last email or didn't you receive it, Sylvain. I sent it on the day you
had problems with Anywhere mail to your Apache account - which is
probably forwarded to Anywhere :-( ). In German slang I would call the
flow "drangepappt". How can this be translated into English: The flow is
not integrated into the sitemap very well and makes the sitemap flow
somewhat opaque or obfusicated. How must look into the flow to
understand what's going on in the sitemap. And if it is so why not
integrating the flow script into the sitemap directly? No, I don't want
to have Javascript in the sitemap, it's only a bad feeling about that.
Especially because of the two-side dependency from sitemap to flow to
sitemap.
> So far this has felt like needless
> additional complexity to me (and I think will to others).
>
> To try to make this point a little clearer:
> Part of the beauty of the sitemap prior to flow was that you could at a
> glance see what each request url was triggering. Now, I look at the
> sitemap, have to locate the flowscript, parse through it for the various
> sendPage etc. and then back to the sitemap to find where the action
> really happens. This could perhaps be handled with some best practice
> naming conventions. Perhaps a practice of passing in the various
> possible view uris to the flowscript should be considered. I don't know.
Naming conventions is to weak to handle this IMHO.
> I'm not negative on flow, and not positive on actions - just pointing
> out a loss of readability of the sitemap that has resulted from our move
> forward.
I can not be negative on flow, because I don't have participated in flow
discussions at that time. But it's my bad feeling about this stuff.
Any comments or flames ;-)
Joerg
Re: [vote] forbidding flowscripts with no sendpage redirects (was
Re:Saving pipeline output to a temp file...)
Posted by Geoff Howard <co...@leverageweb.com>.
Vadim Gritsenko wrote:
> Stefano Mazzocchi wrote:
>
>> On 11 Nov 2003, at 05:47, Antonio Gallardo wrote:
>>
>>> Sylvain Wallez dijo:
>>>
>>>> Let's reformulate this into a proper vote.
>>>>
>>>> Do you want to enforce the fact that flowscript calls (either
>>>> "function"
>>>> or "continuation") *must* redirect using sendPage, sendPageAndWait or
>>>> redirectTo and that, should it not be the case, a
>>>> ProcessingException be
>>>> raised?
>>>>
>>>> [ ] no, let the sitemap execution continue after the <map:call> if
>>>> there
>>>> was no redirect.
>>>
>>> [X] yes, enforce it in 2.1.3
>>>
>>>> [ ] yes, enforce it in 2.1.4
>>>
>>> Earlier means less pain in the future.
>>
>> Agreed, +1
>
> I'm -0 on "yes, enforce". Not sure why it should be disabled.
I'm the same. In fact, I think that flow in some cases needlessly
complicates the composition of a pipeline. Now I have to have two
pipelines where I used to need one. I have to have one that matches the
external request and calls the flow function, and another one for the
default result of that pipeline. So far this has felt like needless
additional complexity to me (and I think will to others).
To try to make this point a little clearer:
Part of the beauty of the sitemap prior to flow was that you could at a
glance see what each request url was triggering. Now, I look at the
sitemap, have to locate the flowscript, parse through it for the various
sendPage etc. and then back to the sitemap to find where the action
really happens. This could perhaps be handled with some best practice
naming conventions. Perhaps a practice of passing in the various
possible view uris to the flowscript should be considered. I don't know.
I'm not negative on flow, and not positive on actions - just pointing
out a loss of readability of the sitemap that has resulted from our move
forward.
So actually, I'll say I'm -.5 on the need to enforce this at all.
Geoff
Re: [vote] forbidding flowscripts with no sendpage redirects (was
Re:Saving pipeline output to a temp file...)
Posted by Vadim Gritsenko <va...@verizon.net>.
Stefano Mazzocchi wrote:
> On 11 Nov 2003, at 05:47, Antonio Gallardo wrote:
>
>> Sylvain Wallez dijo:
>>
>>> Let's reformulate this into a proper vote.
>>>
>>> Do you want to enforce the fact that flowscript calls (either
>>> "function"
>>> or "continuation") *must* redirect using sendPage, sendPageAndWait or
>>> redirectTo and that, should it not be the case, a
>>> ProcessingException be
>>> raised?
>>>
>>> [ ] no, let the sitemap execution continue after the <map:call> if
>>> there
>>> was no redirect.
>>
>> [X] yes, enforce it in 2.1.3
>>
>>> [ ] yes, enforce it in 2.1.4
>>
>>
>> Earlier means less pain in the future.
>
>
> Agreed, +1
I'm -0 on "yes, enforce". Not sure why it should be disabled.
Vadim
Re: [vote] forbidding flowscripts with no sendpage redirects (was Re:Saving pipeline output to a temp file...)
Posted by Stefano Mazzocchi <st...@apache.org>.
On 11 Nov 2003, at 05:47, Antonio Gallardo wrote:
> Sylvain Wallez dijo:
>> Let's reformulate this into a proper vote.
>>
>> Do you want to enforce the fact that flowscript calls (either
>> "function"
>> or "continuation") *must* redirect using sendPage, sendPageAndWait or
>> redirectTo and that, should it not be the case, a ProcessingException
>> be
>> raised?
>>
>> [ ] no, let the sitemap execution continue after the <map:call> if
>> there
>> was no redirect.
> [X] yes, enforce it in 2.1.3
>> [ ] yes, enforce it in 2.1.4
>
> Earlier means less pain in the future.
Agreed, +1
--
Stefano.
Re: [vote] forbidding flowscripts with no sendpage redirects (was
Re:Saving pipeline output to a temp file...)
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Sylvain Wallez dijo:
> Let's reformulate this into a proper vote.
>
> Do you want to enforce the fact that flowscript calls (either "function"
> or "continuation") *must* redirect using sendPage, sendPageAndWait or
> redirectTo and that, should it not be the case, a ProcessingException be
> raised?
>
> [ ] no, let the sitemap execution continue after the <map:call> if there
> was no redirect.
[X] yes, enforce it in 2.1.3
> [ ] yes, enforce it in 2.1.4
Earlier means less pain in the future.
Best Regards,
Antonio Gallardo
Re: [vote] forbidding flowscripts with no sendpage redirects (was
Re: Saving pipeline output to a temp file...)
Posted by Joerg Heinicke <jh...@virbus.de>.
On 10.11.2003 21:15, Sylvain Wallez wrote:
> Let's reformulate this into a proper vote.
>
> Do you want to enforce the fact that flowscript calls (either "function"
> or "continuation") *must* redirect using sendPage, sendPageAndWait or
> redirectTo and that, should it not be the case, a ProcessingException be
> raised?
>
> [ ] no, let the sitemap execution continue after the <map:call> if there
> was no redirect.
> [X] yes, enforce it in 2.1.3
> [ ] yes, enforce it in 2.1.4
If it's not to complicated to enforce, i.e. if it does not possibly
break other code.
Joerg
Re: [vote] forbidding flowscripts with no sendpage redirects (was
Re: Saving pipeline output to a temp file...)
Posted by Sylvain Wallez <sy...@apache.org>.
Sylvain Wallez wrote:
> Let's reformulate this into a proper vote.
>
> Do you want to enforce the fact that flowscript calls (either
> "function" or "continuation") *must* redirect using sendPage,
> sendPageAndWait or redirectTo and that, should it not be the case, a
> ProcessingException be raised?
>
> [ ] no, let the sitemap execution continue after the <map:call> if
> there was no redirect.
> [X] yes, enforce it in 2.1.3
> [ ] yes, enforce it in 2.1.4
>
> Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [vote] forbidding flowscripts with no sendpage redirects (was
Re: Saving pipeline output to a temp file...)
Posted by David Crossley <cr...@indexgeo.com.au>.
Sylvain Wallez wrote:
> Let's reformulate this into a proper vote.
>
> Do you want to enforce the fact that flowscript calls (either "function"
> or "continuation") *must* redirect using sendPage, sendPageAndWait or
> redirectTo
Unico added: >> or sendStatus!
> and that, should it not be the case, a ProcessingException be
> raised?
>
> [ ] no, let the sitemap execution continue after the <map:call> if there
> was no redirect.
> [ ] yes, enforce it in 2.1.3
> [ ] yes, enforce it in 2.1.4
I say ...
[X] yes, enforce it in 2.1.3
... we should nip this in the bud. Later we can always change our mind.
There could be trouble if we let it flower with the release, especially
as we know that it is an issue.
I also think that we should delay the release for this, and also
to allow us a little time to ensure that we are demonstrating
squeaky-clean best practice in our Cocoon Samples.
--David
Re: [vote] forbidding flowscripts with no sendpage redirects (was
Re: Saving pipeline output to a temp file...)
Posted by Sylvain Wallez <sy...@apache.org>.
Sylvain Wallez wrote:
> Let's reformulate this into a proper vote.
>
> Do you want to enforce the fact that flowscript calls (either
> "function" or "continuation") *must* redirect using sendPage,
> sendPageAndWait or redirectTo and that, should it not be the case, a
> ProcessingException be raised?
So far, we have the following results :
8 votes to enforce it in 2.1.3,
1 vote to enforce it in 2.1.4,
and a "-0" and "-0.5" on enforcing (Vadim and Geoff)
So, the community has decided that this should be enforced sooner than
later. Quoting Antonio, "earlier means less pain in the future".
I just committed the patch. Samples seem to behave correctly. Please
cross-check.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [vote] forbidding flowscripts with no sendpage redirects (was
Re: Saving pipeline output to a temp file...)
Posted by Ugo Cei <u....@cbim.it>.
Sylvain Wallez wrote:
> Do you want to enforce the fact that flowscript calls (either "function"
> or "continuation") *must* redirect using sendPage, sendPageAndWait or
> redirectTo and that, should it not be the case, a ProcessingException be
> raised?
>
[ ] no, let the sitemap execution continue after the <map:call> if there
was no redirect.
[ ] yes, enforce it in 2.1.3
[X] yes, enforce it in 2.1.4
Ugo
RE: [vote] forbidding flowscripts with no sendpage redirects (was Re: Saving pipeline output to a temp file...)
Posted by Reinhard Poetz <re...@apache.org>.
From: Sylvain Wallez
> Let's reformulate this into a proper vote.
>
> Do you want to enforce the fact that flowscript calls (either
> "function"
> or "continuation") *must* redirect using sendPage, sendPageAndWait or
> redirectTo and that, should it not be the case, a
> ProcessingException be
> raised?
>
> [ ] no, let the sitemap execution continue after the
> <map:call> if there
> was no redirect.
> [X] yes, enforce it in 2.1.3
> [ ] yes, enforce it in 2.1.4
--
Reinhard
Re: [vote] forbidding flowscripts with no sendpage redirects (was Re: Saving pipeline output to a temp file...)
Posted by Bertrand Delacretaz <bd...@apache.org>.
> Do you want to enforce the fact that flowscript calls (either
> "function" or "continuation") *must* redirect using sendPage,
> sendPageAndWait or redirectTo and that, should it not be the case, a
> ProcessingException be raised?
>
> [ ] no, let the sitemap execution continue after the <map:call> if
> there was no redirect.
> [X ] yes, enforce it in 2.1.3
> [ ] yes, enforce it in 2.1.4
- Bertrand