Hunsberger, Peter wrote: >>>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.
Exactly. By making sitemaps return, you are *not* defining the pattern each group uses. You are leaving it all to them. > It's up to the groups to define what URIs to use, > not me. Ok, then what's the problem? Can't they change the sitemap? > 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. Ok, then give them a subsitemap they use together. If they decide URIs together, they can surely work on the same shared sitemap together. And have other subsitemaps there. > 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. Sure, then mount a sitemap and give it to them... both of them. > Once again, I ask you to tell me how to handle this situation with Cocoon as > it currently sits? I have already said it. More than once. >>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...) Let them share the common sitemap. >>>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/> > > 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! You don't listen. If there is URL overlapping there is no way you can handle the situation gracefully if the groups don't work together. You handle the mapping, you are in charge. They handle it, they are in charge. Read the SoC part of http://xml.apache.org/cocoon/introduction.html ... > 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. Is it magic? > 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. Hmmm... manybe you've defeated *your* idea of subsitemaps. Linux can mount. Cocoon can. Same concept. Would you like the mount point to have a multiplicity? What file does the user get? By doing what you propose, we are in fact making it possible to define very complex mount rules... I think it totally defeats the purpose of the sitemap from a manageability POV. Read the *original* proposal of the sitemap in the archives, and you'll understand why a sitemap is not reactive: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=86952206811879&w=2 ... > I've > given you many reasons why it could help people. It helps people do what I think is bad practice. A citation form Mazzocchi, which I think still stands: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=86952206811915&w=2 " 1) badly designed web sites will lead to verbose sitemaps, on the contrary, well designed web sites will need less verbose sitemaps. 2) sitemap complexity can be a direct measure of your web site complexity and might lead to the creation of design patterns for sitemap complexity reduction. Since I believe that verbosity reduction is proportional to augmented readability and reduced management cost, I'd rather have you spend your cycles in designing your URI space rather than messing around with the sitemap. 3) a good sitemap grows step-wise logarithmically with the web site size. This means that once you've reached the needed web-site complexity, every addiction in the same patterns will not need to modify the sitemap, or, if it does, produces redesign rather than simple verbosity increasing. 4) Cocoon is _not_ designed for small sites. Small sites will have complex sitemaps compared to other solutions. This is why I do not recommend Cocoon for pure HTML replacement. 5) I assume sitemaps will be managed by learned people that keep control of the "contracts" between the working contexts. This is the "management" box in the "pyramid model of operation" (see Cocoon docs). " > 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". No listen to this! :-O I have not voted, I have explained it as much as I can, I spent my time explaining you how it can be done better, and this is the result? bah... :-S >>>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. You are in the research, right? <grin/> >>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. This "cannot hurt anyone" is the usual refrain. :-/ Listen, forget about the solution you want to push forward, it's not a solution but a hack to get your hands clean. Let's start again and see what the *real* problem is. And please, don't just restart the usual refrain, because I'm really trying to find a solution to your problem, ok? -oOo- Now, it seems to me that in your organization, you are the Cocoon admin, and are in charge of the main Cocoon sitemap. There you can give groups subsitemaps that are mounted, thus partitioning the space between them. Some groups work separately while still sharing the same URI space somewhat, and try to work out the inconsistencies with weekly or as-needed summits ;-) You want to be able to have them work *indipendently* on the *same* mount point. Thus you propose subsitemaps that can return; if a subsitemap doesn't recognize a URI, it passes onto the second subsitemap. This is not a mount but /chaining/, and it's different from how the sitemap works now. Something along these lines: <map:match pattern="documents/**"> <map:mount-set uri-prefix="documents"> <map:mount src="docs1/" /> <map:mount src="docs2/" /> </map:mount-set> </map:match> This basically means that you want to treat multiple sitemaps as a single sitemap, as if they were one document. Then what strikes me is that it really should be one document only, not two. Can't your groups work on the same document, maybe with CVS? It would make them collaborate better and faster on the URI space. Or, as a hack, you can include parts of xml inside the common sitemap by using XML entities. Or... I don't know if it works, but (even if I don't like it) maybe it's possible to mount a sitemap without specifying a prefix. Try adding this to the end of the first sitemap and see if it works: <map:match pattern="**"> <map:mount src="docs2/" uri-prefix="" /> </map:match> -- 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]
