Hunsberger, Peter wrote:
Stefano Mazzocchi wrote:
Then don't propose it.
I don't think I will!  However, when doing architecture you always have to
ask if inverting a control flow makes sense; sometimes abstractions suddenly
become obvious or new use cases jump out.
Oh totally. That's why I take time replying to your messages even if they might sound too "devil's advocate"-ish to many here. ;-)

If one was to do such a thing
with the Cocoon sitemap obviously you'd have to allow the current semantics
to continue to work so you'd introduce some complete new concept (what's the
inversion of a pipeline?...)
Not only that. Everytime you add a new construct you are not adding just *one*, but you are adding all possible combinations of that construct with everything that was there already.

This is why I'm always *very* careful about adding new functionality.

Damn, that's exactly the reason why I wanted pluggable matchers.
Are you saying this as a good thing or as a bad thing?
The sitemap components interfaces were designed so that concerns remain separate. From that point on, I'm happy with *anything* that comes out of that. That means: I'm happy about people experimenting new functionality by adding more components that fit the architecture.

I tend to me a little more nervous when people try to force the architecture to do stuff that it can already do but in other ways that break back-compatibility.

Is there a problem going forward?
Not at all!

You can have the equivalent of mod_spelling as a matcher as well... or you could have that table stored into a database... it's up to your matching logic.

But matching is a special concern and I want to keep that separate from flow and other sitemap components.

Sounds very good to me.
Good.

If that was a patter, that would mean that you'd be calling possibly more than one function in the flowscript at the same time and I would *NOT* like this.
That makes sense (I was assuming first match wins, but I can't see a reason
to support it). In that case, you're back to my original assumption: unique
names and you can hash map the whole works.
Yep.

Of course I'll probably always
wonder if there aren't multiple types of URI matching...
Totally, that's exactly the reason why the entire URI matching logic is pluggable and not built into the sitemap.

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



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

Reply via email to