Bug 108156

Summary: Content type Templates don't display properly in Preview
Product: [Retired] Red Hat Enterprise CMS Reporter: Jon Orris <jorris>
Component: content typesAssignee: Vadim Nasardinov <vnasardinov>
Status: CLOSED RAWHIDE QA Contact: Jon Orris <jorris>
Severity: medium Docs Contact:
Priority: medium    
Version: nightlyCC: jross, richardl
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: 2003-11-07 22:47:18 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:
Bug Depends On: 109171    
Bug Blocks: 106597    

Description Jon Orris 2003-10-28 04:28:40 UTC
Description of problem:
@37046

Content types do not display correctly in the preview pane, though they display
correctly on publication.

In preview, only the name & title show up

Comment 1 Vadim Nasardinov 2003-11-03 21:35:24 UTC
I think the bug was due to a combination of two factors:

(a) cms-item.xsl did not "/__ccm__/servlet/content-type/index.xsl"
    until change 37632.

(b) /__ccm__/servlet/content-type/index.xsl has no effect unless you
    use the PatternStylesheetResolver instead of the default
    LegacyStylesheetResolver.


So, if you set
waf.templating.stylesheet_resolver=com.arsdigita.templating.PatternStylesheetResolver

then the preview should work, I think.


Comment 2 Richard Li 2003-11-04 20:39:38 UTC
is the above the default in tip?

Comment 3 Vadim Nasardinov 2003-11-04 20:47:21 UTC
It's not the default.  We could try changing the default from
LegacyStylesheetResolver to PatternStylesheetResolver and see
what happens.


Comment 4 Richard Li 2003-11-04 22:36:30 UTC
hm, it seems like we should, assuming nothing else breaks, or else get
this to work with the default...

jon, can you switch it and rerun the regressions?

justin, vadim: do you think this is the right solution?

Comment 5 Vadim Nasardinov 2003-11-04 23:06:53 UTC
The part I don't understand is, if PatternStylesheetResolver
is backwards compatible with the old stylesheet resolution
process, then what do we need LegacyStylesheetResolver for?

I don't know the answer to this question yet.


Comment 6 Richard Li 2003-11-05 14:16:26 UTC
See bug 109171

Comment 7 Daniel Berrangé 2003-11-05 14:25:00 UTC
> (b) /__ccm__/servlet/content-type/index.xsl has no effect unless you
>     use the PatternStylesheetResolver instead of the default
>     LegacyStylesheetResolver.

Actually, I did fix LegacyStylesheetResolver so that it would work
with the ContentTypeXSLServlet correctly - it now generates http://
URLs just like PatternStylesheetResolver. see p4 37488


> The part I don't understand is, if PatternStylesheetResolver
> is backwards compatible with the old stylesheet resolution
> process, then what do we need LegacyStylesheetResolver for?

The pattern stylesheet resolver itself *isn't* backwards compatible
because you have to re-arrange your top level XSL files. The
LegacyStylesheetResolver is the bit that makes the new XSL
infrastructure backwards compatible, with zero change required other
than setting the templating.stylesheet_resolver property.

As such it is intended for any existing projects who haven't migrated
to the new pattern based resolver. THese projects will have set up a
metric ton of PackageType<->Stylesheet and SiteNode<->Stylesheet
mappings in the DB. For them to switch to the pattern based resolver,
they'd have to move / rename all their existing XSL to fit the formal
naming conventions required by the rules in stylesheet-paths.txt. 
LegacyStylesheetResolver should be finally removed at the same time
SiteNOde, PackageType & friends are finally removed.



Comment 8 Vadim Nasardinov 2003-11-06 18:03:40 UTC
Fixed at 37765.  See bug 109171.