Bug 91770
Summary: | ContentItem.getPath() returns wrong path | ||
---|---|---|---|
Product: | [Retired] Red Hat Enterprise CMS | Reporter: | Bryan Che <bche> |
Component: | other | Assignee: | ccm-bugs-list |
Status: | CLOSED WONTFIX | QA Contact: | Jon Orris <jorris> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | nightly | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-09-29 14:39:33 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Bryan Che
2003-05-27 22:30:55 UTC
I think we should take this bug off the beta 2 list. Two reasons: 1) To my knowledge, it's not resulting in user discoverable error. 2) We may decide it's already doing the right thing, and whoever calls it needs to be careful to call it on a bundle, not an instance inside a bundle. This behaviour does lead to a bug in ContentSectionServlet's Item-URL cache right now. com.arsdigita.cms.ContentSectionServlet lines 228-229 cache the result of an ItemResolver.getItem() call. Justin, is the right thing: -ItemResolver should return a ContentBundle -ContentSectionServlet should get the ContentBundle from the item returned by the ItemResolver -ContentItem.getPath() should work properly from a ContentItem that isn't a bundle I'm not sure what is the right behaviour. Bryan, I'm inclined to say that your second option is the correct behavior, since the bundle, not any contained item, is really the locus of dispatch. It follows, if you think of it the way I do, that: a) A bundle's path is important; it is the leaf node of the tree of dispatchable things (where "dispatch" here refers to the long-standing method of CMS "item" dispatch, not the newer language resolution that occurs after the bundle itself is resolved). b) A language instance's path is *not* important (basically junk) since it is not used for dispatch. Of course, I don't feel my views on this are necessarily widely held, so I feel some trepidation in making proclamations. Any comments? We discussed at the bug roundup and decided to move this to rc0. This is what is causing bug 102894 but I don't necessarily think it is blocking....102894 is just an example of what can happen if the developer is not aware that the bundle is also included and it shows how any existing code will work. |