Skip to content. | Skip to navigation

Personal tools

Navigation

You are here: Home / weblog

Dominic Cronin's weblog

Showing blog entries tagged as: Tridion

Strange dreams of nightmare code

Posted by Dominic Cronin at Mar 04, 2007 05:00 PM |
Filed under: ,

One morning this week I woke up to a very strange combination of life and programming. Kind of a "things that make ya go hmm..." moment. Here's how it went:

Some considerable time ago, I began work on a re-write of a Tridion events system. The existing system was so gunged up with layer upon layer of cruft that we decided it was unmaintainable and that we wouldn't touch it unless absolutely necessary. The fickle winds of project management have now blown us back onto the jagged rocks; we ended up dispatching from the new system back to the old code, which turns out to be fairly broken, and I have to mend it. Ouch!

No big deal, you may think, until you realise that the broken piece is a thirty page long stretch of Visual Basic 6. That's thirty pages all in one function. This code handles a Tridion OnComponentSavePost event, and in the process, saves the component four separate times. Each of these saves causes a recursion into the handler, each time from a different place and with a different data state. Depending on the state, various if-then-else blocks either fire or don't, leading to the code being executed in an order very different from what you see laid out as you hit page-down thirty-odd times. As you can imagine, before making even minor changes to this stuff, you have to marinate in the code for quite some time, tracing the various paths of illogic through the smoke-trails of your predecessor's brain-damaged nightmare. One thing's for sure - you know if you touch anything, there's a huge risk that you'll break something else.

If you've ever done this kind of work, you'll know that once you've lived in the code for a few days, there's every likelihood that you'll spend your nights dreaming of it too.

During this time, our seven-month old son, Finlay has had a virus, resulting in some fairly disrupted sleep for us all. Perhaps once every hour or two through the night, the poor lad would cry out, and you'd find yourself awake in response. After a night of this, it becomes increasingly hard to come up out of deep sleep, and one morning at five or six o'clock, and  I found myself in the middle of a dream of scrolling code, hearing a cry, but hearing it as a bug. Huh? How does that work? You hear of people with psychological disorders hearing colours and so forth, and I suppose in the dream world there are no rules. I heard a cry, and experienced it as a sort of "Oh shit, there's another bug." moment.

Finlay's back to health now, and (mostly) sleeping through the night. Maybe some time soon, I will too.

Pulling website information out of the IIS metabase

Posted by Dominic Cronin at May 24, 2006 10:00 PM |
Filed under: , , ,

Pulling website information out of the IIS metabase

Someone recently asked me how to find the URL where the Tridion user interface is running. The idea was to automate the set-up for Tridion Site-Edit. The following snippet of code doesn't solve their problem, but for me it was a bit of fun exploring how to pull up this data out of the IIS metabase using C#. Although this blog entry is categorised as "Tridion", this code isn't particularly Tridion-specific. It's sufficient to show that it's not particularly painful to work with IIS programatically. You can also write to the metabase using similar techniques.

 

using System;
using System.Collections.Generic;
using System.Text;
using System.DirectoryServices;

namespace Hinttech.Dotnet.Samples.WebSiteDumper
{
    class Program
    {
        static void Main( string[] args )
        {
            using (DirectoryEntry webServers = new DirectoryEntry("IIS://localhost/W3SVC"))
                {
                foreach( DirectoryEntry server in webServers.Children)
                {
                    PropertyValueCollection serverComment = server.Properties["ServerComment"];
                    if ( serverComment.Value != null && serverComment[0].ToString() == "Tridion Content Manager")
                    {
                        Console.WriteLine("The Tridion web site is running on: ");
                        Console.WriteLine("===================================");
                        // If you want the https sites too, you need to do the same thing for "SecureBindings"
                        foreach ( string serverBinding in server.Properties["ServerBindings"] )
                        {
                            string[] serverBindingParts = serverBinding.Split(':');
                            string ipAddress = serverBindingParts[0];
                            string port = serverBindingParts[1];
                            string hostHeader = serverBindingParts[2];
                            if (string.IsNullOrEmpty(ipAddress))
                            {
                                ipAddress="Default";
                            }
                            Console.WriteLine(
                                "\tIP Address = {0}\n\tPort= {1}\n\tHostHeader= {2}",
                                ipAddress, port, hostHeader );
                            Console.WriteLine("===================================");
                        }                                            
                        server.Dispose();
                        break;                        
                    }
                server.Dispose();
                }
	    }

#if DEBUG
            Console.ReadKey();
#endif
        }
    }
}

