cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject SoC between flow and sitemap
Date Fri, 16 May 2003 07:52:49 GMT
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 

<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

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.

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 Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                        

View raw message