----- Original Message -----
From: "Stefano Mazzocchi" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, December 11, 2001 3:03 PM
Subject: Re: [RT] Managing Flow and Resources
<snip/>
> I think you are oversimplifying: I agree with you that actions and
> action-sets are something that should not be in the sitemap (I always
> found strident the different degree of reuse you had with pipeline
> components and actions), but at the same time, the current sitemap
> semantics is IMO very well designed for stateless publishing needs,
> which still are the great majority of the web resources.
IMO Actions are needed in the pipeline.
Sometimes you want to apply actions to a whole "class" of pipelines,
not only to the current flowing "instances".
For example, for access control or single routine db actions they
are good.
The problem arises when the interaction is more complex than
a simple request-response.
Sessions take care of the data part, flowmaps or such should
take care of the flow part.
> > A pipeline describes how an input document should be transformed to
> > HTML/WML etc, and nothing else. No actions, no redirects, no
> > programming at the pipeline level.
No redirects, ok.
No programming, ok.
No actions... not sure.
> In fact, the name "sitemap" is exactly that: 'a map for the site'.
>
> When Pier and I designed the concept, we had the feeling that it was
> possible to separate the concer of 'mapping resources' and assembling
> the pipelines that generate them, from that of programming the flow
> between the different resources.
>
> Since we couldn't find an elegant way to add these capabilities (at that
> time, we were thinking about letting Turbine take care of that part!) we
> decided to postpone further design.
>
> Unfortunately, since flow-driving instructions are required even for the
> most simple restriction-based publishing system, the need for headless
> programmatic activity emerged, and the Turbine Action concept was ported
> over to Cocoon.
>
> Giacomo knows that I never really liked this approach, but I didn't stop
> the effort because I wasn't able to provide a more elegant solution.
>
> Interesting enough, what you described in your above example is exactly
> the kind of 'flowmap' that I've been looking for in order to move away
> actions from the sitemap.
>
> I knew that the intrinsic 'wait for request' behavior of the site forces
> the sitemap to follow a declarative approach, as much as the 'drive the
> flow' behavior of a web application would force the flowmap to follow a
> more procedural approach.
Very good explanation.
Anyway, I would be careful on procedural programming...
Declarative can be much more powerful if well done; sometines
procedural gets stuck in defining many cases... they deal different
_aspects_ of the programming problem, they are orthogonal.
When you do class diagrams in UML, they are quite clear.
Use-case are not much more complicated.
But when you diagram all the calls (procedural), it gets really
incomprehensible sometimes.
Sometimes running behind the user gets too complicated, usually
it's better to just do things when the data is ready, who cares where
it came from. I want to send all params and get a result, why
do I have to follow your flow. Constrained flow should be kept
to minimum! Less flow constraints, less problems in maintaining.
Of course, apart when flow constraining is part of the semantics
of the transactions, in this case it's the opposite.
Many times a declarative pipeline that stops at different points
until state is correct is enough.
If the flow is linear, better keep it declarative.
Oh my, got carried away ;-)
> Even more: since the sitemap might be written by people used to publish
> information and documents, the XML syntax is more suited for their
> skillset. At the same time, since the flowmap is written by people used
> to write programming languages, a java-like syntax is better suited for
> their skillset.
+1
> In this vision, Berin's proposal to make pipelines reusable by adding
> variable substitution might allow both sitemap and flowmap to use sort
> these pipeline definitions (pipemaps?) and reduce overall verbosity.
>
> Anyway, I think that by trying to prove the Flowmap concept wrong,
> Ovidiu gave us the best example of a flowmap in terms of syntax
> (code-based instead of XML-based) and functionality (continuations-based
> instead of FSM-based).
;-)
> > If you need to describe logic, you do it using the language. This
> > describes which pages are sent in what order. When you want to
> > generate a result, you call send-page() with the source document, a
> > pipeline definition that should process your document, and additional
> > data to be used in generating the source page dynamically.
> >
> > To generate the source document, it's better if we use a markup
> > language that prevents users from doing computations in the page. The
> > page should be generated only from data passed to the pipeline by
> > send-page(). I haven't used it before, but Velocity seems to be a good
> > fit for this, as it doesn't allow any embedded processing in the page.
>
> Since Cocoon content will always be XML-ized, I see two possible
> solutions here:
>
> 1) use XML-orthogonal solutions (Velocity)
>
> <p>Today is ${date}</p>
>
> 2) use XML-namespaced solutions
>
> <p>Today is <dxml:date/></p>
>
> Again, the semantics are exactly the same, but the first approach if
> more friendly to code writers, the second to HTML writers. We could even
> have both and let the user decide which one he/she like the best.
>
> > With this model we have the clear separation of concerns. Each layer
> > does only the things it's supposed to do, in a clean way.
>
> Absolutely:
>
> sitemap -> handles the stateless needs
> flowmap -> handles the statefull needs
Actions are not statefull... they can stay in the sitemap.
> Add a simple and effective way to pass data from the *maps to the
> pipelines and into the content XML files and we are done.
Yup.
Nicola Ken Barozzi These are the days of miracle and wonder...
...so don't cry baby, don't cry
<[EMAIL PROTECTED]> Paul Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
