I guess I have said it enough times - I am in a rather privileged position within the WCM space, as I get to see a lot of what really is implemented by our customer base (mostly in the highly regulated financial industry), I get to play with magic crystal balls, and I get to hear about what experts and analysts think content people should be doing now, and in the future.
And I admit, I am extremely confused, because the pieces don't fit together.
Let me try to explain what I mean with this.
On the one hand, we have simplicity. The people who select WCM systems (please note that I am not saying "Content Editors") want a "Facebook-like experience" creating content. They want the simplicity of WordPress or perhaps Blogger (which I use) when creating content.
On the other hand we have compliance and content governance. People want to control content life cycles, trace back the origins of content from its inception to its inclusion on a given page, to its transformation into a Call To Action on the home page, to its decommissioning a year later into the "outdated content" bin.
And finally, on the last hand (yes, I know those are three hands, get someone to lend you one), we want content re-purposing and targeting. We want content that can be used across all channels - Web, Email, Digital Signage, Facebook, Twitter, IOS/Android Apps, Google Glasses and what not.
And this is where I get confused.
Simplicity means one thing - less flexibility. Sure, you can make very reusable content with WordPress, but then you're putting the onus onto your editors to use the correct html mark-up for your content. I agree that a lot can be achieved with some smart plug-ins, but how do you prepare for the next channel that you don't know about yet? And especially, how do you create truly "re-formattable" content when you want simplicity, which by its own definition mixes content and layout?
And governance. Governance is impossible without metadata. Usually, it requires metadata about your metadata (ever tried defining a release policy linked to content models?). Again, sure, we can try having your editors enter that metadata in their simple-to-create-content web tool. Doesn't look so simple anymore, does it?
Creating content that can be re-purposed for various channels, including those that don't exist yet, and allows for personalization is where the whole thing falls apart in my view.
How can you have content that was simple to create - web based, WordPress like interface, loads of drag-and-drop widgets and SEO optimizers and navigation managers and whatnots - and have that content still comply to a strict schema, like those specified in schema.org? Sure, you can look at semantic engines - like Apache Stanbol - to help your editorial team get their content right, but how is that going to help you determine which headline to show on your iPhone app?
Don't take me wrong, I'm not trying to say that creating content should be hard - on the contrary, it must be easy. But creating content that can live beyond the constraints of a web page requires thinking beyond drag-and-drop and easy-to-use (actually, having to use your mouse when creating content is a terrible thing and completely breaks the flow of work) - you have to think about content modularity and new delivery models.
My view on the future of content is that layout and look-and-feel will disappear, and consumers of your content will care about nothing else than the content itself, the layout will be based on their preferences and their own metadata, with smart apps - in whatever is the device-du-jour - taking on the task of formatting that content for display. Don't think RSS, think Open Data+schema.org.
So, unless I'm terribly wrong (which is always possible and known to have happened many times), the emphasis on Customer Experience Management requires more content structure, not less. And more content structure, today, means that editors must have an abstract view of content, focus less on how it looks and more on how it's structured, so that the context in which the content is displayed can adapt to the customer's expectation. And to do that, we have to think beyond pages and re-think content as individual entities that can be manipulated and formatted for display in whatever device or app the customer may chose to consume it in. And that my friends, is against the view that content editing should be a simple, word-editing-like experience. Just like word editors were built for a world in which your main goal was to print that document once it was finished, many WCM tools out there are built to publish web pages, and web pages will be just a tiny fraction of how content is consumed in the future... (just like the number of people that actually print documents once they're finished with their editing).
Sunday, July 07, 2013
Sunday, April 14, 2013
SDL Tridion and Rich Text Fields
In the past year we've been asked a few times how to add support for non-XHTML tags to Tridion Rich Text Fields (if you want to know how, check here, here or here) and this usually gets followed by a discussion with questions along the lines of:
So, here's my take on why you're doing it for the wrong reasons. Yes, you can modify the rich text settings to allow entering any possible tag, but everytime you do this you are breaking the experience of your content editors for the sake of making your html markup work on your site.
When editors must create content that includes non-standard XHTML tags they will have to edit the html source of their content and add the tags themselves - guess how much of that will work when using Experience Manager? When implementing Tridion (or any other WCM) you may be tempted to take shortcuts to implement faster, and also to avoid having to review the HTML/Web app that you intend to use. But if your content editors are expected to edit their source html to insert "data-rule" attributes in links, you just made their life harder.
What should you do instead?
In my view, non-XHTML attributes required on content should be dealt with in the most user-friendly way. If you need to use <article> or <section> tags in your RTF, why not convert <div class="article"> to <article> at publish time? If you need to insert data attributes to links, then do consider a similar approach replacing other, normal attributes (or, at the very least, consider writing an extension that allows to add those tags without editing the html source).
Every time you ask an editor to edit the source of their html to add attributes you are asking them to dislike the system. Consider this when designing applications, making it hard to edit content has never been one of the goals for a WCM implementation project...
- Why do you want to do that?
- Why is it not there out-of-the-box?
- Is it supported?
So, here's my take on why you're doing it for the wrong reasons. Yes, you can modify the rich text settings to allow entering any possible tag, but everytime you do this you are breaking the experience of your content editors for the sake of making your html markup work on your site.
When editors must create content that includes non-standard XHTML tags they will have to edit the html source of their content and add the tags themselves - guess how much of that will work when using Experience Manager? When implementing Tridion (or any other WCM) you may be tempted to take shortcuts to implement faster, and also to avoid having to review the HTML/Web app that you intend to use. But if your content editors are expected to edit their source html to insert "data-rule" attributes in links, you just made their life harder.
What should you do instead?
In my view, non-XHTML attributes required on content should be dealt with in the most user-friendly way. If you need to use <article> or <section> tags in your RTF, why not convert <div class="article"> to <article> at publish time? If you need to insert data attributes to links, then do consider a similar approach replacing other, normal attributes (or, at the very least, consider writing an extension that allows to add those tags without editing the html source).
Every time you ask an editor to edit the source of their html to add attributes you are asking them to dislike the system. Consider this when designing applications, making it hard to edit content has never been one of the goals for a WCM implementation project...
Tuesday, April 02, 2013
R5 is dead. Long live R5
Today we finished the code base for SDL Tridion 2013 and released it to customer support. Though not a revolutionary release as SDL Tridion 2011 was, it brings a lot of functional enhancements to core Content Management features that our enterprise-level customers asked for, and (the best feature in my view) the ability to use non-Tridion content as "regular" Tridion assets.
(If you want to know more about what's new with SDL Tridion 2013, take a look at the community webinar recording).
A consequence of this release is that, keeping in line with our support policy, support for SDL Tridion 2009 should end in the next 6-12 months (we always support the last 2 major Tridion releases, and offer a "grace" period for the version prior to that), and this means the end of the R5 line.
SDL Tridion R5 was initially launched in October 2002 and introduced a LOT of concepts that were quite revolutionary for the WCM world at the time:
- Personalization & Profiling via Target Groups
- Browser-only, fully functional, business-friendly interface with Server-side XML and client side javascript (I guess I can't call it AJAX because AJAX didn't exist back then!)
- Extensible Event System allowing for implementation-specific automation
- XML everywhere
- Support for XSLT templates and VBScript/JScript templates
- Template Building Blocks!
- Component-based Content Management!
- Java & ASP Content Delivery modules
- Blueprinting!
Stop for a moment and think about how much (and how many times) the web changed since October 2002. Now consider that the same core architecture that powered sites in 2002 is still powering major sites today - that's foresight. It shows the designers of the R5 core knew what they were doing, and where the world was moving to. With Tridion 2011 ("R6") we did some much-needed refactoring of the interface (browser support & extensibility being the core new features) but also quite a lot of lower-level refactoring that allowed us to introduce new products quite rapidly after that release: Experience Manager, Online Marketing Explorer, User Generated Content) and finally with Tridion 2013 ("R7") the introduction of multi-item workflow (aka "Bundles") and External Content Libraries.
In other words, we're off to a good start on the R6/R7 dynasty - may it serve us (and our partners and customers) as well as the R5 architecture did.
Sunday, March 03, 2013
The rise of the corporate team player (good old TOM)
In case it isn't clear by now, I'll make it explicit: I love the Tridion Object Model API. Sure, our content delivery API is nice, and OData on the content delivery rocks.But me and the TOM was love at first sight (even if TOM never really acknowledged or even winked at me, I'm fine with this one-sided relationship). TOM has matured quite a lot in the past few years, moving from an extremely flexible COM+ architecture to a semi-functional .NET implementation (TOM.NET) to a fully functional one (with Tridion 2011) and with its WCF, service-oriented face ("CoreService") it just shines.
One of the intended benefits of adding a WCF face to TOM was to open up access to our Content Manager core to any client you would want to implement yourself or ourselves (for instance, the Content Manager Explorer and Experience Manager interfaces of our new soon-to-be-released Tridion 2013 use the CoreService to talk to the core), but a few things happened - perhaps unintended initially - with this new-found freedom to interact with Tridion: customers started looking at the CM as something that other applications can talk to.
And Tridion has one functionality that most other applications lack: it can push content to your website. Any type of content. At any time of the day. And though I wouldn't recommend using Tridion to push your 70 million transaction records to your website hourly, it actually fits really well if you don't need to republish your full catalog all the time (which typically is a sign of a bad architecture to start with, but let's not go there). A decoupled WCM will always have trouble with pushing time-sensitive information - like updating the price of 1700 products in the next 2 seconds while at the same time publishing your new 7000 pages website. But we have no trouble at all pushing product info to the website. Even if we don't manage it - or even know it exists beyond perhaps a SKU or product ID.
And I'm not the only one to have realized the potential of this. One of our customers is now routing all 3rd-party content via Tridion (through WCF) for editorial review and publishing to the website, something that was particularly painful for them to do before Tridion was added to the picture. Another one is considering using Tridion as the publishing mechanism for some "records stored in Oracle" that don't need editor attention - but do need to end up on the website, and that's hard to do with their current system. Yet another customer is looking at providing access to Tridion from their PIM, so "collections" of products can be published directly from the PIM's interface (while having Tridion do the heavy lifting).
This flexibility to play nice in the Enterprise is becoming more & more key to today's always on, always connected "modern enterprise" that must deal with aging products that are incredibly hard to upgrade or modify to cope with "simple things" like publishing to a website. But when all it takes is to call a webservice, upload a stream or structured content, and ask Tridion to "Please publish this to our Live site", the whole game changes. Suddenly, it's not black magic anymore to get something on the website.
And I love that too. EAI was my playground before Tridion, and now Tridion is providing EAI-lite features (don't hold your breath on having Tridion handle your bank transactions just yet, but as a publishing service provider for your internal tools it is awesome).
In a recent discussion with a customer we were debating whether to import product info into Tridion or keeping it where it is. The customer's architect was inclined to placing it all in Tridion, while we were telling them not to - probably a surprising action from a vendor, telling a customer to "not use our software to store your info" - but we had a really good reason for this: Tridion is not a PIM. It was not built as a PIM. It does not think as a PIM. So use your PIM for PIM-like tasks.
Likewise, your PIM is not built to publish stuff to the Web or manage it once its live. So don't use your PIM to publish to the web, just ask Tridion to do it for you.
I guess I may be quite a geek, but this idea of using software for what it was built, and talk to other software so they can complement each other, feels just like poetry to me. :-)
PS - It turns out the architect's previous experience with WCM was with a very large competitor of SDL, which has notorious problems playing nicely in the enterprise, and that's why he thought he would have to import all content into Tridion first. He has seen the light now!
One of the intended benefits of adding a WCF face to TOM was to open up access to our Content Manager core to any client you would want to implement yourself or ourselves (for instance, the Content Manager Explorer and Experience Manager interfaces of our new soon-to-be-released Tridion 2013 use the CoreService to talk to the core), but a few things happened - perhaps unintended initially - with this new-found freedom to interact with Tridion: customers started looking at the CM as something that other applications can talk to.
And Tridion has one functionality that most other applications lack: it can push content to your website. Any type of content. At any time of the day. And though I wouldn't recommend using Tridion to push your 70 million transaction records to your website hourly, it actually fits really well if you don't need to republish your full catalog all the time (which typically is a sign of a bad architecture to start with, but let's not go there). A decoupled WCM will always have trouble with pushing time-sensitive information - like updating the price of 1700 products in the next 2 seconds while at the same time publishing your new 7000 pages website. But we have no trouble at all pushing product info to the website. Even if we don't manage it - or even know it exists beyond perhaps a SKU or product ID.
And I'm not the only one to have realized the potential of this. One of our customers is now routing all 3rd-party content via Tridion (through WCF) for editorial review and publishing to the website, something that was particularly painful for them to do before Tridion was added to the picture. Another one is considering using Tridion as the publishing mechanism for some "records stored in Oracle" that don't need editor attention - but do need to end up on the website, and that's hard to do with their current system. Yet another customer is looking at providing access to Tridion from their PIM, so "collections" of products can be published directly from the PIM's interface (while having Tridion do the heavy lifting).
This flexibility to play nice in the Enterprise is becoming more & more key to today's always on, always connected "modern enterprise" that must deal with aging products that are incredibly hard to upgrade or modify to cope with "simple things" like publishing to a website. But when all it takes is to call a webservice, upload a stream or structured content, and ask Tridion to "Please publish this to our Live site", the whole game changes. Suddenly, it's not black magic anymore to get something on the website.
And I love that too. EAI was my playground before Tridion, and now Tridion is providing EAI-lite features (don't hold your breath on having Tridion handle your bank transactions just yet, but as a publishing service provider for your internal tools it is awesome).
In a recent discussion with a customer we were debating whether to import product info into Tridion or keeping it where it is. The customer's architect was inclined to placing it all in Tridion, while we were telling them not to - probably a surprising action from a vendor, telling a customer to "not use our software to store your info" - but we had a really good reason for this: Tridion is not a PIM. It was not built as a PIM. It does not think as a PIM. So use your PIM for PIM-like tasks.
Likewise, your PIM is not built to publish stuff to the Web or manage it once its live. So don't use your PIM to publish to the web, just ask Tridion to do it for you.
I guess I may be quite a geek, but this idea of using software for what it was built, and talk to other software so they can complement each other, feels just like poetry to me. :-)
PS - It turns out the architect's previous experience with WCM was with a very large competitor of SDL, which has notorious problems playing nicely in the enterprise, and that's why he thought he would have to import all content into Tridion first. He has seen the light now!
Saturday, January 26, 2013
My Tridion VM bootstrap project
As part of my luxurious and privileged seat in Tridion Product Management I get to test new stuff all the time. It's great to just point my browser to the build server and download the latest nightly build (stable or unstable) and start playing around with it - how's the notification area behaving? Can I assign tasks now? How's the workflow engine doing? etc.
While this is great, it has a certain, heavy, repetitiveness to it. Every time I get a new build I need to either completely uninstall Tridion and start again (we obviously don't bother doing migration scripts between minor builds) or start from a completely new VM.
And this means:
So I started, slowly, creating a series of C# command prompt programs to automate stuff for me. Initially these scripts would just create my diamond-shaped blueprint, a set of schemas, and some components. Then, I added a script to import content via RSS so I get some real content in it. Then, I expanded it to also create pages for these components. Then I added configuring the Publication Targets and Target Types. Then I added expanding the Tridion pre-build web applications and copying the configuration for these. Then I added actually creating the sites in IIS. Then I added support for all this to be configured via a XML file. Then I added changing the default templates to include Experience Manager building blocks. And finally I added support for Tridion 2011 too.
And now I decided to share it with everyone. The two projects I use to prepare my environments are available under MIT license on Google code.
There are 2 projects in here: CreateAnEnvironmentForMe and ImportContentFromRss. Each does what its name implies, and there's reasons why they are separate which I won't care to elaborate. I also offer no support whatsoever and really just hope the community can help evolve this solution to something a bit more stable. This code is not intended to be used in Production Environments, and there's no guarantees it will work for you.
These tools are tools I use, and they're fit for me to use them. If you need more rounded corners to use it, please feel free to change it - contact me via this forum or the google project if you want committer rights on the project. I typically run these projects from within Visual Studio, because I expect them to fail here and there, and this allows me to quickly fix them.
Hope this project can help others out there.
While this is great, it has a certain, heavy, repetitiveness to it. Every time I get a new build I need to either completely uninstall Tridion and start again (we obviously don't bother doing migration scripts between minor builds) or start from a completely new VM.
And this means:
- Create new blueprint
- Create new schemas
- Create new content
- Create new publication target(s)
- Configure Content Delivery for HTTP Upload
- Configure Website
- Configure Session Preview/Experience Manager
So I started, slowly, creating a series of C# command prompt programs to automate stuff for me. Initially these scripts would just create my diamond-shaped blueprint, a set of schemas, and some components. Then, I added a script to import content via RSS so I get some real content in it. Then, I expanded it to also create pages for these components. Then I added configuring the Publication Targets and Target Types. Then I added expanding the Tridion pre-build web applications and copying the configuration for these. Then I added actually creating the sites in IIS. Then I added support for all this to be configured via a XML file. Then I added changing the default templates to include Experience Manager building blocks. And finally I added support for Tridion 2011 too.
And now I decided to share it with everyone. The two projects I use to prepare my environments are available under MIT license on Google code.
There are 2 projects in here: CreateAnEnvironmentForMe and ImportContentFromRss. Each does what its name implies, and there's reasons why they are separate which I won't care to elaborate. I also offer no support whatsoever and really just hope the community can help evolve this solution to something a bit more stable. This code is not intended to be used in Production Environments, and there's no guarantees it will work for you.
These tools are tools I use, and they're fit for me to use them. If you need more rounded corners to use it, please feel free to change it - contact me via this forum or the google project if you want committer rights on the project. I typically run these projects from within Visual Studio, because I expect them to fail here and there, and this allows me to quickly fix them.
Hope this project can help others out there.
Wednesday, January 09, 2013
Whatever the future may bring... will be outdated soon
Had an interesting request from a customer recently:
Whatever the future may bring has been pretty much my domain lately. I knew that moving from Professional Services to Product Management would bring a rather large set of changes. For instance, I can't really complain about feature X not being in the product, since it is my job to decide what goes in the product. Another interesting change is that now everyone thinks I need their advice :)
Anyway, the future proofing of anything we do is not a small challenge, and it applies to everything we do today. For instance, my LinkedIn profile stated:
So here we are, trying to decide how to future-proof a product, and we can't even write text that won't be obsolete next year. I was privileged to have seen Mike Walsh present at Innovate last year, and one slide that made an impression on me was this one. Yes it does, unfortunately it's a one-way communication channel.
So, how do I prepare for "whatever the future may bring"?
I guess this is one of the advantages of having a relatively light foot-print in our content delivery stack. You want 2001-style XML flat file publishing? You got it. 1999 style JSP with embedded code? You got it. Even (God almighty protect us all) VBScript ASP pages? You got it. What about MVC? You got that too. What about Service-based? Yup, got it (with OData no less).
So, what's next?
I have my own ideas about what's next, and we're working hard to 1) validate those ideas and 2) build it into the product, but can't share that just yet (another one of those things that change with being in Product Management - don't talk about what you can't commit to). Keeping in line with what we built up to today, it will be something that you can extend the hell out of, and will have lots of functionality you will not discover until 3 years later... (WAI anyone?) And maybe, just maybe, we can finally drop Classic ASP support ;-)
Ensure that the product will continue to support different form-factors and whatever the future may bring.How can I answer that with anything else than a very bold "Of course!"?
Whatever the future may bring has been pretty much my domain lately. I knew that moving from Professional Services to Product Management would bring a rather large set of changes. For instance, I can't really complain about feature X not being in the product, since it is my job to decide what goes in the product. Another interesting change is that now everyone thinks I need their advice :)
Anyway, the future proofing of anything we do is not a small challenge, and it applies to everything we do today. For instance, my LinkedIn profile stated:
With 10+ years of experience, of which 8+ as a consultantThough it might sound interesting, it had been written in 2004, making it quite out-of-date for something that contains numbers (I updated it now), which in turn made me rewrite my SDLTridionWorld profile to let you do the math instead.
So here we are, trying to decide how to future-proof a product, and we can't even write text that won't be obsolete next year. I was privileged to have seen Mike Walsh present at Innovate last year, and one slide that made an impression on me was this one. Yes it does, unfortunately it's a one-way communication channel.
So, how do I prepare for "whatever the future may bring"?
I guess this is one of the advantages of having a relatively light foot-print in our content delivery stack. You want 2001-style XML flat file publishing? You got it. 1999 style JSP with embedded code? You got it. Even (God almighty protect us all) VBScript ASP pages? You got it. What about MVC? You got that too. What about Service-based? Yup, got it (with OData no less).
So, what's next?
I have my own ideas about what's next, and we're working hard to 1) validate those ideas and 2) build it into the product, but can't share that just yet (another one of those things that change with being in Product Management - don't talk about what you can't commit to). Keeping in line with what we built up to today, it will be something that you can extend the hell out of, and will have lots of functionality you will not discover until 3 years later... (WAI anyone?) And maybe, just maybe, we can finally drop Classic ASP support ;-)
Tuesday, November 27, 2012
StackExchange and the [tridion] tag
If you use any of the Tridion community resources, you have certainly started using StackOverflow for your Tridion questions (or for your daily dose of questions).
However, we seem to have started abusing the principles of StackOverflow - programming questions - and getting more and more configuration questions.
While, obviously, our community members rush out to try to help, it will probably not be long before someone starts closing off threads that ask no real question, no real programming question, or that are just discussion starters.
The number of open-ended, non-programming questions is annoying (to say the least). Luckily, the people behind StackExchange know very well that not all IT questions are programming questions, so there are other sites that we can use for all yourTridion Software knowledge questions:
- ServerFault
- SuperUser
So, next time you're going to ask on StackOverflow how to configure Session Preview, or how to best design a workflow, please take a minute to consider if this is a programming question, and if this should be in Stack Overflow. Server configuration questions are better suited for ServerFault, while usability questions should go in SuperUser. Simple.
If you're afraid that people may miss it (since most people only monitor Stack Overflow after all), then perhaps shout out on the Tridion Forum too. The MVPs typically pick up on these things quite fast, and the community will continue growing without impacting our generous hosts at SO.
Yes, I also agree that we should have a Tridion-dedicated Stack Exchange site. That's why I committed to this proposal on Area 51, as I am sure you have too.
However, we seem to have started abusing the principles of StackOverflow - programming questions - and getting more and more configuration questions.
While, obviously, our community members rush out to try to help, it will probably not be long before someone starts closing off threads that ask no real question, no real programming question, or that are just discussion starters.
The number of open-ended, non-programming questions is annoying (to say the least). Luckily, the people behind StackExchange know very well that not all IT questions are programming questions, so there are other sites that we can use for all your
- ServerFault
- SuperUser
So, next time you're going to ask on StackOverflow how to configure Session Preview, or how to best design a workflow, please take a minute to consider if this is a programming question, and if this should be in Stack Overflow. Server configuration questions are better suited for ServerFault, while usability questions should go in SuperUser. Simple.
If you're afraid that people may miss it (since most people only monitor Stack Overflow after all), then perhaps shout out on the Tridion Forum too. The MVPs typically pick up on these things quite fast, and the community will continue growing without impacting our generous hosts at SO.
Yes, I also agree that we should have a Tridion-dedicated Stack Exchange site. That's why I committed to this proposal on Area 51, as I am sure you have too.
Saturday, November 24, 2012
How would you do it without Tridion?
I see myself being quoted more & more on the above question, which is one of my favorite answers to most Tridion implementation questions.
So I thought it was time to start putting here some of the questions that made me come up with that answer... Just walk through these questions and - in your mind - answer each with "How would I do it without Tridion?" - you'll find that the answer is almost always exactly the same when you do something with Tridion or without it, which I think is one the greatest strengths of this amazing product. These are real questions that I have been asked (some more often than others) in the past years:
I know this puts me in a conflict with the drag-and-droppers out there, who want to be able to drag-and-drop everything and their mother into a page, without really thinking of consequences. I'll give you the consequences at a later post...
So I thought it was time to start putting here some of the questions that made me come up with that answer... Just walk through these questions and - in your mind - answer each with "How would I do it without Tridion?" - you'll find that the answer is almost always exactly the same when you do something with Tridion or without it, which I think is one the greatest strengths of this amazing product. These are real questions that I have been asked (some more often than others) in the past years:
- How do I do A/B Testing with Tridion?
- How do I configure a reverse proxy for my Tridion website?
- How do I integrate comments into my pages?
- How do I integrate search into my website?
- How do I call a webservice from a template?
- How do I check my website performance?
- How do I add analytics?
- How do I improve my SEO?
- How do I add a Javascript or CSS file to my pages?
I know this puts me in a conflict with the drag-and-droppers out there, who want to be able to drag-and-drop everything and their mother into a page, without really thinking of consequences. I'll give you the consequences at a later post...
Monday, October 15, 2012
Validating content on Save - Part 2 now available
The much awaited 2nd part of the "Validating content on save" series is now online, thanks to Robert Curlette for taking over this epic effort.
Monday, October 01, 2012
Changes
As hinted on my last post - and as made public by the Toronto User Group announcement a couple of weeks ago - I have, as of today, left the wonderful world of Professional Services and started a new challenge on the also wonderful world of Product Management.
I have been a consultant for almost all of my Professional career (15 of 17 years), and have pretty much covered many of the possible ways of building (in no particular order) email servers, firewalls, Windows domains, user directories (pre- and post-LDAP), TCP/IP addressing strategies, intranets, extranets, internet, collaboration servers, application servers, transformation services, open source, closed source, free, expensive, sgml, html (2,3,4 & 5), wml, xml, xhtml, VB, VBA, VBScript, C, C++, Informix 4gl, Clipper, PL/SQL, xslt, collaboration strategies, workflow processes, automation - from factory to work processes, so many integration frameworks, c#, java, php, javascript, data management (big and small data), structured and unstructured data, search engines, recommendation engines, monitoring engines, migration tools, social media, rss, odata, oauth, unix servers, websphere, weblogic, tomcat, jboss, iis, apache, wcf, wwf, xaml, saml, browser debugging tools, memory debugging tools, network debugging tools, and so much more, and always - throughout all these years - kept my customer first mantra. Customer is always right - except when the customer is wrong, in which case it is my duty to point this out to the customer, so that the customer may be right.
This served me well in the past, and I am counting on this instinct to serve me even better in the future. I am extremely happy about having made this move, and being able to influence the future direction of SDL software - Tridion in particular - while keeping my customers first.
I'll be posting regularly on how this transition goes, and certainly about all the new & exciting stuff we will be building at SDL!
See you all on the other side!
I have been a consultant for almost all of my Professional career (15 of 17 years), and have pretty much covered many of the possible ways of building (in no particular order) email servers, firewalls, Windows domains, user directories (pre- and post-LDAP), TCP/IP addressing strategies, intranets, extranets, internet, collaboration servers, application servers, transformation services, open source, closed source, free, expensive, sgml, html (2,3,4 & 5), wml, xml, xhtml, VB, VBA, VBScript, C, C++, Informix 4gl, Clipper, PL/SQL, xslt, collaboration strategies, workflow processes, automation - from factory to work processes, so many integration frameworks, c#, java, php, javascript, data management (big and small data), structured and unstructured data, search engines, recommendation engines, monitoring engines, migration tools, social media, rss, odata, oauth, unix servers, websphere, weblogic, tomcat, jboss, iis, apache, wcf, wwf, xaml, saml, browser debugging tools, memory debugging tools, network debugging tools, and so much more, and always - throughout all these years - kept my customer first mantra. Customer is always right - except when the customer is wrong, in which case it is my duty to point this out to the customer, so that the customer may be right.
This served me well in the past, and I am counting on this instinct to serve me even better in the future. I am extremely happy about having made this move, and being able to influence the future direction of SDL software - Tridion in particular - while keeping my customers first.
I'll be posting regularly on how this transition goes, and certainly about all the new & exciting stuff we will be building at SDL!
See you all on the other side!
Tuesday, September 18, 2012
Discontinuing series
The promised series on how to Validate Content on save will have to be put on hold, due to some decisions I took recently.
Anyway, the good news is that I passed on the content I had already developed for that series to another member of our great community, and I am sure he will post the remaining blogs on how to validate content with Anguilla on his blog sometime soon.
The other even better news is that I will be moving on to a more product-centric position within SDL CMT (Content Management Technologies) and really looking forward to it. More to be announced soon.
Anyway, the good news is that I passed on the content I had already developed for that series to another member of our great community, and I am sure he will post the remaining blogs on how to validate content with Anguilla on his blog sometime soon.
The other even better news is that I will be moving on to a more product-centric position within SDL CMT (Content Management Technologies) and really looking forward to it. More to be announced soon.
Tuesday, July 17, 2012
Validating content on Save - Part 1 of many
Recently I had to do a project where we are validating quite some content options whenever the editors decide their work is done. This got me thinking about sharing some of these experiences. This post is the first of a few that I have lined up on this subject, and where I try to cover the available options for content validation from the simple (and cheap) ones to the very complex and over-engineered.
For (many) years, the solution to the eternal "how do I validate content" question with Tridion has been a combination of making fields mandatory and using the Event System (OnComponentSavePre anyone?).
Recently I had to take a different approach to this, since Tridion 2011 brings all this amazing extensibility framework (codenamed Anguilla) that allows to do whatever we want with our content, right? While this is true, the correct answer comes in many shades of gray, and the biggest obstacle on creating a great solution for validating content for your editors is the learning curve.
Let’s think about how we can do this, by taking a very simple example, then growing it out to bigger things. In the first scenario we're covering in this series of posts, we will focus on how to validate that a field named "Title" starts with a capital letter, and we'll do this using 3 different approaches:
This will now force our field to start with an upper case letter, and Tridion will enforce the rule.
If I now try to save my content, Tridion will let me know I don’t understand what I’m doing:
And since I won’t understand the error message either, this becomes more complex than what we can handle with simple schema restrictions…
There are other simple scenarios, particularly with number fields, that Tridion handles quite gracefully (by not allowing the editor to type a number higher than specified in "xsd:maxInclusive" for instance), or limiting the maximum number of characters you can type in a field. However, fairly quickly we fall into a domain where business logic is required to validate fields (common examples are Start and End Dates for events, where you depend on 2 fields to provide the correct validation).
So this was the "cheap" content validation: schema restrictions.
Let’s go now to the 2nd option, using the Event System.
Taking the same example from above (first character must be upper case) we could take one of 2 approaches: Let the user know that the first letter must be upper case, or automatically changing it. Which approach you take depends on your organization’s culture. In some companies it is OK to have the system take decisions for you, while other organizations need to give the editorial team full control about any content that gets created. Let's build an event system to deal with the second approach (letting the editors know about the errors of their ways):
Step 1: create an Event Class Library with Visual Studio.
Add some references from [Tridion-Home]\bin\client
Then let’s write some code to validate if your first character is upper case, and notify the editor if that’s not the case.
Restart Tridion (COM+ and Service Host) and let’s see what it does.
So, it’s a nice improvement from the previous message. Cost of development? Well, it took me about 20 minutes to write it and deploy it (fair enough, it’s far from ready, with things that you shouldn’t see in production like "if (component.Schema.Title != "Article") return;"), but you get the picture.
You could also just be slightly smart about it and outline this requirement in the field’s description:
But this is too specific to this use case, and it’s a simple one after all.
Next (within a few days, I promise) we will start looking at how we could do this with Anguilla.
For (many) years, the solution to the eternal "how do I validate content" question with Tridion has been a combination of making fields mandatory and using the Event System (OnComponentSavePre anyone?).
Recently I had to take a different approach to this, since Tridion 2011 brings all this amazing extensibility framework (codenamed Anguilla) that allows to do whatever we want with our content, right? While this is true, the correct answer comes in many shades of gray, and the biggest obstacle on creating a great solution for validating content for your editors is the learning curve.
- Schema restrictions
- Event System
- CME Command Extension
<xsd:element maxoccurs="1" minoccurs="1" name="Title"> <xsd:annotation> <xsd:appinfo> <tcm:extensionxml xmlns:tcm="http://www.tridion.com/ContentManager/5.0"></tcm:extensionxml> </xsd:appinfo> </xsd:annotation> <xsd:simpletype> <xsd:restriction base="xsd:string"> <xsd:pattern value="[A-Z][A-Za-z0-9_ ]*"></xsd:pattern> </xsd:restriction> </xsd:simpletype> </xsd:element>
This will now force our field to start with an upper case letter, and Tridion will enforce the rule.
If I now try to save my content, Tridion will let me know I don’t understand what I’m doing:
There are other simple scenarios, particularly with number fields, that Tridion handles quite gracefully (by not allowing the editor to type a number higher than specified in "xsd:maxInclusive" for instance), or limiting the maximum number of characters you can type in a field. However, fairly quickly we fall into a domain where business logic is required to validate fields (common examples are Start and End Dates for events, where you depend on 2 fields to provide the correct validation).
So this was the "cheap" content validation: schema restrictions.
Let’s go now to the 2nd option, using the Event System.
Taking the same example from above (first character must be upper case) we could take one of 2 approaches: Let the user know that the first letter must be upper case, or automatically changing it. Which approach you take depends on your organization’s culture. In some companies it is OK to have the system take decisions for you, while other organizations need to give the editorial team full control about any content that gets created. Let's build an event system to deal with the second approach (letting the editors know about the errors of their ways):
Step 1: create an Event Class Library with Visual Studio.
Add some references from [Tridion-Home]\bin\client
Then let’s write some code to validate if your first character is upper case, and notify the editor if that’s not the case.
using System;
using System.Collections.Generic;
using Tridion.ContentManager.ContentManagement;
using Tridion.ContentManager.ContentManagement.Fields;
using Tridion.ContentManager.Extensibility;
using Tridion.ContentManager.Extensibility.Events;
namespace ValidateTitleFieldUpperCaseFirstLetter
{
[TcmExtension("ValidateTitleFieldUpperCaseFirstLetter")]
public class Validate : TcmExtension, IDisposable
{
private readonly List<EventSubscription> _subscriptions = new List<Eventsubscription>();
public Validate()
{
Subscribe();
}
private void Subscribe()
{
EventSubscription subscription =
EventSystem.Subscribe<Component, SaveEventArgs>(ValidateFirstLetterIsUpperCase, EventPhases.Initiated);
_subscriptions.Add(subscription);
}
private void ValidateFirstLetterIsUpperCase(Component component, SaveEventArgs args, EventPhases phases)
{
if (component.Schema.Title != "Article") return;
if (component.ComponentType != ComponentType.Normal) return;
ItemFields fields = new ItemFields(component.Content, component.Schema);
SingleLineTextField titleField = (SingleLineTextField)fields["Title"];
if(titleField.Values.Count == 0)
{
// Tridion should take care of this, but just in case someone changed the field to optional
throw new Exception("Title field is mandatory.");
}
string fieldContent = titleField.Value;
if(char.IsLower(fieldContent[0]))
{
throw new Exception("The first letter of the Title field must be a Capital letter.");
}
}
public void Dispose()
{
foreach (EventSubscription subscription in _subscriptions)
{
subscription.Unsubscribe();
}
}
}
}
Now let’s build our code and tell Tridion to execute it (add a line similar to this to Tridion.ContentManager.Config under "<extensions>"<add assemblyFileName="D:\Tridion 2011\PathToYourDll\ValidateTitleFieldUpperCaseFirstLetter.dll" />
Restart Tridion (COM+ and Service Host) and let’s see what it does.
So, it’s a nice improvement from the previous message. Cost of development? Well, it took me about 20 minutes to write it and deploy it (fair enough, it’s far from ready, with things that you shouldn’t see in production like "if (component.Schema.Title != "Article") return;"), but you get the picture.
You could also just be slightly smart about it and outline this requirement in the field’s description:
Next (within a few days, I promise) we will start looking at how we could do this with Anguilla.
Labels:
anguilla,
c#,
content validation,
event system,
projects,
schemas,
tom.net,
tridion,
tridion 2011,
tridion cme,
xml
9
comments
Subscribe to:
Posts (Atom)