cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: [Vote] Controller/Sitemap integration
Date Thu, 17 Jul 2003 15:10:15 GMT

Reinhard Pötz wrote:
> As I have been confused by all those suggestions you can find a summary
> here: 

nice, helps controlling my confusion as well

> After the discussion and all your opinions I would prefer:
> Integrating the flow processor/engine:
> --------------------------------------
> <map:flows>
>   <map:flow name="js" type="javascript">
>      <script src="flow/PetStoreImpl.js"/>
>      <script src="flow/petstore.js"/>
>   </map:flow>
>   <map:flow name="java" type="atct">
>     <class src="org.apache.cocoon...."/>
>   </map:flow>
>   <map:flow name="fsm" type="fsm">
>     <blabla src="descriptors/fsm.xml"/>
>   </map:flow>
> </map:flows>
> ... in order to be coherent. Please note that the flow
> element only has name and type. All other things
> are IMO part of the configuration (... someone proposed
> to have a class attribute --> that's useless for e.g. the
> JavaScript implementation)


> Call a flow the first time:
> ---------------------------
> <map:call flow="[yourFlow]" type="js">
>     <map:parameter name="x" value="y"/>
> </map:call>
> I prefer "call" because this makes the most sense for me.
> But I'm +0.5 with initialize. And I like the word flow otherwise
> it is totally obscured that it is part of the flow implementation.

I find 'call' somewhat hiding the initialize/continue essence

nice idea with the @flow (gets us passed the @src discussion)

> Please note again that we need a "type" attribute again.


> ... and I don't like src because src means something different
> everywhere in Cocoon (something that can be called using the
> SoureResolver ...)
> Continue a flow:
> ----------------
> <map:continue id="..." type="js">
>    <map:parameter name="x" value="y"/>
> </map:continue>

in fact liking your @flow so much I would even get it in here to 
replace the @id:

in both cases this attribute does the same: it 'identifies' the 
'flow' to be started or continued (so going for @flow in the one 
would almost impose it on the other on the grounds of coherency, 

> Again, I don't like src (see reasons above) and we need the type
> attribute.

maybe too early to say, but I would hope that all flow-engine (or 
processor) implementations could share _one_ store of active 
FlowState's (actually I would see it as one possible 
anti-balkanization action, but people with other implementations 
in mind might have a different view)

having @type in there for now makes sense, and doesn't harm us 
since it could easily become just obsolete in the future case I'm 

> Component declaration:
> ----------------------
> I'm indifferent on this ...

me too

> --------------------------------------------------------------------
> And here a completly new alternatvie (at least for this discussion:)
> <map:flow call="" type="js" >
>    <map:parameter name="x" value="y"/> 
> </map:flow>
> and
> <map:flow continue="" type="java" >
>    <map:parameter name="x" value="y"/> 
> </map:flow>
> This makes for me the greatest sense because you still know that you
> deal
> with flow and this is not obscured by call, continue, initialize or
> whatever.
> Perhaps, this would make a renaming of the declaration in
> <map:flows>...</map:flows>
> necessary.
> What do you think?

I like the ones above more, with only the slight remarks
(just added some to the wiki to reflect)

My list then becomes:
Integrating the flow processor/engine:
   - V2 : flows/flow/(@type,@name)/*

Call a flow the first time:
   - V2 : initialize/(@flow,@type)/paramaters

Continue a flow: (just added the option)
   - V7 : continue/(@flow,@type)/paramaters

Component declaration: (indifferent on the engine-processor)

   - V1 : FlowState(and -Manager)

> Cheers,
> Reinhard

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                        

View raw message