Please understand: I _do_ like flow (how could we not) there just
seem to be some unclear contracts between flow and sitemap in my
head.... (so excuse me for the maybe rant-y tone of voice here)
I hope to be fueling some discusion that might lead to clarifying
some of the contracts usefull for general web-app-development
inside cocoon (even for those not using flow maybe).. it could be
that I just overlooked some ready excisting facts of life, please
point those out then
[1] flow communicates with pipeline components behind the scenes.
(Actually it's not the only component doing so, but that should
not be seen as a justification)
sendpageandwait() sets two important objects as attributes to the
request attribute... (the continuation and the so called
bean-dict (hashmap-like 2nd argument to the function)
these get picked up by jxpathtransformer (or generator) or any
other pipeline-component that wants to use that information.
And there is my fundamental itch with this approach: those
pipeline-components are to be written to deal (exclusively) with
the quite arbitrarily manner in which these 'beans' or usefull
objects are communicated between the deciding logic (flowscipt)
and the consuming publication pipe components
While it's a perfect Model2 approach I would argue that we do NOT
want to keep these arbitrary choices (why the request object? why
the chosen attribute names?) hidden in the java implementation
source codes, yet rather have it under the control of the sitemap
editor.
<map:match pattern="...">
<map:call function="..">
<!--+
| Can we (euh, do we want to) come up with some
| mapping in here between
| - logical names of important objects produced
| inside (by) the flow script: 'continuation',
| 'bean-dict', but also script specific stuff like
| 'user-preferences', 'chat-room',...
| - and some arbitrary object-addressing-string that
| allows to formally describe in which space
| (session, application, request) and under which
| attributename that 'logical' object is to be
| stored/retrieved
+-->
</map:call>
</map:match>
I would find it logic then that those so called
object-addressing-strings (they should be quite url-like) get
reused to guide the pipeline-components to where they might find
additional information.
[2] flow decides on pipelines outside the sitemap-control.
sendPageAndWait()'s first argument points to the cocoon
publication line to use in any given instance.
If I would compare this to Actions it would pretty much be the
action that decides on the redirect to use rather then returning
a map that contains enough state-information that allows the
sitemap (with the use of more matchers, selectors and/or smart
resources) to put the correct pipeline to work.
Making this comparison, I'm in fact questioning if we wouldn't
rather put that part of binding the flow-state back to the
uri-request-space under control of the sitemap (the one in charge
of the pipes and their matching URI's in the first place?)
<map:match pattern="...">
<map:call function="..">
<!--+
| Can we (euh, do we want to) come up with some
| mapping in here between
| - logical names of publication-states the flow-script
| will want to refer to. e.g. for the
| infamous guessing game: 'guessing' and 'done' but
| in more general terms 'start', 'validation-ok',
| 'please-correct-errors',...
| - and the actual publication pipeline that should
| be used in each of those particular states.
+-->
</map:call>
</map:match>
Hm, of course we can get pragmatic about all of this: separation
of control is probably not meant to be seen as a one-on-one on
separated files? And one more contract clearly has to be mapping
an actual need.
So, It's not because the js-script and sitemap.xmap are different
files that they shouldn't be under control of the same person...
(which it nowadays needs to be as I tried to argument)
However, in this case I think there is a future for a more
ready-made reuse and even distribution of flowscipts that can be
hookep up in different existing cocoon webapps that each need to
fit it into their own uri-request-space, hopefully without the
need to change the script that is.
regards, and upfront thx for your thoughts, counter-arguments and
possible useful best practices on these
-marc=
--
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
|