As part of this ticket, make sure the default template set has three differing
templates.

The thing he says at the end may explain our apparent template UI bug:  the
templates all look the same because MultilingualItemResolver (which replaces
SimpleItemResolver) no longer encodes/decodes the context info in the URL.

Justin

Richard Li wrote:

> [13:38] <crag> CMS Templates... I'm curious if anyone has actually used
templates with different contexts (the default is to use DefaultTemplateResolver
where the context is always "public")
> [13:39] <jorris_home> crag: That's a good question, which I've had myself.
There's a bugzilla ticket something like 'Templates don't seem to do much' on
the trunk.
> [13:44] <scott> jorris_home: what do you mean by "don't do much" -- are you
referring to multiple contexts or templates in general?
> [13:44] <scott> they do use multiple contexts on DP I believe.
> [13:44] <scott> as for templates in general, you can pretty much add as many
or as few components as you want to a page with templates.
> [13:45] <crag> scott: are you referring to the template edit UI (under the
content types tab of content section)?
> [13:45] <scott> for example, for the Camden project I"m working on, all
content types but two use the same template, so we just modified the default cms
item.jsp -- but there are two content types which need different templates. One
of them has additional UI components on it but is otherwise similar to the
default, and the other one is completely different.
> [13:46] <scott> actually I'm referring to the templates themselves rather than
the CMS UI to edit them
> [13:46] <scott> I just write the JSP in emacs and upload it.
> [13:46] <scott> but yes, I upload it under the appropriate content type.
> [13:47] <scott> if you're installing from scratch, I think the
SectionInitializer will automatically load and publish your per-content-type
templates.
> [13:47] <crag> interesting.  seems to make debugging xsl one step more
difficult :)
> [13:47] <scott> what do you mean?
> [13:47] <scott> you mean some content types have different XML to work with as
a result?
> [13:47] <crag> does it store your template to db?
> [13:47] <scott> yes, but it's got to be published to actually have any effect
-- as the template is pulled from the filesystem just as any other JSP would be
> [13:49] <scott> but how is using multiple templates more difficult to debug
than relying on a single template -- only one is used for any given page request.
> [13:49] <crag> right, it isn't i was thinking you were uploading xsl
> [13:49] <scott> and the rules for which template to use are pretty
straightforward.
> [13:49] <scott> ahh, no.
> [13:49] <scott> CMS templates must be JSPs.
> [13:50] <scott> and even if you don't upload templates, you're still using a
template -- you're using the default item.jsp template
> [13:50] <crag> the method i'm familiar with is writing a switch on the content
type to select the jsp, rather than uploading
> [13:50] <scott> you mean in enterprise.init?
> [13:50] <crag> no, i forget... let me go look at my code :)
> [13:51] <scott> hmm. must be some sort of customization. CMS out-of-the-box
selects a jsp as follows:
> [13:51] <crag> ItemDispatcher.java, of course :)
> [13:51] <scott> 1) does the content item have a template explicitly 
associated with it -- i fso, use it
> [13:52] <scott> 2) does the content type have a default template -- if so use it
> [13:52] <scott> 3) else use the systemwide default.
> [13:52] <crag> although, back to my original question if anyone uses multiple
contexts, that would apply to 2)
> [13:53] <scott> actually, it would apply to 1)
> [13:53] <scott> the context is stored in the template-item assocaition, not
the template-type association
> [13:53] <crag> yep, 1) :)
> [13:53] <scott> right now to use multiple contexts, you'd need to add all
context-specific templates to your content type
> [13:54] <scott> and for each item that needs multiple contexts, associate the
right template under the context on the content item "templates" tab
> [13:54] *** bdolicki has quit IRC (Client Exiting)
> [13:54] -> *quaid* are you getting this? scott's an expert on the CMS, so
pretty much everything he says is very useful and enlightening :)
> [13:54] <scott> better solution would be to extend the UI and back end for the
template -> type association and add a default template for each context (on a
per-content-type basis)
> [13:55] <scott> what are you using multiple templates for?
> [13:55] <crag> oh, i'm not, just curious because a support question came up
regarding them
> [13:55] <crag> but i think the point of contexts is to show a different
template based on say, user preferences
> [13:55] <scott> right now the use context is based on the URL.
> [13:56] <crag> right, which defaults to public if not specified
> [13:56] <scott> the template context gets added to the URL, so if you item is
/ccm/content/foo.jsp, /ccm/content/tem_alternate/foo.jsp would return the item
with the alternate template
> [13:58] <crag> but it looks like out of the box (which I assume uses
DefaultTemplateResolver), those 2 urls are still the public context
> [14:08] <scott> hmm. the code could have changed, or I may be misremembering
something -- but the way to trigger the context was looking for tem_contextName
in the URL right after the section name.
> [14:09] <scott> yes -- SimpleItemResolver sets the context
> [14:09] <scott> from the URL
>
>

Update to issue 20560 by Crag_Wolfe
Action: Actually, the templates tab is misleading in that you won't change
anything by selecting "Assign Template".  So, that won't interfere with
modifying the xsl templates.

Out of the box, the default context is always "public".  Also, these templates
are analagous to .jsp's, such as item.jsp (rather than xsl templates).  The
point of templates in the templates tab, is to assign a different default
context.  But the code doesn't actually support this by default: you would need
to write a TemplateResolver and/or modify SimpleItemResolver.

Actually, CMS templates aren't analogous to JSPs -- they _are_ JSPs. If you
wanted to you could make them spit out HTML directly, but in practice, CMS JSP
templates generally output bebop XML which is styled via the usual stylesheets.

