Stefano Mazzocchi wrote: > Hunsberger, Peter wrote:
<snip on stuff we agree about/> >>>>Now, if the "type" was available in the flow, you could get different >>>>resources for the same flow. >>> >>>Well, how would Cocoon know how to match? Say I ask for '/dashboard' how >>>is the pipeline going to find out where to get the parameter in order to >>>match the user-level? >> >> It would have to come from some higher level Cocoon component... > > well.. > >> Essentially you'd invert the current pipeline flow: matchers/selectors >> outside of pipeline types. > > but *why* braking everybody's sitemap when we have something else that > works perfectly with our current semantic? > >> I don't think it's currently worth spending any >> energy discussing why such a thing would be a bad idea... > > 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. 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?...) <snip on more stuff we agree on/> >> >> Seems fair enough. If that's the case then the recent issue about matching >> internal resources seems relevant: shouldn't flow also match internal >> resources? > > Yes, and AFAIK it does. Someone had posted that they couldn't get it to work. Hadn't heard more since.... >>>Agreed. One way of solving this would be to have a way to generate a >>>flowscript out of a cocoon:/ pipeline. But we haven't decided if that is >>>a good thing or is FS. >> >> Well I can certainly see how it might be nice to generate your language >> dependant URI matching automagically... > > Well, it's damn easy to do it right now with a custom i18n-aware matcher: > > <map:match type="i18n" src="mail"/> > > then this "i18n" matcher has a lookup table like this > > <uri name="mail"> > <alternate lang="EN">mail</alternate> > <alternate lang="IT">posta</alternate> > <alternate lang="FR">poste</alternate> > ... > </uri> > > There is no need to alter the sitemap semantics for this and no need to > have the flow involved. > > Damn, that's exactly the reason why I wanted pluggable matchers. Are you saying this as a good thing or as a bad thing? Is there a problem going forward? > 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. <snip on more agreement/> >> Yes, I agree. It seems that there is a real reason for indirect URI mapping >> from flow to pipeline, but no real reason to allow multiple types of >> indirection. As such, the addition of map:map isn't needed, you can achieve >> the same thing by adding a new attribute to the existing pipeline. IE: >> >> <map:match pattern="login/" flow="login"> >> ... >> </map:match> >> >> But then the question of what to do with actions remains, (it seems too >> early to deprecate them ;-)... > > Oh, I totally agree here. > >> The other new question is now; is the "flow" attribute in the above a unique >> name (as per my original assumption), or in fact a pattern? > > 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. Of course I'll probably always wonder if there aren't multiple types of URI matching... --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
