Bug 91770

Summary: ContentItem.getPath() returns wrong path
Product: [Retired] Red Hat Enterprise CMS Reporter: Bryan Che <bche>
Component: otherAssignee: 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 published an article with the name, "article."  However, calling getPath() on
that article returned "article/article"

Comment 1 Justin Ross 2003-06-06 23:09:36 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.

Comment 2 Bryan Che 2003-06-09 13:10:27 UTC
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.

Comment 3 Justin Ross 2003-06-09 16:03:40 UTC
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?

Comment 4 Justin Ross 2003-06-11 00:30:32 UTC
We discussed at the bug roundup and decided to move this to rc0.

Comment 5 Randy Graebner 2003-08-26 13:09:46 UTC
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.