You are here

nested-tables.xsl customization layer

Submitted by msulliva on Thu, 06/08/2006 - 22:25

I mentioned this to Jon at Summit and finally got around to testing it out. I haven't tested this in production so I can't vouch for the performance hit if there is any. Shouldn’t be…

Here’s how it works, you would have a customization layer that would be named nested-tables.xsl that has an import statement to the renamed original, say nested-tables-orig.xsl. The only things in your customization layer would be the xsl <template> tags that you need to modify and the import statement (and some other minor stuff see example). Whatever is in the customization layer would over-ride the originals with the same name *and* attributes. Unfortunately you would need to copy over the entire <template> block, even if you're just changing a small part of it.

So hopefully when a luminis patch blows away your nested-tables customizations you just rename the Sungaurd version to nested-tables-orig.xsl and copy back over your customization layer. If anyone knows where the path to the nested-tables is set, you might not even have to do this step and just change the path to point your customization layer, which imports the original.

Note if Sungaurd actually made any changes to the nested-tables.xsl in the specific templates that you override, you would need to then merge the changes into your customization layer, but I don’t imagine a whole lot of that goes on, and it would be a lot easier to diff the changes from the previous Luminis release to the new release than the new Luminis release to your customized nested-tables.xsl.

My plan now is to try changing image filenames, and possibly using a stylesheet override so I’m not making near as many code mods.

I’ve attached a sample that adds [!!] before each channel.

Modification:

Comments

This rocks ! I've been meaning to get around to trying this out - I'm so glad you posted it, thanks !

- Jon

This makes my mods so much cleaner. As I patched up to III.3.3.0 today, I converted my mods in production to this method. Works like a charm. I'll let you all know if I have any issues.

Your hack works great ... and is not the source of my woes here, but since you're an XML / XSL guru could you tell me why something I'm attempting won't work ?

Basic problem :
The overall 'hack' is in nested-tables.xsl. I'm moving the [xsl:apply-templates match="navigation"] line somewhere else, and it won't render the tabs.

Detatils :
I've altered the navigation template to stack the tabs in a more traditional website navigation scheme, and I want to place them on top of the left column before all the channels start to render.

I found the place to do the call from, however when I place the apply line there nothing displays.

I tried changing the [xsl:apply-templates select="navigation"] to [xsl:call-template name='navigation'] and changed the [xsl:template match="navigation"] to [xsl:template name="navigation"], and that seems to call it because I can see some of my extra html display there, however none if the tabs render as if the for-each loop on the navigation template fails.

So ... I'm guessing that call-template dies because it doesn't have access to the tab variable or something ?

Sorry, I'm sure this is difficult to understand without the nested-tables in front of you.

I continuted hacking around and ended up with this line :

[xsl:apply-templates select="/layout/navigation"/]

and it popped in there ... yea.

i wish i knew just a bt more about XSL, I feel like I can generally hack this stuff, but it is certainly a hack and not a fundamental understanding fo what I'm doing. Our new CMS system is heavily XSL based so I think I'm going to be forced to get a true understanding of it.

I learned most of the XSL I know from http://www.w3schools.com/xsl/xsl_languages.asp and an important part of XSL is actually XPath which was the source of Jon's problems: http://www.w3schools.com/xpath/default.asp which defines how you can navigate the XML nodes. Also TopXML (http://www.topxml.com/) has some great stuff but I can't navigate their site to save my life and usually end up there through Google.

To explain Jon's problem I'm guessing the apply-templates was called from within <layout> which in XSL/XPath means that you're already in /layout so apply-templates navigation would work. When you moved it you had to use the full XPath to /layout/navigation or alternatively //navigation would peg out all <navigation> tags no matter where they are.

Editing the nested-tables.xsl file would make a lot more sense if we could see the actual XML that Luminis is passing into the nested-tables.xsl for the transformation. I've had a little success at kicking out the XML from Luminis and will post it if I ever iron it out. So theoretically if we had a sample Luminis XML file we could use PHP or Java to do the transformation outside of Luminis or even a tool like XML Spy's XSL debugger on the XSL so it's not a game of hacking the file and then having to wait for Luminis to bounce...

This should win "hack of the year" award. I mean-who doesn't have to hack up nested-tables? You've just made everyone's lives immeasurably easier(especially with many people doing III.3.3 upgrades this summer).

Great hack! Just tried it on my dev. box in readiness to go to III.3.3

If you look in your uPortal Db in the UP_SS_THEME table, there's a reference to SS_NAME "Nested tables". Change SS_URI to something like

"stylesheets/org/jasig/portal/layout/tab-column/nested-tables/myUni-nested-tables.xsl"
(You could also change the SS_DESCRIPTION_URI, SAMPLE_ICON_URI and SAMPLE_URI values if you're feeling rather fruity)

In your new file "myUni-nested-tables.xsl" import the original nested-tables.xsl as you describe ...

http://www.w3.org/TR/xslt#import (for more info)

This way you shouldn't even have to rename any files and your mods will remain (provided the upgrade process doesn't update the Db).

HTH

--
HooDooWitch

That's what I was looking for! I spoke too soon about the "I don’t imagine a whole lot of that goes on" (major changes to nested-tables). This 3.3.3 did some pesky changes that I saw Jon complaining about, bummer... I'm up late getting my changes to 3.3.1 into 3.3.3... Hopefully this isn't normal (I'm new to luminis, go live at the end of the month), but I'd imagine we're in for a "treat" when 4 comes around as well.

So is there an equally clean way to preserve my HTML fragment mods? We heavily modify the thtml files that build various fragments within Luminis 3.3.1/3.3.3 and so far every time we upgrade those get whacked.

Is this (still) the preferred way to modify nested-tables?

It seems like it might be beneficial to leave the default nested-tables.xsl in place and add an "import" command to the bottom of it. That added import would import your changes. This way, when SunGard comes out with a new nested-tables.xsl, all you'd have to do is re-add that import?

However, I am new to this, and I'm not sure I fully understand it all?