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 Wed, 09 Oct 2002 16:21:36 GMT
>> I can think of many use cases where I might
>> want to parcel out handling of a portion of a site to some other group,
>> still continue processing a request if the other groups sitemap did not
>> handle it.
> Please share them with us.

The general use case is where a web site has to handle non-hierarchical
structure.  For example cross functional reporting.  You may want to parcel
out handling of area "x" to one group and of area "y" to another.  Since
there is an intersection of responsibilities a third requirement to also
handle those cases of the form "xy" (or "yx")  Currently you can't do this
in a general fashion with sub-sitemaps.

As a specific use case consider sections within a departments all
contributing to the same web site.  Each group is authorized to update a
subdirectory containing their own sitemap and handle content within their
own area.  Suppose the department has a statistics section responsible for
handling requests for data crunching. Suppose the department also has it's
own IT group responsible for handling infrastructure issues (new PC's etc.)
The first group may have a sitemap matching the pattern "stats*", the second
group might have a pattern matching "it*".  

In our case, the stats group also mostly handles their own infrastructure,
but not always (historical and political reasons). Similarly, some requests
for stuff that looks like stats isn't (requests for statistics on IT
infrastructure). It would be good if requests like "stats*/it*" could first
be matched against the stats department and then against the IT departments
pages.  Similarly, it would be good if requests like "it*/stats*" could be
first matched against the IT pages then the stats pages. (Of course the
stats departments also produces stats about their own IT infrastructure.)  

The point is, that since these two sections are working independently of
each other 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.  Yes, given such a
scheme, there could be cases where one section accidentally intercepts
another sections URL (dependant on who comes first in the master sitemap),
but those can be resolved through negotiation between the two sections (and
the precedence rules would still be well understood). 

Is this necessary?  Probably not.  Is there any reason not to allow it?
Probably not.

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

View raw message