Bug 108156 - Content type Templates don't display properly in Preview
Content type Templates don't display properly in Preview
Status: CLOSED RAWHIDE
Product: Red Hat Enterprise CMS
Classification: Retired
Component: content types (Show other bugs)
nightly
All Linux
medium Severity medium
: ---
: ---
Assigned To: Vadim Nasardinov
Jon Orris
:
Depends On: 109171
Blocks: 106597
  Show dependency treegraph
 
Reported: 2003-10-27 23:28 EST by Jon Orris
Modified: 2007-04-18 12:58 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-11-07 17:47:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jon Orris 2003-10-27 23:28:40 EST
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 16:35:24 EST
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 15:39:38 EST
is the above the default in tip?
Comment 3 Vadim Nasardinov 2003-11-04 15:47:21 EST
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 17:36:30 EST
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 18:06:53 EST
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 09:16:26 EST
See bug 109171
Comment 7 Daniel Berrange 2003-11-05 09:25:00 EST
> (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 13:03:40 EST
Fixed at 37765.  See bug 109171.

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