cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Flowmaps
Date Mon, 17 Jun 2002 19:31:06 GMT
Vadim Gritsenko wrote:
> 
> > From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> >
> > Stefano Mazzocchi wrote:
> 
> <snip/>
> 
> Guys, I'd like to question some of the sitemap markup also...

Great.

> > > More explicit sitemap markup
> > > ----------------------------
> > >
> > > Here is what I think would be a much better approach to connect a
> > > sitemap and a flowmap:
> > >
> > > <map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">
> > >
> > >   <map:flowmaps default="calculator">
> > >    <map:flowmap name="calculator" src="calc.js"
> language="javascript"/>
> > >   </map:flowmaps>
> 
> Is this necessary step? We do not declare like this all sitemaps we
> mount later. Why it is necessary to declare flowmaps, can't this step be
> omitted?

This is good point. See more comments below.

> > >   <map:pipelines>
> > >    <map:pipeline>
> > >     <map:match pattern="">
> > >      <map:call function="calculator('prefix','/kont')"/>
> > >     </map:match>
> > >
> > >     <map:match pattern="kont/*">
> > >      <map:call with-continuation="{1}"/>
> > >     </map:match>
> 
> Why not replace these two with something more simple/obvious and
> something which better correlates with map:mount syntax we have now?

Because I don't want the people to perceive that a 'flowmap' is just
another way to process pipelines.

In the past, I had that impression myself that this symmetry was a good
thing, but I've changed my mind: I think that flowmaps should replace
actions, not replace a subsitemap.

> Something similar to:
> 
> <map:match pattern="calc/*">
>   <map:mount-flow check-reload="yes"
>                   src="calc/calculator.xflow"
>                   uri-prefix="calc" />
> </map:match>
> 
> Here, it will be not necessary to have additional and confusing to
> newbies "kont/*" matcher. Everything below calc/ goes to flowmap, and in
> flowmap you can use e.g. calc/kont/ to indicate continuation.
> 
> And, if flowmap has map:mount notion, all necessary for the calculator
> XSPs can be served by sub-sitemap with matcher:

I perfectly see your point because this was my previous idea as well:
sitemap and flowmap both implement 'pipeline processor', one uses a
declarative markup syntax, the other uses a procedural code-like syntax.

While appealing conceptually, my FS alarms start ringing when I fear
people asking to be able to control and assemble pipelines directly from
the flowmap.

What you are proposing opens the door to major overlap between sitemap
and flowmap in functionality and this might result, in the future, to us
writing big time docos about 'best practices' that say "keep things
separate".

The approach I proposed *forces* things to be separate: there is no way
for a flowmap to assemble a pipeline, since it's not its concern. Flow
logic is anything that is not directly related to XML.

I fear that if we make the sitemap and flowmap functionally overlap
(like you are somewhat proposing with the semantics above), then we'll
have to surrender to people asking for more granular pipeline control,
then we'll have to wait years until they figure out that the sitemap is
the place to control pipelines and the flowmap is the place to control
flow logic that doesn't deal with the pipeline directly but calls them.

Of course, this is just my personal impression of the future evolution
of the concept, but I can't stop my FS alarms from ringing on this.

> > >     <map:match pattern="*.html">
> > >      <map:generate src="{1}.xsp" type="serverpages"/>
> > >      <map:serialize/>
> > >     </map:match>
> > >    </map:pipeline>
> 
> Then, flowmap directory will be self-contained.
> Isn't this simpler and more logical?

See above.

> > I think that
> >       <map:match pattern="kont/*">
> >        <map:call with-continuation="{1}"/>
> >       </map:match>
> >
> > Is unnecessary and *will* create confusion, since there is no way to
> > enforce it while using a flowmap.
> > Users will forget to write it and flood us with mails of "why doesn't
> it
> > work?".
> 
> +1 to eliminate it. I would love to see flowmaps working same way
> sub-sitemaps do.

I strongly hope you change your mind after what I wrote above.
 
> > How about:
> >       <map:match pattern="">
> >        <map:call function="calculator('prefix','/kont')
> >                  continuation-match="kont/*"/>
> >       </map:match>
> 
> As stated below, flowmaps aren't resources, hence map:call doesn't fit
> here well.

Again, map:call is not about resources but it's about jumping to another
execution point, as the 'call' word clearly implies. I see no issues in
keeping the semantic coherent.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message