I'm fairly new to Umbraco, but after building and maintaining several websites on the platform I'm still struggling to figure out a best practice naming convention for properties and property aliases. I'm not sure if I'm being overly picky or if I'm architecting my document types poorly. The documentation and examples I've been able to find don't shed much light on the issue, as they typically involve only a small number of properties.
Consider the attached wireframe of a fairly typical page design:
To realise this in Umbraco I might block out a "Home" document type as follows:
Banner: Heading, Summary, Link, Call to action, Image
Products: Heading, Summary, Image, Link, Call to action
About: Heading, Summary, Link, Call to action
News: Heading, Summary, Featured articles, Link, Call to action
This wouldn't work as the resulting property aliases would conflict with one another. To work around this, I might prefix each property name with the name of its tab, as follows:
About: About heading, About summary, About link, About call to action
News: News heading, News summary, News featured articles, News link, News call to action
I might even go a step further and split the property name from its alias, so that content editors have a smaller field label to contend with, for example "Call to action" instead of "Products call to action", and rely on the tab itself to provide context.
Is this a sensible way of doing things?
Is always prefixing property aliases to avoid possible conflicts worth it?
What architecture or naming techniques can be employed to handle situations like the above?
What resources exist for examining different methods of building larger Umbraco websites?
I usually try to avoid having so many properties on the same doctype, mostly because of the issue you are mentioning, having to prefix the propertynames feels a bit dirty.
When I see your example site, i don't necessary see one page with a bunch of properties. I see one page with a bunch of blocks/segment. I would have build a "Banner"-block, a "Product"-block, "About"-block (or probably something more generic), "News Listing"-block etc. Then place them all in a Nested Content property and assign to the HomePage.
Then all your block can have a "Heading", "Summary", "Link" etc without the prefixes.
This way:
Blocks are not tied to a specific doctype but can be used all over the website. (If you allow them.)
You avoid the property naming collisions.
You give your editors the freedom of moving blocks around (re-order nested content items).
You can render each block with its own partialview, (and if you want, its own controller). This gives you a lot more smaller views with just a few lines of code instead of one huge "HomePage.cshtml"-template with hundreds of lines of code.
One could argue that "But what if I just want to use the News Listing on the startpage?" I would still create is as its own block, because 1, you never know if you might need to use that block on another page in the future and 2, extracing functionallity to smaller bits it never a bad thing.
I know I didn't answer all your questions, I just thought I share my thoughts on this topic which I think is and interesting topic and I'm interested to see how other's feels.
Property naming conventions
I'm fairly new to Umbraco, but after building and maintaining several websites on the platform I'm still struggling to figure out a best practice naming convention for properties and property aliases. I'm not sure if I'm being overly picky or if I'm architecting my document types poorly. The documentation and examples I've been able to find don't shed much light on the issue, as they typically involve only a small number of properties.
Consider the attached wireframe of a fairly typical page design:
To realise this in Umbraco I might block out a "Home" document type as follows:
This wouldn't work as the resulting property aliases would conflict with one another. To work around this, I might prefix each property name with the name of its tab, as follows:
I might even go a step further and split the property name from its alias, so that content editors have a smaller field label to contend with, for example "Call to action" instead of "Products call to action", and rely on the tab itself to provide context.
Hi Stephen.
I usually try to avoid having so many properties on the same doctype, mostly because of the issue you are mentioning, having to prefix the propertynames feels a bit dirty.
When I see your example site, i don't necessary see one page with a bunch of properties. I see one page with a bunch of blocks/segment. I would have build a "Banner"-block, a "Product"-block, "About"-block (or probably something more generic), "News Listing"-block etc. Then place them all in a Nested Content property and assign to the HomePage.
Then all your block can have a "Heading", "Summary", "Link" etc without the prefixes.
This way:
One could argue that "But what if I just want to use the News Listing on the startpage?" I would still create is as its own block, because 1, you never know if you might need to use that block on another page in the future and 2, extracing functionallity to smaller bits it never a bad thing.
I know I didn't answer all your questions, I just thought I share my thoughts on this topic which I think is and interesting topic and I'm interested to see how other's feels.
Have a great day Stephen! Take care!
Hi Dennis,
Great idea - I like how this pattern simplifies the individual document types and the flexibility provided to content editors.
Would you use this pattern for all pages on a site? Do you think it would get repetitive for commonly created pages like blog posts?
is working on a reply...