cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Generalizing the flow
Date Sat, 05 Jul 2003 19:25:54 GMT
Christopher Oliver wrote:

> Sylvain Wallez wrote:
>> Christopher Oliver wrote:
>> <snip/>
>>> The problem I have with the proposed changes is that they obscure 
>>> the design and use of flowscript (in order to support some other 
>>> unspecified "flow engine", which to appears to not really have the 
>>> same "interface" as the flowscript engine, IMO). To try to force 
>>> them to use the same sitemap constructs seems unnecessary and 
>>> counterproductive.
>> First of all, the usual disclaimer, as the continuation-based flow 
>> script has unfortunately become a kind of religion in Cocoon : I love 
>> the flowscript and continuations, and I do use it for real-world 
>> applications. But I'd also like other "religions" to be able to exist.
>> Now back to the discussion...
>> What is the more obscure :
>> - "Intepreter" or "FlowEngine" ? "Interpreter" is something that 
>> interprets a language, and not something that drives the application 
>> flow. 
> Interpreters are things that have "functions" and "continuations". 
> What are "FlowEngines" exactly? 

A FlowEngine is something that's able to manage a flow that drives the 
user through a series of pages. Is it mandatory to use an interpreter 
for this ?

>> - "WebContinuation" or "FlowState" ? Continuations are a particular 
>> implementation of a way to store the flow state. 
>> - <map:call function> or <map:call flow> ? "function" is a related to

>> entry points in a functional language. How does this relate to 
>> application flow ? 
> With Flowscript, the application (page) flow _is_ actually defined by 
> a functional programming language. That's the whole point. Your 
> proposed name changes obscure this, IMO. 

That's the point : "with FlowScript". Let's translate this sentence to 
another domain : "with XSLT, document processing _is_ actually defined 
by a stylesheet". Should we name transformers "stylesheets" ?

>> - <map:call continuation> or <map:call state> ? Again, "continuation"

>> is a particular implementation of the flow state.
> Well, right now it's the key concept that makes Flowscript possible. I 
> think it's a little more than a mere implementation detail.

Of course, continuations make _FlowScript_ possible. But what is a 
continuation ? Isn't it the implementation of the flow state in 
FlowScript ? What about other implementations ?

>> I really think the proposed changes better represent the real 
>> concepts behind the flow stuff rather than the current names which 
>> are more related to the particular implementation we have today.
>> What do others think ?
> This discussion has clearly digressed into a subjective discussion 
> about names. So -0 to any name changes. 

Names are one of the most important things in design, since it's first 
through the names that a user goes into a set of classes. Bad names 
imply wrong understanding. Abstractions named after a particular 
implementation make other implementations look clumsy, since they don't 
fit into the name, even if they fit into the real underlying concept.

Answering to your other post also :

> Then I don't undertand what you're talking about. It is not possible 
> to provide a "flow implementation" in the sense that I understand it 
> in "plain old Java". But I'm also not interested in pursuing this 
> discussion any further. There's a lot of work still to be done on the 
> current flow implementation, and what time I have I plan to spend on 
> that.. 

Ok. So let's make it simple : a page flow is about driving the user 
through screens, each transition depending on the current state of the 
application. There are other means than a continuation-enabled 
interpreter to drive page flow and keep application state. The names 
currently used to represent the flow-related concepts are too much 
related to this particular implementation.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message