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.This discussion has clearly digressed into a subjective discussion about names. So -0 to any name changes.
What do others think ?
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
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
