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.
<handle-errors/>
>>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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
