cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Reinhard Poetz" <reinhard_po...@gmx.net>
Subject RE: [RT] Flow/Sitemap Integration
Date Thu, 16 Jan 2003 16:00:14 GMT
Michael Melhem / Stefano Mazzocchi wrote:

<snip>
> > ><map:sitemap>
> > >  <map:components>
> > >  </map:components>
> > >
> > >  <map:flow>
> > >    <map:script>
> > >      <src="myflow.js">
> > >    </map:script>
> > >    <map:flowmap>
> > >      <map:map pattern="login/"  flow="login"/>
> > >      <map:map type="regexp" pattern="register*/"
> flow="registerUser"/>
> > >      <map:map pattern="logout/" flow="logout"/>
> > >    </map:flowmap>
> > >  </map:flow>
> > >
> > >  <map:pipelines>
> > >    ...
> > >  </map:pipelines>
> > ></map:sitemap>
> > >
> > >We could define a flow mapping as a "matching" between a flow function
> > >and its corresponding entry point pattern (which could be an URI
> > >or whatever)
> >
> > True.
> >
> > >We could use the <map:match> directly withing the flowmap to implement
> > >this, but this would not force the user to call a flow method and would
> > >not allow for the compact easy-to-read syntax above.
> >
> > But I'm pretty sure that people *will* want to extend that and will
> > complain about the fact that <map> and <match> do, in fact, the same
> > thing, but with different semantics and this won't please people (nor
> > please my sense of semantic elegance, to tell you the truth)
>
> A map:map = map:match + map:call
>
> Im not against using <map:match> here within the flowmap...but
> I do have to ask wouldnt it suggest to the user (incorrectly) that this
> is another a "pipeline" where they can assemble anything they like?

I don't think so because the flow related stuff is outside of
<map:pipelines>...</map:pipelines>. And a second arguement: the sitemap
interpreter will not allow such constructs.

Therefore I would use following XML to declare the mappings to flow scripts.
...
</map:components>
<map:flow>
   <map:scripts language="JavaScript">
       <map:script src="scripts.js"/>
   </map:scripts>
   <map:flowmap>
      <map:match pattern="xxx">
         <map:flow call-function="xxx()"/>
      </map>
      <map:match type="request-parameter" pattern="cont-id">
         <map:flow continue-with="{1}"/>
      </map:match>
   </map:flowmap>
</map:flow>
<map:pipelines>
...

This would have following advantages:
 - reuse of the matchers
 - easier for existing cocoon users to understand the mapping
   between uri/request-parameter/what-ever  <---> flow
 - possible to submit parameters to the matcher AND to the function
 - clear separation between pipelines and flows

and
 - (as already mentioned in this thread): the <map:flow>-part should match
   before the <map:pipelines> part

... disclaimer:
I know that element/attribute names are important but my point in this mail
is the structure - so please don't discuss why I named elements this ;-)


>
> Perhaps at the implementation level <map:match> and <map:map> are
> similar, but conceptually they are different.  Using <map:map> will
> encourage the user to think of the mapping as a single atomic
> instruction and not try and "tinker" with other
> components (routing or otherwise). Hmmm....but im still in two minds
> about this. :)

What do you mean exactly?
What I *really* need is a way to redirect to a URI which is mapped to a
flowscript - which is currently possible.

> > >If we use <map:map> component (as suggested above), the question then
> > >becomes, how do we get the <map:map> component to match (URIs in
> > >the above case)?
> > >
> > >Is there a reason why we wouldnt use (under the hood) the
> > >already existing matcher components to the matching here?.
> >
> > No technical reason (that I can think of) but it's a purely
> semantical one.
> >
> > Granted that it makes sense to move the flow hooks from the pipeline, I
> > think that we should reuse semantics where it makes sense, because
> > people already made an effort to learn it and in that case we reduce
> > their need to learn new stuff.

Exactly!


> >
> > Thoughts?
>
> What about issues like backwards compatibility. If we were to get the
> the go ahead form the list to implement this, would we still allow
> flow-hooks within the pipelines sections as is the case now - for the
> sake of backward compatibility??

I think there should be a *final* vote about the semantics without
considering backward compatibilty:

 - should "flow-hooks within the pipelines" be removed?
 - names of the flow elements (scripts, call-function, continue)
 - allowing the cocoon protocol calling scripts?
  (I'm in favor of it because this could become a *really* cool feature!)

Regards,
Reinhard

>
> Regards,
> Michael
>
> >
> > --
> > Stefano Mazzocchi                               <stefano@apache.org>
> > --------------------------------------------------------------------



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


Mime
View raw message