You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2003/11/12 14:39:48 UTC
[RT] Is flowscript polluting sitemap readability?
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.
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