It’s been a while since I did a full Tridion implementation, and mostly I review/advise on other people’s implementations nowadays, but there’s something that I have always failed to see in other people’s implementation and I wonder why: the use of Domain Specific classes.
Let’s look at some examples, by taking some simple content types. Assume a schema with:
Name – Article Author – Component Link to “Person” Component PublishedDate – DateTime field Summary – RTF, 5 line summary Content – RTF, full content ContentClassification – multi-value keyword field
In a “normal” implementation you will then proceed to see loads of code like this:
If you would have just been a bit lazier you could have created a class like this:
And now your code would be a much more readable and friendly to use:
And you don’t need to explain so much about Tridion to any of the untrained newbies that got assigned to your project.
So – why don’t we see this being used more often? Discuss.
5 thoughts on “Making your life simpler as a Tridion Developer”
Well, maybe becouse sofar i have not seen any good reason to use C# templates over DWR templates (other than the developer showing of his mad C# skills) and the DWR template syntax is even more lazier 😉
I know there are situations that a DWR template will not do the job, but if we are talking about informational websites (which make up most of out projects), most of the pages will be plain content, so no C# templates needed (apart from some TBBs for manipulating the package). This leaves us to some more dynamic stuff like apps or interactive content. Still in a lot of ways i say most solutions are overcomplicated to what the customer would need to satisfy.
I can remember a blog stating that nowadays a lot of implementations are overrated, like calling everything a GUI Extension while its not, same thing aplies here: KISS, that would make our lives much easier and would spend the budgets of the customer much better way #safetheworldMoreKISS(es)
but again, if you’re one of those developers i mentioned before, sure it seems your job becomes dull, just make sure that the customer will profit from your playtime, becouse that is whats its all about in the end.
Though I do understand the point about Dreamweaver Templates, I run more & more into scenarios where DW must be “supplied” of data from other sources (other components, folder/sg metadata, etc) and it’s in these cases that I see Tridion c# code that is more complex than it needs to be.
Spending 2 hours creating proper classes for your content will save you days over the course of an implementation – especially when someone else needs to pick up on your job.
Hi Nuno,
Great idea.
I think one reason this isn’t done is that often the Template Building Blocks are built with re-use in mind, not just across the current site in question but across projects. So maybe in that case it is easier to think in terms of the Tridion domain rather than the business domain.
I’ve been thinking about splitting my TBB libraries up into smaller components, so maybe the generic reusable ones could be split out and then project specific ones built around a class library as you describe.
I think the classic “instant” (CPs on a page = HTML) site approach will be around for a while. But customers that come from different, possibly homegrown, CMS and unique (strict) rendering requirements may want their proprietary content format in XML or JSON. Domain specific classes would help here, especially if the actual HTML markup and styles (rendering) is done presentation side. I’m seeing more projects/requests for mobile, external web services, analytics, personalization, GUI extensions which supports Nuno’s point on external data.
I think we skip this domain-specific abstractions more often when the customer doesn’t really “own” the Tridion template code. If the Tridion consultant knows the Tridion model and there’s no one to explain it to, there’s no need to make it simpler. Add deadlines and there’s less time to understand how you’d want to wrap code (though I’ve seen it brought up early on in projects).
On the other hand, we see this approach frequently in CD-side implementations. Devs gravitate towards a vendor-agnostic formats that hide the “Tridionness.” We’ve seen wrappers, XML content configs, and frameworks built to smooth out the difference between Tridion and the business model (CWA, DD4T, and other dynamic implementations).
CD-heavy implementations might also skip CM-side C# development all-together–not everyone has a fifth environment to play with. 😉
This sounds like DD4T v0.1 (or the .net framework Q created around 2008 to decouple Tridion dependencies into a ‘neutral’ class model).
Well, maybe becouse sofar i have not seen any good reason to use C# templates over DWR templates
(other than the developer showing of his mad C# skills) and the DWR template syntax is even more lazier 😉
I know there are situations that a DWR template will not do the job, but if we are talking about informational websites (which make up most of out projects), most of the pages will be plain content, so no C# templates needed (apart from some TBBs for manipulating the package). This leaves us to some more dynamic stuff like apps or interactive content. Still in a lot of ways i say most solutions are overcomplicated to what the customer would need to satisfy.
I can remember a blog stating that nowadays a lot of implementations are overrated, like calling everything a GUI Extension while its not, same thing aplies here: KISS, that would make our lives much easier and would spend the budgets of the customer much better way
#safetheworldMoreKISS(es)
but again, if you’re one of those developers i mentioned before, sure it seems your job becomes dull, just make sure that the customer will profit from your playtime, becouse that is whats its all about in the end.
Though I do understand the point about Dreamweaver Templates, I run more & more into scenarios where DW must be “supplied” of data from other sources (other components, folder/sg metadata, etc) and it’s in these cases that I see Tridion c# code that is more complex than it needs to be.
Spending 2 hours creating proper classes for your content will save you days over the course of an implementation – especially when someone else needs to pick up on your job.
Hi Nuno,
Great idea.
I think one reason this isn’t done is that often the Template Building Blocks are built with re-use in mind, not just across the current site in question but across projects. So maybe in that case it is easier to think in terms of the Tridion domain rather than the business domain.
I’ve been thinking about splitting my TBB libraries up into smaller components, so maybe the generic reusable ones could be split out and then project specific ones built around a class library as you describe.
Rob
@Ingmar, +1 to simple. It’s “not always an extension.” http://www.createandbreak.net/2012/08/not-always-extension.html
I think the classic “instant” (CPs on a page = HTML) site approach will be around for a while. But customers that come from different, possibly homegrown, CMS and unique (strict) rendering requirements may want their proprietary content format in XML or JSON. Domain specific classes would help here, especially if the actual HTML markup and styles (rendering) is done presentation side. I’m seeing more projects/requests for mobile, external web services, analytics, personalization, GUI extensions which supports Nuno’s point on external data.
I think we skip this domain-specific abstractions more often when the customer doesn’t really “own” the Tridion template code. If the Tridion consultant knows the Tridion model and there’s no one to explain it to, there’s no need to make it simpler. Add deadlines and there’s less time to understand how you’d want to wrap code (though I’ve seen it brought up early on in projects).
On the other hand, we see this approach frequently in CD-side implementations. Devs gravitate towards a vendor-agnostic formats that hide the “Tridionness.” We’ve seen wrappers, XML content configs, and frameworks built to smooth out the difference between Tridion and the business model (CWA, DD4T, and other dynamic implementations).
CD-heavy implementations might also skip CM-side C# development all-together–not everyone has a fifth environment to play with. 😉
This sounds like DD4T v0.1 (or the .net framework Q created around 2008 to decouple Tridion dependencies into a ‘neutral’ class model).