cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: defaulting to a matcher when another one is not present
Date Sat, 12 Oct 2002 23:44:56 GMT

Hunsberger, Peter wrote:
>>>Is this necessary?  Probably not.  
>>In fact, in the above scenario it isn't.
> How would you suggest handling it with Cocoon today?  

Since you *have* to define up front between groups which URLS to use, 
and define them with no general rule, simply make a FixedListMatcher 
that matches based on fixed names in a list, so that you don't need an 
expert system and just need to update a list.

This will also be a bonus, since you will finally have written down some 
documentation of your messy URI space :-P

>>>Is there any reason not to allow it?
>>>Probably not.
>>Let me disagree.
>>A sitemap is a *contract*.
> Well that's the basis for the disagreement.  I don't believe a sitemap
> should always be a strict contract, a sitemap should be a set of rules about
> to handle URIs.  If these rules can be strictly encoded and enforced all for
> the better, but if they can't I'd still like to be able to handle the
> situation gracefully.


>>It defines the URI space of your site, and URIs are hierarchical in
>> nature.
> Even though the semantics of a URI are hierarchical, there's no need for the
> mapping to business logic also be restricted to be hierarchical. 

I never said that.

>>If you define the URI space *outside* of the sitemap ("but those can be 
>>resolved through negotiation between the two sections") you are 
>>effectively reducing the usefulness of the sitemap.
>>Since splitting URIs between groups is a rule, ie a *contract*, on the 
>>URI space, it should be evident in the sitemap itself and defined 
>>*before* the control is delegated to the subsitemaps, because it should 
>>be negotiated between the parties *before* they start adding pages and 
>>potentially stepping on their toes.
> You are still encoding the external resolution of the discussion in the
> sitemap.  The fact that the two groups agree to allow for name collision is
> part of the "contract" so to speak...   Yes it's nice to be able to code
> everything in nice provable procedural code.  Real life doesn't always work
> that way. Our real life situation is much more messy, we'll eventually have
> to code a bit of an expert system to resolve the business rules on what
> information is presented for any given URI request.  The URI itself, in our
> particular case is almost meaningless and at best only gives us hints on
> what the user thins they want to see.

Do you realise that what you are saying doesn't make sense?

" we'll eventually have to code a bit of an expert system to resolve the 
business rules "

You mean that your programmers need to be experts just to understand 
what URLs to use? And you say that enabling this way of working in 
Cocoon is a *feature*?

>>Now, given that your groups don't want to tread on each other when 
>>working, simply define the spaces they can manage in the main sitemap 
>>and the problem is elegantly solved.
>>"we don't necessarily know how they will code their URL's and we
>>  want each to have a shot at resolving any given URL."
>>Exactly what I want to avoid.
>>URI spaces must be well crafted up front, and possibly self-describing 
>>and easy to understand.
> Well, that's all fine and good.   There's nothing in the proposal that would
> stop you from creating such sitemaps.  Just don't use the optional
> allow_return="true" (or whatever) attribute when you link your sub-sitemaps.

Just because a thing is made possible doesn't mean that it should be done.
Saying "put it in, it won't stop your way" is not a solution, just a 
recipe for disaster down the road.
If we would have done it every time we got a request...

> You still haven't given me any reason why the rest of us -- who don't
> necessarily have such neatly compartmentalized worlds -- should have to
> conform to that particular sitemap model?

You don't have to.
Cocoon is opensource. Take the code, patch it, and use that.

But I still think that your way of doing it is not right, and your 
example use-case makes my opinions more strong on this.

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

To unsubscribe, e-mail:
For additional commands, email:

View raw message