cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: [Vote] Controller/Sitemap integration
Date Wed, 16 Jul 2003 21:52:22 GMT
I don't have a vote, but I have been somewhat connected to this 
thread so I thought I'ld speek up anyway...

As for the proposal Sylvain and I uttered originally I would 
consider the discussion we had on the topic after Sylvain's post 
to direct more (but not completely) into the naming-proposals 
Stephan is introducing here...

The following might seem like nagging but I do share Sylvain's 
eagerness to get names really right, so I'm wide open for other 
alternatives and views...


Stephan Michels wrote:
> 
> If I think on different implementations for the flow,
> the names are not every intuitive, IHMO.
> 
> So, can I offer some alternatives?
> 
> On Wed, 16 Jul 2003, Reinhard Pötz wrote:
> 
> 
>>  [A] The "Cocoon Advanced Control Flow" provides a controller that is
>>      linked into the sitemap (as **child element** of <map:sitemap
>>.../>:
>>
>>      <map:flow type="[yourEngine]">
>>          [configuration]
>>      </map:flow>
>>
>>      This reflects that the flow is not a *usual* sitemap resource but
>>      something else.
> 
> 
> The point, which irritates me, is that you don't have a identifier
> to address the script/whatever.
> 
> So my favorite choise will be
> 
> <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="org.apache.cocoon...."/>
>  <map:flow name="fsm" type="fsm" src="descriptors/fsm.xml"/>
> </map:flows>
> 
> So this will be coherent with the other objects.
> 

and it makes perfect sense after the recent discussions

it does go a step further and assumes we allow for more then one 
flow impl to be active at any given time

not needing to choose one impl for the complete cocoon webapp is 
still something different then making sure that implementations 
can be swapped (we had a consensus on the latter, not yet on the 
first)

but again, it makes sense all the way and IMHO assures more 
easily for a seemless integration of what is around (and thus 
making sure more of the 'related' issues will be handled in equal 
ways, making the different impl more 'alligning' then 'competing')

> 
>>  [B] The controller is called by:
>>
>>      <map:call flow="[yourFlow]">
>>        <map:parameter name="x" value="y"/>
>>      </map:call>
> 
> 
> Seems fine, an alternative will be
> 
> <map:initiate flow="js" call="[Javascript function]">
>  <map:parameter name="x" value="y"/>
> </map:initiate>
> 
> <map:initiate type="java" call="[Java method]">
>  <map:parameter name="x" value="y"/>
> </map:call>
> 
> <map:initiate type="fsm" call="[Name of state]">
>  <map:parameter name="x" value="y"/>
> </map:initiate>
> 
> I like the combination of initiate/continue
> 

yes, I stated this in another thread, looking at it from the POV 
of the sitemap there are two kinds of URI's:

1/ the ones that start/initiate a use case (of which the state is 
managed at the server side)

2/ the dynamic ones that point to states that can continue the 
process

> 
>>  [C] A state of the controller is called by:
>>
>>	<map:call state="">
>>        <map:parameter name="x" value="y"/>
>>     </map:call>
> 
> 
> We don't call states in this sense. We continue
> a continuation ;-)

actually I think we continue with the 'use-case'

or we continue the 'interaction'

> I guess <map:continue continuation="{1}"/> is bad.
> 
> <map:continue src="{1}"/>
> or
> <map:continue id="{1}"/>
> 

Still <map:continue state-id=".." /> might make sense as well?


>>  [D] All flow interpreters[3] are Avalon components and declared
>>      in the cocoon.xonf:
>>
>>      <flow-engine default="[yourController]" logger="[yourLogger]">
>>        ...
>>      </flow-engine>
> 
> 
> +1, except the name, see next.
> 
> 
>>  [E] Changes in the current Javascript implementation:
>>      - rename "Interpreter" to "FlowEngine",
> 
> 
> Again, to be coherent my favorite is
> <flow-processor> like <xslt-processor> and <xpath-processor>, or
> treeprocessor.
> 

quite indifferent here, since processor is still not catching it 
completely IMHO, but I don't have a better alternative yet :-(

> 
>>      - rename "WebContinuation" to "FlowState", and accordingly
>>        "WebContinuationManager" to "FlowStateManager".
> 
> 
> Yes, the Continuation represents a state, but to make a clear
> difference as a new concept, I think 'Continuation' is accurate.
> But 'Web..'?!
> 

I think there is two things here: interface and current 
implementation.

we should get the correct name for the abstract thing, but the 
WebContinuation could keep on existing as the 
flow-script-js-continuation thingy that just implements that 
(although some reference to js in that name would make more sense 
then?)

I still like FlowState in this context... as I said above we 
continue with the use case or interaction (rather then 'the 
continuation')... the reason why we can do that is because there 
is server side State of the Flow maintained for the current point 
in that process...

(I know State sounds like something 'passive' while the 
continue-responsibility it has points out some 'activity'... note 
however that the Flow-prefix makes up for that, and that the 
classic 'State' pattern suffers from the same, so some of us 
might be used to it)

> - rename "WebContinuation" to "Continuation", and accordingly
>          "WebContinuationManager" to "ContinuationManager".
> 
> 
> Thoughts?
> 
> Stephan Michels.
> 


regards,
-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


Mime
View raw message