Bug 91770 - ContentItem.getPath() returns wrong path
ContentItem.getPath() returns wrong path
Product: Red Hat Enterprise CMS
Classification: Retired
Component: other (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: ccm-bugs-list
Jon Orris
Depends On:
  Show dependency treegraph
Reported: 2003-05-27 18:30 EDT by Bryan Che
Modified: 2007-04-18 12:54 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-29 10:39:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Bryan Che 2003-05-27 18:30:55 EDT
I published an article with the name, "article."  However, calling getPath() on
that article returned "article/article"
Comment 1 Justin Ross 2003-06-06 19:09:36 EDT
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 09:10:27 EDT
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 12:03:40 EDT
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-10 20:30:32 EDT
We discussed at the bug roundup and decided to move this to rc0.
Comment 5 Randy Graebner 2003-08-26 09:09:46 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.