Re: [RT] Flow/Sitemap Integration

[Stefano Mazzocchi]

Michael Melhem wrote:

On Tue, Jan 14, 2003 at 04:52:43PM +0000, Stefano Mazzocchi wrote:

Michael Melhem wrote:

Hmmm, but if we get that far, then

<flowmap>
<map type="regexp" patter="blah*" flow="blahFlow"/>
</flowmap>

isn't just syntax sugar for

<pipeline>
<match type="regexp" pattern="blah*">
 <call function="blahFlow"/>
</match>
</pipeline>

???

Hmm..Well maybe, but for the fact that flowmap section in not within the
pipeline section (which I think we agreed is what we want)
and that the treeprocessor would not allow actions or
other routing components which would otherwise be allowed within the
pipeline section.

Good point.

if we agree that something like the following sitemap syntax
is desirable:

<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?
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. :)

Me too. While I do see value in the concept of <flowmap> separation, I think that we might be closing the door to creative uses of the flow layer that might end up making the <flowmap> mappings as complex as the normal sitemap pipelines.

I'm starting to think that we should leave it as it is and see user feedback before trying to solve an issue that might not even exist.

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.

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

We are in alpha-mode for a reason. And the reason is *exactly* to try to do the *right* thing *before* we have to bind our back-compatibility effort to it.

When we designed the sitemap, it took us months to agree on the semantics and we kept moving it back and forward until nobody had anything to say about it.

I think that effort saved us a bunch of pain later on and I'm willing to follow the same path once again.

--
Stefano Mazzocchi <[EMAIL PROTECTED]>
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]