As for the preview link, looks like the template preview links have lost the
template context portion of the URL -- but it sounds like this is the
MultilingualItemResolver issue -- if you add the template encoding/decoding
back, it should work, as the template-specific preview works on 5.2.

Making a separate default template for each context will require UI and back-end
changes. Currently the template context is set in the template-item association.
There is no context field in the template-content type association. That would
have to be added to support a different default template for each context.

I think resolving this particular ticket requires a few things:

1. Documentation of TemplateContext and templates.
2. 3 different default templates (one for each context) so that the system is
more demo-able.

The actual problem of templates not working is tracked in 91891. Retargeting
this ticket for RC0.

Note that the changelists discussed in 91891 also address the issue of preview
links and template contexts not working. Essentially the template context
handling code which worked with the old SimpleItemResolver was only partially
implemented (and then commented out) in the initial implementation of
MultilingualItemResolver. My changes (documented in 91891) fix this for
MultilingualItemResolver. In addition, note that the UI never allowed you to add
a new template. Templates are added to content types on the Content Types tab at
the section level. Item-level templates are selected from the list of available
templates uploaded to the content type. Once you have created templates for the
content types, the Templates UI does allow you to assign them to items.

Also note that setting default templates on the section UI currently hard-codes
this to "public" -- the london branch fixes this (I don't know the changelist #
offhand though). The item-level UI also hard-codes the query which returns the
template list to "public" -- this has not been fixed on the london branch either.

 After discussing this with Jon Orris and Scott Seago, changing the 
status to QA_READY, because 
 
 
 (a) the original bug was fixed some time ago.  The "preview" link URL 
     is now different for the three different contexts. 
 
 (b) as for Justin's comment that the three different contexts should 
     have different templates out of the box, that is rather hard to 
     achieve. 
 
 
There is one real bug that should be fixed, but we should probably 
file a separate ticket for that.  The bug is this: 
 
  If you go to the Content Sections' "Content Type" tab and try to add 
  a template to, say, the Article content type, you can only assign 
  the template to the "public" context. There is a "Use Context" 
  drop-down box, but it only shows "public" as the only available use 
  context.  Scott tells me this has been fixed on the London tree. 
 
 
As to why (b) is hard, here's why. It is way too easy to change the 
way the CMS template cookie crumbles. 
 
There are many levels -- way too many, IMHO -- on which the template 
application mechanism can be changed. 
 
The item preview is served by ContentSectionServlet (ConSeSe). 
ConSeSe relies on the ItemResolver (IR), returned by ContentSection 
(CS), to figure out the request context.  Out-of-the box, CS is 
hardwired to return "MultilingualItemResolver" as the value of the 
content_sections.item_resolver_class column. (This is hardcoded in the 
"create(String)" method of the CS class.) 
 
 
ConSeSe asks ContitemItemDispatcher (CID) for a template resolver. 
CID delegates this call to ContentSection.  CS queries the datatabase 
to find out its template resolver.  The template resolver class name 
for a section is stored in content_sections.template_resolver_class. 
In an out-of-the-box CMS, a querying this column returns 
"DefaultTemplateResolver" (DTR).  Where and when does this db column 
get initialized?  The class name DTR is hardcoded in the (private) 
createContentSection method in cms.installer.Installer. 
 
CID is responsible for dispatching the item. To do so, it delegates to 
to the TR (which, by default, is DTR) to get the template for this 
item.  DTR tries to look up 
  (a) the item-specific template;  if this fails, then 
  (b) the content-type specific template; if this fails, then 
  (c) the default template. 
 
(a) is accomplished by querying cms_item_template_map. 
 
(b) is accomplished by delegating to the DefaultTemplateManager 
(DTM). DTM queries cms_section_template_map to find the template. 
 
(c) is accomplished by querying ContentSectionConfig (CSC), which 
returns the value of the enterprise.init parameter 
"defaultItemTemplatePath" (specified in 
com.arsdigita.cms.installer.Initializer block). Coupled with the value 
of the "templateRootPath" parameter this returns 
 
  ./web/packages/content-section/templates/default/item.jsp 
 
given the following default settings 
    templateRootPath = "/packages/content-section/templates"; 
    defaultItemTemplatePath = "/default/item.jsp"; 
 
 
In light of the above, these are some of the possible ways to change 
the template applied to a previewed content item. 
 
 
* Write a custom subclass of ItemResolver (or AbstractItemResolver) 
  that overrides getTemplateFromURL method to implement a different 
  mechanism for determining the context.  (Currently, it searches for 
  an occurrence of a string like "tem_public" in the URL and parses 
  out the "public" part of. The "tem_" is the hardcoded prefix.) 
 
* Use a custom template resolver instead of DefaultTemplateResolver. 
  Presumably, this can be accomplished by updating the 
  content_sections.template_resolver_class field in the database. 
  Once the template resolver is changed, you may no longer have the 
  notion of three possible contexts. 
 
* If using DTR, register a content-type-specific template for each 
  content type.  Supplying default content-type-specific templates 
  out-of-the-box is a huge waste of time, because PS projects are 
  guaranteed to want to customize these. 
 
* If not registering a content-type-specific template for each content 
  type, then change the default template path in enterprise.init. 
 
* If you use category-based browsing, then the same item may have 
  different templates depending on the category in which it is 
  currently being (pre)viewed. 
 
 
The most sensible thing to do seems to be to improve the existing UI 
in a way that indicates to the user which template is used for preview 
for a given item in a given context.  I am not sure what would be the 
best way to accomplish this.