You think you got what it takes?

My evolution in Tridion knowledge is a repeating (and repeatable) pattern:

1. Looks cool, and pretty easy
2. God what the hell is that?
3. I hate you Tridion
4. Why on earth is it working now?
5. Hmm. That actually makes perfect sense
6. WOW, look at all the shiny stuff I can do. Seriously, this is sooo coool!

Enjoy the glory for a few months, go back to square one.

• It was like this with Infrastructure knowledge and deployer configuration and broker xml files and Tomcat and IIS 6.5 years ago.
• It was like this with VBScript and Component Templates and XSLT and Metadata and Dynamic XSLT templates 6 years ago.
• It was like this with c# and Event Systems with Interops and marshalling and unmarshalling of COM and multithreading TDSE objects 5.5 years ago (hey Robert, remember this one?)
• It was like this with Compound Templating when it came out in February 2008.
• It was like this with complex Taxonomies when it came out in mid 2009.

So why would it be any different with the new Anguilla Framework introduced in 2011?

I think I'm on the transition between steps 3 and 4, where I do get things to work but in many cases I am not really sure why. It has first and foremost to do with my lack of knowledge and any practical experience on _proper_ JavaScript development. Heck, other than simple carousels and show/hide stuff I don't think I had ever written more than 10 lines of JavaScript in one go.

Here's a few tips on some of the things I've done so far too keep me somewhat sane, I hope this will help others:

DISABLE CACHE ON YOUR BROWSER. Seriously, get the Firefox Web Developer extension, and turn the cache off while developing.

Get used to a javascript console. I use Firebug mostly, and the messages it logs are priceless! Some people prefer Chrome, others IE. I don't really care. Just use one.

Backtrack what the CME is doing when it fails. When your extension breaks Tridion completely (believe me, it will happen a LOT of times) Tridion will gracefully half-load and not show you any error. Luckily you had your Javascript console when the CME was loading, and you can clearly see what request broke it. Copy the url that it tried to load (it will look more or less like this: http://localhost/WebUI/Editors/CME/Views/Dashboard/Dashboard_v6.0.0.39607.6_.aspx?mode=js) and now you'll probably get a very useful ASP.NET error message instead (typically along the lines of "File X does not exist") which will point you in the right direction.

And, most important, keep believing you CAN do it. You'll get there.

Tridion Publisher and Custom Resolvers

Back in the day, we used to disable Tridion's link resolving (aka "Link Propagation") at publish time by using the old and venerable Event System (for more details about link resolving, check this page).

Recently I had to write some code to disable link resolving only under certain conditions for Tridion 2009, and started going down the true-and-tried road of Event System and "OnComponentPublishPre" events. Shortly after deployment in the test environment we started getting some really angry error messages from COM saying that my code was trying invalid casts.

Obviously offended by the suggestion that my code wouldn't work, I tried to understand what the **** was going on, and eventually figured out that it was all down to this: MSXML cannot be used in .NET code. And since the Event System in pre-2011 days is still based on COM and the Publish Instruction is an MSXML document... it would never work.

I could have re-written my Event System in VB6... but let's not even go down that path.

After scratching my head for about half a second, and some nudging from @puf on the right direction, I decided to try writing a Custom Resolver for the Tridion Publisher.

And I was so amazed with the results that I thought I should share it with you.

There's quite a few differences between a Custom Resolver and the Event System approach, the main ones being that you write your code in native .NET (using TOM.NET objects) and that you do not completely disable link resolving - you just fiddle with the results instead.

Another great advantage of a Custom Resolver is that it is forwards-compatible: the code you write for Tridion 5.3 or 2009 will also work with Tridion 2011(*).

So, let's get to the code, shall we?

Create a class library, add references to Tridion.Common, Tridion.ContentManager and Tridion.ContentManager.Publishing.

Create a class that implements the Tridion.ContentManager.Publishing.Resolving.IResolver interface.

Create a void method as follows:

public void Resolve(IdentifiableObject item, ResolveInstruction instruction, PublishContext context, Tridion.Collections.ISet <ResolvedItem> resolvedItems)

The resolvedItems collection is exactly what it looks like: this is the list of items that will be published unless we interfere with it. It's just a collection, so feel free to iterate through it, determine its type, remove items from it, etc. There's a reasonably good sample on the Tridion docs, just search for Custom Resolver.

Just a few more words on the deployment:

• The assembly you create must go into the GAC
• You have to add your assembly to the Tridion.ContentManager.Config file in the "resolvers" section AFTER the default resolver from Tridion
• Restart the publisher and you're in business

(*) Hotfix CM_2011.0.1.74870 required in this pre-Service Pack 1 world.

PowerTools 2011

After some hard work from (mostly) Peter Kjaer, Chris Summers and Yoav Niran, the Power Tools project is finally under way.

As from yesterday, there is a guide outlining the steps required to create a power tool, so I thought it is about time to start recruiting more cooperation from the community.

The previous Tridion PowerTools were mostly a collection of ASP pages with some VBScript and Javascript helpers that provided a series of common functionalities:

• Progress bars for long-running processes
• Logging and debugging information
• Item Pickers

With the new Tridion 2011 UI and API (aka the Anguilla Framework) most of this functionality either broke or became obviously out-dated. Rather than taking the approach of making the power tools compatible with the new API (which would have been a monstrous task anyway) some people (Yoav and Chris mostly) had the guts to start this project from scratch.

Though some of the common functionalities are still "undeveloped", there is enough in place to start playing. We do have now a common progress bar (pretty impressive btw), a nice and mostly clean WebService-based framework, a common set of javascript tools to handle the webservice responses, etc.

The main missing point right now is an Item Picker, but there is some work happening on that one too.

As it is clear if you read the No-nonsense guide to creating a Power Tool, there's a whole bunch of files to create per PowerTool, and each file has a very specific - and required - purpose. As the platform evolves we will be merging more and more of these features into a Common library, but for now you have to live with it...

If you want to collaborate in this project - as we all hope you do - here's some of the things you may want to do:

1. Join the powertools discussion 
2. Join the IRC channel (yes! IRC! like in 1988) on freenode/#tridion
3. Design the behavior of the next powertools. As it is now, this project is full of development geeks, but severely lacking on usability experts or actual powertool users. We could certainly use some help from a Functional point of view
4. If you're dev-inclined, try out the guide mentioned above, and start playing with it. You may also want to write a better version of it, which we would ALL appreciate.
5. Finally - determining icon sets for the tools would be a great contribution too.

And hopefully someone will get around creating an installer for it...