thomas wrote:
--On Freitag, 13. Mai 2005 12:07 Uhr +0200 Sylvain Wallez <[EMAIL PROTECTED]> wrote:
3 years ago, the cocoon devs were discussing "flow maps", and addition to
the sitemap to define page flow using an XML grammar. We always ended up
with verbose XML languages having control structures (the infamous "if"),
and then some people came with continuations, at first is Scheme (a Lisp
dialect - eck!) and then Javascript, and later pure Java.
Having a real programming language allow to *very easily* write complex page flows, as you can use all the language's features for control structures, and simply use regular variables to store the interaction state. Amazingly easy and powerful.
The main advandage I see to a declarative approach is that it allows to build visual tools (i.e. graphical editors) to design the flow. But the underlying XML files are very likely to be a real mess in realworld complex use cases.
Note however that Cocoon's flow engine is pluggable and that we have 3 versions of it today: - flowscript, using Javascript to define the flow (business logic should be kept in Java) - javaflow, a pure java implementation - apples, an experimental implementation (used in Daisy IIRC) which may be actually closer to Spring's approach.
as i understood it the results of a flowscript-operation don't generate sax-events. so you can use flowscript only at the end of a pipeline. is that true?
Yes, a flowscript doesn't generate sax events, and no, it doesn't come at the end of a pipeline. Rather the contrary, as the flow is the controller in the MVC (model - view - controller) pattern.
Actually, Cocoon is sometimes called "MVC+" as it has two levels of controlers:
- a level is the sitemap, a controller that maps requests to some processing (be it a flow call or a pipeline)
- another is the flow, which manages the interaction of the user with the business logic across successive pages.
So the flow takes some decisions according to the application state, and then calls a pipeline using an internal request (i.e. using the "cocoon:" protocol).
and is it equally true for all 3 flow-implementations mentioned above?
Yes, they all behave similarily: do some stuff and call a pipeline. They differ either in the programming language used or in the way interaction state is saved across requests.
in that case i would think that some logic within the sitemap (the infamous "if") wouldn't be so bad (for very comlex problems one could still decide to leave the sax-stream and use flows). but i might very well overlook something obvious or essential.
Actually, there are some ifs already in the sitemap: <map:match>, <map:act> and <map:select> are control structure, and are similar to an "if" or a "switch". But the purpose of these control structure is to allow some simple conditional building of pipelines, and complex conditions should be computed at the controller level, i.e. in the flow.
Sylvain
-- Sylvain Wallez Anyware Technologies http://apache.org/~sylvain http://anyware-tech.com Apache Software Foundation Member Research & Technology Director
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
