Return-Path: 
 <cocoon-dev-return-28408-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 6229 invoked by uid 500); 17 Jun 2002 21:14:35 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 6218 invoked from network); 17 Jun 2002 21:14:35 -0000
From: "Vadim Gritsenko" <vadim.gritsenko@verizon.net>
To: <cocoon-dev@xml.apache.org>
Subject: RE: [RT] Flowmaps
Date: Mon, 17 Jun 2002 17:14:15 -0400
Message-ID: <01da01c21643$efa98780$0a00a8c0@vgritsenkopc>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2616
In-Reply-To: <3D0E38FA.ED70FDE6@apache.org>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> 
> Vadim Gritsenko wrote:
> >
> > > From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> > >
> > > Stefano Mazzocchi wrote:

<snip/>


> > > > More explicit sitemap markup
> > > > ----------------------------

<snip what="flowmap declaration"/>


> > > >   <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.

<snip what="mount sub sitemap from flowmap"/>


> > > 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.

I also strongly hope that we can eliminate this extra matcher and won't
trip your alarms :)

I hear your fears. Let me make second try on this. This snippet below
will allow sitemap designer to choose what method of continuation
passing he wants to use. You can use either URI matching, or Cookie
matching, or parameter matching. Here, continuation obtained from the
URI:

<map:match pattern="calc/*">
  <map:flow method="calculator" continuation="{1}" />
</map:match>

This means: start flow if no continuation is provided or continue flow
if continuation is present.

We can change wording (map:flow -> map:whatever), can change number of
arguments, etc, but my feelings is that it will be easier to use and
understand if flow requires only one sitemap "operator", but not two as
of now: map:continue and map:call.

 
> > > 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.

I agree with Nicola's argument: users might get confused if call is
loaded with one more meaning.

Or might be not...


Vadim

> --
> 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