Bug 91891

Scott, can you comment as to the status of your changes, and whether or not
they're ready to be merged? Thanks.

31768 contains several changes (see the p4 comment) which essentially break down
as follows:

1) Redefined TemplateResolver to actually resolve template paths (as the javadoc
claims was its purpose). Remove template resolution logic from the dispatchers
and put it in DefaultTemplateResolver. This is necessary if we want be able to
define custom TemplateResolvers

2) Add a method to TemplateResolver to return a path for an actual Template
reference. This is important so that PFS can publish templates to the path that
the TemplateResolver is expecting them to be in.

3) MultilingualItemResolver has been fixed to correctly handle template contexts
-- when this logic was partially carried over from the old SimpleItemResolver,
it was not correctly implemented, and then the code was commented out.

4) Refactored MultilingualItemResolver to pull out some of the name/lang
resolution code into separate protected methods so that subclasses can reuse the
code.

5) Removed template path caching from ItemResolver since with multiple template
contexts, there is not a one-to-one correspondence between templates and items.

6) Added enterprise.init params for setting the ItemResolver and
TemplateResolver. ContentSection already provides a way to modify these, but
there was no way to do it from the Initializer. Note that for this to work you
also need changelist # as I forgot to include the initParameter calls for the
new parameteters in the first checkin.

You also need to grab @31761 for item requests to properly be dispatched to
ContentItemDispatcher. It prepends "/" to the URL fragment before checking for
preview URLs and passing the URL to the ItemResolver. This is what the old
ItemDispatcher did, and preview was only working by coincidence -- the
CMSDispatcher in the dispatcherchain also resolves items to URLs, but we don't
want item requests to go there.

Note that javadoc for TemplateResolver is added in 31782 (although that change
also adds javadoc for other classes in other changelists I'll address below)

Anyway, all of this should be appropriate for merging. It seems to be working
fine on my checkout, and I have not yet looked at how it affects the junit tests
or what additional tests may be necessary.

31395 contains fixes for categorizing Bundles rather than Items. This can be
merged as-is, but it would definitely need to be tested again with new
versioning/persistence if there have been substantial changes to
ObjectCOpier/VersionCopier, although this level of change shouldn't be at that
low a level. 

This change also doesn't address the problem that a ContentBundle is never
unpublished even if all instances are unpublished. We should probably add some
logic to ContentItem.unpublish() similar to the code which unpublishes folders
whe n appropriate.

31762 and 31769 are both needed to properly publish templates to the FS. This
has nothing to do with multilingualism or categories though. Essentailly
pre-troika, the only thing we really used PFS for was publishing templates, and
coincidentally, that's the only thing the DP PFS code does NOT publish.

31762 overrides getPath() for Templates to return the path with the ".jsp"
extention. Pre-troika, all ContentItems returned this extension, but new PFS
code doesn't use the extension. Templates still need this since they are actual
JSP files.

31769 makes a special case of  Template publishing. I'm not sure this is
necessarily the best way to do this, but it was the only way David and I could
come up with which required only minimal changes to PFS. The biggest
complication is that the new PFS code publishes files to a separate area not
under the webapp root (such as /var/www/html or something), but Templates should
not go there -- instead they need to be under the webapp root, and in particular
 they need to go to the directory that the CMS initializer has specified. So we
use the new TemplateResolver method from 31768 to return the proper
relative-to-webapp-root path for templates and PFS will place the template
there. Essentially if it's a template PublishToFile uses the TemplateResolver to
get the right pathname, and when the PublishedFile object is instantiated, the
m_isTemplate flag needs to be set in order to signal that 1) path should be
relative to webapp root rather than PFS root and 2) don't delete empty
directories upon template deletion. 2) is necessary since some of the subfolders
within the returned template path will already have files in them that pfs
doesn't know about, so folder deletion is inappropriate (for example we wouldn't
want to delete packages/content-section).

Note that without these changes, any CMS request for a content item which uses
any template other than the site-wide default will return a 404.

31771 has the actual category navigation resolvers included, as well as a couple
of additional minor changes to Category and CategorizedObject. However, this
builds on top of the changes in 31249, 31350, 31369, 31759 (which essentially
removes some of the dispatcher-oriented additions to 31249), 31760, 31774, 31786

The bulk of the changes are in 31249, although some of those new files and edits
are removed in subsequent changes (as I abandoned the notion of a separate
dispatcher/site node for category browsing).

You might want to wait a little on this change -- I haven't really tested the
category-to-template assignment yet as there's no UI for it at the moment. I
will need to test this portion later this week though.

"You might want to wait a little on this change -- I haven't really tested the
category-to-template assignment yet as there's no UI for it at the moment. I
will need to test this portion later this week though."

The comment above applies only to 31771, not the other changelists referenced in
this ticket.

In my comment on 31768, I forgot to include the changelist # for the
initParameter fix (because I forgot to check in the fix). The changelist # is 31803

31804 adds UI for assigning templates to categories.

31807 is also relevant to Multilingual/Categorization issues. I added a method
setDefaultCategory(category) to ContentItem which will grab the bundle and set
the isDefault attribute for the category association (using
CategorizedObject.setDefaultParentCategory). This is analogous to using
ContentItem.addCategory(category) for proper handling of ContentBundles except
the isDefault link attribute is set here.

*** Bug 91329 has been marked as a duplicate of this bug. ***

Also merge 31942, a bug fix to 31782.

Changes 32126, 32113, 32076, 32075, 32072, and 32068 integrate all of Scott's
francetv changes to the trunk.  Since this bug doesn't actually describe any
defects, just important merges, I'm going to mark this closed and let other
tickets handle specific problems.