Component linking and magical parameters in Tridion's XSLT component templates

Posted by Dominic Cronin at Jan 28, 2006 11:00 PM |
Filed under: ,

I was recently asked a question about XSLT templating in Tridion. The question was about how you create component linking code from within your XSLT component template. The tricky part is that you need a publication ID and a component template ID. My solution involved getting these in the page template and passing them in to the XSLT as parameters. OK - job done - it's just coding from there eh? Well yes - but it didn't stop being interesting at that point, because my questioner in the meantime had come up with his own solution based on some sample code that he'd found on the Tridion forum. He hadn't needed to add the parameters himself, because Tridion adds some parameters for you as if by magic.

 

It turns out that if you include any of the following three global parameters at the top of your XSLT, Tridion will add the corresponding DOMs as parameters as if by magic.

<xsl:param name="tcm:Page"/>
<xsl:param name="tcm:Publication"/>
<xsl:param name="tcm:ComponentTemplate"/>

This is very cool, and saves you the effort of coding it, but I don't know whether it's a supported feature. I suppose it should be, because it's really just the standard behaviour for a component template translated to XSLT. I just can't find it anywhere in the documentation.

 

There is a gotcha, mind you! Although the parameters are declared in the "tcm:" namespace, which resolves to "http://www.tridion.com/ContentManager/5.0", don't be tempted to use a prefix other than "tcm:" for this namespace. If you do, you'll find that there's something broken; the parameters don't seem to be added automatically. (Tested on R51SP4) Still - as it's an undocumented, and perhaps unsupported feature, we can't really complain.

 

It would make a good enhancement request though. Perhaps Tridion can be persuaded to document this and support it. In the meantime, perhaps it's better to be on the safe side and explicitly add the parameters you need to the Component Presentation from the Page Template.

Tridion behaves badly when publishing ASPX

Posted by Dominic Cronin at Jan 12, 2006 11:00 AM |
Filed under: ,

Tridion behaves badly when publishing ASPX

When you publish ASP.NET code from Tridion using the TCDL mechanism, it adds extra output that you didn't ask for. Specifically, each component presentation is emitted wrapped in a span tag. The span tag has an ID composed of the URI's of the component and component template.

These span tags aren't there because you asked for them in your content, or in your templates, so why are they there?

I reported this bug to Tridion customer support, and they told me that it's not a bug. It's designed that way, they say. Fair enough, I say, then it's a design bug. Apparently, the purpose is "to make it easier for SiteEdit and template designers to manipulate existing component presentations. Well that won't wash, because it's no earthly use for either purpose.

Is it a bug? Walks like a duck, quacks like a duck....

What harm can it do?

  • Well in my case the main issue was that in XHTML a span tag isn't allowed to contain block-level elements. That means the XHTML produced this way is invalid. (I'm the kind of guy that likes to see a clean compile, and I like to see my web pages validate correctly too. This isn't just bravado, it's the most efficient way to work.)
  • On top of that, you might not always be in charge of the CSS on your site. What if someone specifies a child selector instead of a descendant? That's just an example: you can imagine a hundred other ways this detritus could ruin your style.
  • Oh heck! It's just broken, that's all. A web content management system should allow you to manage your web content. That means not emitting things you didn't ask for.

Anyway - what can you do about it?

  • You can ignore it. This might be OK if you don't care about validation, and you have complete control of the styles.
  • Of the people I've spoken to, it seems most are simply avoiding the problem by publishing to a Publishing Target with Target Language set to None. Of course, if you do this, you have to writeOut the various functions for linking etc. yourself. If everyone does this, then Tridion might as well never have invented TCDL in the first place.
  • You can create a customised version of the AspDotNETTransformer. This is probably what I'll do. Tridion customer support have provided me with some java source code (which is just as well as it's an undocumented API). It looks straightforward enough and it's install once - fixed forever.
Quack, Quack!!!