Folks that work with me know that I’m not a super-awesome programmer; I’m a front-end guy who dables with programs. I’m way more comfortable telling you what went wrong with your CSS in Internet Explorer 8 than what happened with your Razor template in Tridion 2011. Razor Mediator for Tridion is a blend of C# and .NET that just operates about two levels higher than where I am most of the time. As a result, I often spend time trying to figure out what information there is on a component and how to grab it. So a few weeks ago, I went from knowing that Razor could access TOM.NET to actually understanding it, and as a result I wrote a little debugging TBB to help other front-end guys looking to figure this thing out.
Razor for Front-End Guys
If you’re a front-end guy who’s spent any time writing page templates and component templates in Tridion, you’re well-acquainted with DWT (Dreamweaver templating). DWT is the least programmy way to put together a page —it’s just some customized HTML tags. Because DWT isn’t very programmy, it’s perfect for front-end guys whose programming experience hasn’t gone further than JavaScript. DWT has tons of limitations, though. The moment you want to access something that isn’t on the component itself, things get exponentially harder as you have to start writing helper TBBs, C# blocks, or worse. In a Tridion implementation where the only option is DWT, it’s hard for a pure front-end guy to be very useful for very long.
When I encountered Razor for the first time, it was a bit rocky. Because I was more designer than developer, it was harder for me to accept the new way of seeing my TBBs; I had to get used to seeing more ‘programmy’ things mixed in with the markup. Getting used seeing programming gunk mixed with markup is a small hurdle, though. Getting used to the Razor syntax was another. Writing foreach
, if
, switch
, and other statements was a bit more difficult because I didn’t know anything about C#. But, JavaScript and C# come from the same family of languages, so if you can write well-formed JavaScript, you can figure out how to write Razor with a little trial and error. Once you get through the learning curve, Razor will save days if not weeks of development time for CTs and PTs. Not only that, the guy writing the HTML can actually build the templates.
Razor for Sharpening Templates
Now, as a front-end guy, I knew that Razor was .NET, and that it accessed the TOM.NET API. But I didn’t always understand that. Again, as a front-end guy, Razor just made it easier to take fields and wrap them in HTML. My understanding of Razor was limited to simply the methods that Alex had put in his documentation.
Razor isn’t just for accessing a few fields on a component, though. Razor lets you access whatever you want on that component. Alex has written kind of ‘short-hand’ methods for things like getting fields and metadata, but the options don’t end with what he wrote in the documentation. You can actually get any property or method that exists on a component — because Razor accesses TOM.NET. All you have to do is access the TridionObject
first. So if you’re dealing with a binary schema, and you wanted to get the file name, you can: @Component.TridionObject.BinaryContent.Filename
. If you wanted to get the root element of the component’s schema, it’s just @Component.TridionObject.Schema.RootElementName
. So not only does Razor make templating more efficient, it makes Tridion templates more powerful.
Building a Debugging TBB for Components
Once it clicked that I could access previously-unavailable properties by starting with TridionObject
, I made a ‘debugger TBB’. I cracked open the TOM.NET API documentation, looked at all the properties that exist for the the Component class, and decided to output them. Once I did that, I wrapped it in some pretty HTML, and added a touch of CSS so that it would be easier to read. So take this Razor that you see and add it to a TBB. Then make a Component Template that uses it, and link that CT to all of your schemas in your dev environment. Now you have both a list of stuff you can access, and a way to see all of the stuff you need, for any given component.
What this Razor will tell you:
This will output everything you can imagine:
- Fields and their values
- Multimedia information: Filename, filesize, type
- Schema Information
- Metadata fields and values
- Version History
- Containing folders or publications
- Keywords
- Items it uses
Problems you might run into
I’m using Razor 1.3.2 which has the GetFields()
method. If you aren’t on 1.3.2, either upgrade, or remove these code blocks.
I also wrote this using HTML5’s summary
and details
elements, which are browser-based expand/collapse elements. So, when you preview a component using this TBB, use Chrome first.
@using System.IOTitle: @Component.Title
Fields and Values
@foreach (var field in @Fields.GetFields()) { Field Value } @field.Key @field.Value @if(Component.TridionObject.ComponentType.ToString() =="Multimedia"){
ComponentType: @Component.TridionObject.ComponentType
}
FileName @Component.TridionObject.BinaryContent.Filename Filesize @Component.TridionObject.BinaryContent.FileSize Is external @Component.TridionObject.BinaryContent.IsExternal MultimediaType @Component.TridionObject.BinaryContent.MultimediaType
UploadFromFile @Component.TridionObject.BinaryContent.UploadFromFile UploadFromStream @Component.TridionObject.BinaryContent.UploadFromStream
Schema: @Component.Schema
Schema information Title @Component.TridionObject.Schema.Title Purpose @Component.TridionObject.Schema.Purpose root element @Component.TridionObject.Schema.RootElementName
Metadata: @(Component.Metadata != null ? "has metadata" : "no metadata ")
metadata schema: @Component.MetadataSchema
Metadata Fields and Content @foreach (var field in @Component.Metadata.GetFields()) { Field Value } @field.Key @field.Value
Version and Revision Info
Version @Component.TridionObject.Version Revision Date @Component.TridionObject.RevisionDate Revision @Component.TridionObject.Revision
Revisor @Component.TridionObject.Revisor description @Component.TridionObject.Revisor.Description title @Component.TridionObject.Revisor.Title is admin @Component.TridionObject.Revisor.IsSystemAdministrator WebDav Url: @Component.WebDavUrl
path: @Component.Path
Session: @Component.TridionObject.Session
Owning repository: @Component.TridionObject.OwningRepository
Title @Component.TridionObject.OwningRepository.Title Publication Key @Component.TridionObject.OwningRepository.Key Multimedia Path @Component.TridionObject.OwningRepository.MultimediaPath Multimedia URL @Component.TridionObject.OwningRepository.MultimediaUrl HasChildren @Component.TridionObject.OwningRepository.HasChildren RootFolder @Component.TridionObject.OwningRepository.RootFolder
( @Component.TridionObject.OwningRepository.RootFolder.Title )RootStructureGroup @Component.TridionObject.OwningRepository.RootStructureGroup
( @Component.TridionObject.OwningRepository.RootStructureGroup.Title )Organization item: @Component.TridionObject.OrganizationalItem
LockType: @Component.TridionObject.LockType
LoadState: @Component.TridionObject.LoadState
IsShared: @Component.IsShared
IsPublishedInContext: @Component.TridionObject.IsPublishedInContext
IsLocalized: @Component.IsLocalized
Allowed Actions: @Component.TridionObject.AllowedActions
ApprovalStatus: @Component.TridionObject.ApprovalStatus
Keywords
@foreach (var keyword in Component.TridionObject.GetUsedKeywords()){
} @keyword.Id @keyword.Title
Items this uses
@foreach(var usedItem in Component.TridionObject.GetUsedItems()){
} @usedItem.Id @usedItem.Title
Items this is used in
@foreach(var usedItem in Component.TridionObject.GetUsingItems()){
} @usedItem.Id @usedItem.Title
Permalink
Good to see you expanding your comfort-zone. Maybe others will take heart from this and take on the deadly TOM! The best programmers always write code to help them write code, and this is a good example of that. There is some ready-made tooling that might also come in useful in this area. I’m thinking of the ItemXml power tool, and of course, Tridion’s own (often ignored?) default templates.
Permalink
Thanks Dominic. I’m vaguely aware of the ItemXML Power Tool, but I don’t have it installed with the other power tools I’m using for this particular implementation. But you’re right, that’s a good developer utility.
And you know… I’m just as guilty as anyone for ignoring those default templates. Good Point.