cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [RT] Generalizing the flow
Date Fri, 04 Jul 2003 16:02:40 GMT
Vadim Gritsenko wrote:

> Sylvain Wallez wrote:
>
>> Vadim Gritsenko wrote:
>>
>>> Sylvain Wallez wrote:
>>>
>>>> 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.
>>>
>>>
>>> Was it Stefano who was against pluggable flow engines? IIRC, that's 
>>> why it did not made into map:components... 
>>
>>
>> If the flow engine should not be pluggable, why does <map:flow> have 
>> a "language" attribute ? 
>
>
>
> To allow Python flow implementation? :) 


Oh no, that damn snake again ;-)

> But (as I understood it) it would have the same FOM as JavaScript 
> implementation, thus flow will be essentially same, only language is 
> different.


We can make here a parallel with XSP (IIRC, you wrote the Python 
version) : each target language provides the same <xsp:xxx> elements, 
but their implementation has been done independently for each of these 
languages (through the various xsp_[lang].xsl). The same applies to flow 
: each implementation should provide a consistent implementation of the 
FOM (currently specified in IDL).

Now things can be different, however, for implementations that use the 
same high-level concepts (a flow engine or a ServerPages generator) but 
a different approach, such as flow engines driven by an existing 
back-end. But these ones will be application-specific and won't be 
present in Cocoon's CVS. But the important point is that Cocoon should 
not prevent them to exist where needed.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com



Mime
View raw message