That might seem like a controversial title for a Sitecore blog. After all, datasources are accepted as being essential for building successful Sitecore sites. Don't worry, I'm a strong advocate of using datasources. If they aren't central to your approach, then you probably haven't grasped just how powerful Sitecore can be.
But nothing's perfect, and I hope this post can start a discussion concerning what I perceive to be a missing piece in Sitecore's datasourcing mechanism. I'd really like as many people as possible to comment below. Whether you agree, disagree, or even if you think I'm inventing a problem that just isn't there.
Breaking this down:
1. They're just labels. Who would want to personalize them?
I can understand this response, but to me it seems a little lazy. I don't think it's our place as developers to predetermine what content a user should or shouldn't test or personalize. It simply ignores the problem and forces restrictions on the user.
2. Add label fields to the datasource item's template.
Alright, that fixes the problem. Now everything in the component, including the labels, can be populated from a single datasource item. But it also completely destroys any separation of content from presentation. If we have 10 components that can all be datasourced to a product item, then all the various labels need to be stored as part of the product. Also, if I want to personalize a label, then I have to create a duplicate product item. That just seems wrong to me.
3. Use an "Adaptor" Datasource.
This involves creating a new template which can act as an intermediate datasource for a component. The datasource has one field that references a product item and another that references a "labels" item. This effectively maintains the separation of presentation and content, but also adds a layer of indirection that I think users would find confusing.
(I should point out that I don't have a workable solution that is better than any of the above, but neither do I find any of them acceptable).
It's seems logical to me that each component needs a secondary "labels datasource". It could be personalized/tested just like the standard datasource, but would be completely independent of it. I think this would make sense to users, and also maintain presentation/content separation. As far as I can tell, this isn't currently possible. The personalization logic is too entangled with the existing implementation, But maybe in future...
I don't consider this problem to be a failing on Sitecore's part. The product has grown organically over time and this issue is something that arose as a by-product of other excellent features. Nevertheless, it would be great if a solution could arise from discussion within the community.
But nothing's perfect, and I hope this post can start a discussion concerning what I perceive to be a missing piece in Sitecore's datasourcing mechanism. I'd really like as many people as possible to comment below. Whether you agree, disagree, or even if you think I'm inventing a problem that just isn't there.
The Scenario
Take a look at the example components below. They're both datasourced to the same product item. The content obtained from the datasource is highlighted in green. There's also additional content that's unique to the components themselves (highlighted in blue). These are labels that would commonly be stored in a dictionary and have nothing to do with the datasource item.
Breaking this down:
- The properties of the product item are: Professional Sitecore Development, John West,
Wrox; 1 edition, English, the image, the star rating - The labels associated of component 1 are: By, Buy Now!
- The labels associated of component 2 are: Title, Author, Publisher, Language, Add To Cart
So where's the problem?
We know that applying datasources to our components is a good thing. The main reason for doing so is to make personalisation and testing possible. But how do we personalize or test the labels? There's only one datasource item, and they're not part of it.Common Responses
I've discussed this topic with several people. Each of them acknowledged the issue, and each of them had a different approach to dealing with it.1. They're just labels. Who would want to personalize them?
I can understand this response, but to me it seems a little lazy. I don't think it's our place as developers to predetermine what content a user should or shouldn't test or personalize. It simply ignores the problem and forces restrictions on the user.
2. Add label fields to the datasource item's template.
Alright, that fixes the problem. Now everything in the component, including the labels, can be populated from a single datasource item. But it also completely destroys any separation of content from presentation. If we have 10 components that can all be datasourced to a product item, then all the various labels need to be stored as part of the product. Also, if I want to personalize a label, then I have to create a duplicate product item. That just seems wrong to me.
3. Use an "Adaptor" Datasource.
This involves creating a new template which can act as an intermediate datasource for a component. The datasource has one field that references a product item and another that references a "labels" item. This effectively maintains the separation of presentation and content, but also adds a layer of indirection that I think users would find confusing.
(I should point out that I don't have a workable solution that is better than any of the above, but neither do I find any of them acceptable).
A Possible Solution?
As mentioned at the beginning of the post, I'd love people to weigh in on this topic, but I have a potential solution that I'd like to see built in to future Sitecore releases.It's seems logical to me that each component needs a secondary "labels datasource". It could be personalized/tested just like the standard datasource, but would be completely independent of it. I think this would make sense to users, and also maintain presentation/content separation. As far as I can tell, this isn't currently possible. The personalization logic is too entangled with the existing implementation, But maybe in future...
Summary
The main questions raised in this post are:- Should we sacrifice the separation of presentation and content in order to achieve maximum flexibility?
- Is it acceptable that some content should never be testable/personalizable?
- Should we even think of labels as "content"?
- How do we effectively decouple presentation and content without making life difficult for users?
I don't consider this problem to be a failing on Sitecore's part. The product has grown organically over time and this issue is something that arose as a by-product of other excellent features. Nevertheless, it would be great if a solution could arise from discussion within the community.
Comments
Post a Comment