cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: [RT] Generalizing the flow
Date Fri, 04 Jul 2003 15:37:29 GMT


reinhard_poetz@gmx.net wrote:
>>reinhard_poetz@gmx.net wrote:
>>
>><snip/>
>>
>>>If we change this we have to change this too, don't we?
>>>
>>> <map:flow language="JavaScript">
>>>   <map:script src="flow.js"/>
>>> </map:flow>
>>>
>>>-->
>>>
>>> <map:flow engine="xyz">
>>>   <map:controller src="yyz"/>
>>> </map:flow>
>>> 
>>>What do you think?
>>> 
>>>
>>
>>Although we can change the attribute of <map:flow> ("type" would be more 
>>in accordance with other sitemap statements), it's content is actually a 
>>Configuration object given to the chosen flow engine. For 
>>type="JavaScript", it fully makes sense to list script files, but other 
>>implementations could have a totally different configuration, including 
>>class names.
>>
>>Note : that's why, at the start of flow discussion (a looooog time ago), 
>>I wanted to put <map:flow> inside <map:components>, because this is 
>>actually what it is : a component definition and configuration.
> 
> 
> So you propose
> 
>  <map:flow type="JavaScript">
>     <map:??? src="flow.js"/>
>  </map:flow>
> 
> What element should replace ??? in your opinion? <map:controller ... ?
> 

The point sylvain tried to make (if I understood it)

if looking at it as a component we configure
then it would be up to the specific component to decide?

for state-automate it would probably be:
<map:flow type="InteractionInstance">
      <map:controller class="com.acme.YourClass"/>
</map:flow>


for the current js engine most likely just keeping:
<map:flow type="JavaScript">
      <map:script src="flow.js"/>
</map:flow>

makes the most sense.

> Reinhard
> 
> 
> 

Actually this was part of the discussion we didn't really want to 
open up again... given the fact that the very first reply touches 
it however we might want to wander along this path some more.


In any case, for hooking in stateless gateways the stress on 
having only one possible engine is even more limithing (feasible 
through some delegation hacking I guess)


-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