cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <>
Subject RE: defaulting to a matcher when another one is not present
Date Mon, 14 Oct 2002 16:34:45 GMT
>> 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.

No you don't have to define up front what groups use what URIs.  That's the
whole point of using sub-sitemaps.  All I have to define is what part of a
pattern each group uses.  It's up to the groups to define what URIs to use,
not me.  I don't want to be in charge of this; I don't want anyone in our
group to be in charge of this.  I want the end users to work the URI
mappings out between them and I want the sitemap to still work when they
decide that one groups URIs overlaps the root of another groups URI.  The
fact that I give them default sub-sitemap matchers of "IT*" and "Stats*"
shouldn't be their problem if they decide that IT has a good reason to match
"StatsSomethingStrange" for some specific URI. 

Once again, I ask you to tell me how to handle this situation with Cocoon as
it currently sits?

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

Again, the problem of what URIs are handled where is their problem, not
mine.  The other groups are the ones that have to document it, not the
people setting up the "web server" as they regard the whole system.  I can't
document it in the sitemap, they have to document it via the political
negotiations that occur between the two groups (and probably do so in
copious minutes every second Thursday morning...)

>> 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
>> to handle URIs.  If these rules can be strictly encoded and enforced all
>> the better, but if they can't I'd still like to be able to handle the
>> situation gracefully.
> <handle-errors/>

Throwing an error is not graceful behavior as far as an end user is
concerned when they have every reason to expect their URI mapping to work!

>>>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
>> mapping to business logic also be restricted to be hierarchical. 
> I never said that.

No, but that's what you're implying.  This would be reasonable if all we
where talking about was URIs.  But the fact is that sitemaps encode more
than just URIs; they include matchers that can extract behavior from
session, request, and a multitude of other Cocoon components.

>> 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
>> 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
>> that way. Our real life situation is much more messy, we'll eventually
>> 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
>> particular case is almost meaningless and at best only gives us hints on
>> what the user think 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*?

Actually, in our particular case understanding what URI to use it dead
simple.  There's only about a dozen.  Understanding what data will
subsequently be displayed will in fact take experts in a multitude of areas.

It seems to me that you are expecting that there is a one to one mapping
between a URI and what data is displayed on the screen.  In many cases that
isn't possible.  We work in a research environment; if we knew precisely
what data was needed to meet any request in the future it probably wouldn't
be research anymore...  Instead, we have to allow for URIs that are
in-themselves ambiguous and use other ways to determine what data is
subsequently displayed on the screen.  The other methods require a complex
evaluation of security authorization rules combined with patient privacy
rules and clinical treatment protocol rules.  Just looking at the URI can't
possibly tell you everything about what is to be displayed. Trying to encode
all such possibilities in a URI would be futile.

If you stop to think about it you'll realize this is true for almost any
system other than simple static screen displays:  what data is presented is
based on session values, or request values, or cookie values, or whatever.
As such, saying that a URI map should _always_ be required to be
deterministic is nonsense.  There may be very good reasons for a sub-sitemap
to look at other values associated with a URI and reject the handling of
that particular URI.  There may be very good reasons why some other
sub-sitemap could then subsequently handle that particular case. If I have
to code all the matching rules in the parent sitemap I've defeated the
purpose of the sub-sitemaps.

>> Well, that's all fine and good.   There's nothing in the proposal that
>> stop you from creating such sitemaps.  Just don't use the optional
>> allow_return="true" (or whatever) attribute when you link your
> 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.

Yes, I'm very aware of that,  However, you have yet to give me even the
slightest hint of how this could possibly cause any real problems.  I've
given you many reasons why it could help people. Even if you don't agree
with my reasons -- if you want people to respect your votes -- I believe you
need to give us some real justification for not allowing this change other
than the fact you think "it is not right".

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

You know as well as I do that patching any code -- be it open source or
otherwise -- is not a good idea for long term maintenance.  For open source
code it can be a disaster since the code base can  mutate on you so quickly.

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

I'd like to respectfully suggest that you haven't really been able to
understand the problem our organization is up against.  That's likely my
fault, it's a hard problem to explain (research tends to be that way), and
I've got to give you a somewhat artificial use case both for simplicity
reasons and for privacy reasons.  However, I'd like you to once more go back
and look at this.  I for one strongly believe that the ability to
_optionally_ parcel out handling of a URI to multiple sub-sitemaps would
help for some organizations and that adding such capabilities to Cocoon
cannot hurt anyone.

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

View raw message