>> >> 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 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! >>>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. 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 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 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 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. 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
