I will preface that this may not be the best use of a branch template, but it seems ok on paper, with a few drawbacks.
Sitecore 8, we have a Template called "Program." Program needs the ability to either be a two-column (9-3 grid) or a full (12-col grid). These basically represent a full version and a version with a right rail.
We want the content editors to be able to decide when they create the page whether they want a "program" or "program with right rail." To set this up, we created two branch templates. One that looks like this:
Layout: Base Layout
Renderings: Full (sublayout), Program Detail (rendering, dropped onto Full's placeholder)
And one that looks like this:
Layout: Base Layout
Renderings: Two-Column (sublayout), Program Detail (rendering, dropped onto Two-Column's placeholder)
Placeholder settings: Right Rail (allows right rail components to be added)
Then when the user right clicks on the "programs" item in the tree, they can pick one of the two options above and it creates the program item with the appropriate presentation details (again, either a full width or a two-col).
This all works, but the problem is if I ever have to change something on one of the branch templates, that change is not propagated to any items that were created based off of that branch like standard values works. There's no "branch delta" that I'm aware of.
Is there a better way to handle this? In my head, it essentially sounds like I need standard values for a branch template, but I don't think that exists.
Another thought I had was to create an "Program Master" template and then create two templates that inherit from it, Program and Program with Rail. That way they would share the same data but would have different standard values and allow me to set different presentation details for it. This feels a little dirty since I'd basically be creating a template to handle look and feel. I hope I'm explaining this correctly, but if not I'll update with more info if I'm being unclear.
Unfortunately if you want to take advantage of "layout deltas," out of the box you would need to have a separate template with its own standard values, as far as I'm aware.
You could probably do something fancy with the renderLayout pipeline if you wanted -- e.g. Sitecore Zen Garden introduces the concept of "Designs" which are used to define default layout, and allow you to separate layout from Standard Values. But you're going off the reservation at that point.
Related
I have custom model with different data types like string (file path) or double which should be edited using combobox with a few items.
It is not clear for me why delegates should be applied to views and not to models...
So, should I pass some kind of flag from my model and then use different delegates for those items according to those flags?
What is the best practice to make it?
EDIT: I'll try to clarify my question:
I have model with the map (key - value (structure that can contain different types like QVariant)) and it's necessary to set different delegates for each row of my, say, QTableView.
What is the best way to pass some "flag" for every item from my model and then handle this flag to set appropriate delegate for the given row?
EDIT2:
This model-view pair is for storage and editing software options with different types.
From the docs:
Unlike the Model-View-Controller pattern, the model/view design does not include a completely separate component for managing interaction with the user.
Delegates are supposed to tackle the "how" in "how should users interact with my data" (that's why I highlighted "interaction").
For your case, that very "double" field you provided, depending on it's interpretation, we could use a line edit (eg exact toleration), spinbox, or even some sort of color select (interpret the value as a color). Even more, one could use a line edit with some sort of color scale for the widget to make it more clear what consequence that value may have.
Correct way? They're tools, not one better than other but rather "one to tackle a specific problem". Can't tell what's the correct way from the info provided.
I suggest re-asking the question with much more info if you still have doubts.
Relatively new Sitecore dev here and I'm trying to get some clarity on simple topics, so I have a few questions.
When creating a data template: what is the difference between just filling in the values on the template, and adding standard values? Don't both become default values whenever you create an instance of that template? If I want to make sure each item of a template has a certain value, which should I use and why? When is it appropriate to just fill out the value on the template, as opposed to adding standard values?
Branch templates: I need to create a group of items whenever a single item is created, and it sounds like branch templates are perfect for this. However, I recently read that instantiated items from a branch template stop inheriting the moment they're created.
For example, I have a branch template called Store, and create an item based off of this called Walmart. I then add features to the Store by adding new items, but Walmart doesn't get those changes? If this is problematic to my situation. I really need to keep all instantiated items in line with the branch template, and give them the new features. If my understanding is correct, how can I get around this?
Thanks
Templates. For mature .NET developer it would make sense to think about templates as about C# classes - they define the data structure for the items that would be created on that particular template. Like classes in C# they may be inherited, but unlike in C# multiple inheritance is supported with them.
Official documentation on templates is quite descriptive and handy: https://sdn.sitecore.net/upload/sitecore7/70/data_definition_api_cookbook_sc70_a4.pdf
Standard Values is a kind of blueprint prototype item for your template. You create some default values that will be auto-filled as soon as you create an item of that particular template. Standard Values item is a child item of a template definition item. You may also use tokens - dynamic values like $name, $parentname, $date, $time, $now, $id and others (you may also create your own tokens). Please read more about standard values: http://goo.gl/uUZJZf
Branch templates allow you to re-produce a sub-tree on instantiation, not just one item, but also some children (and children of those children) as you specify in branch template itself. As on screenshot below, whatever is selected within red frame will be created as a result of branch template instantiation:
Also, Sitecore items can't inherit from values set in a branch template. They will always default to the values in the original template's standard values. This is a limitation of branches (as described in this SO question: http://goo.gl/PSElYy)
As far as I understood your case, you should have a branch template called Store (somewhere underneath /sitecore/templates/Branches) and within that item reproduce exact structure that will be created on when template is used to replicate into a new branch in your content. Again, you may use tokes all around branch template (at any level) - they would be replaced with actual values. Likewise, when you use your Store branch template to create Walmart, you may auto set its display name to Walmart by using $name token.
Is there a way to control the order of slides displayed to users in a carousel from the Experience Editor perspective? (or even the Content Editor)
Basically, based on the user that has been identified or not identified, I would like to display a different slide as the first slide of the carousel. All the other slides would still be present, just in a different, specified order.
Is there a way to accomplish this via rules or should I look at having to create separate datasources that have the different slide orders already specified?
TL;DR
Personalization can do three things:
vary a datasource for a rendering
vary a rendering (use another rendering basically)
hide a rendering.
I guess the question you need to answer is whether what you need can be accomplished by doing either one of these actions.
If you've used nested structures to represent your carousel (like we do in SCORE, you can see how it looks like here or here) it's not hard to show/hide certain panels based on personalization conditions and thus reorder the carousel. Depending on how exactly it looks on the published site you may only need to repoint datasources. Either way, it's personalization out of the box and your content structures working nicely together.
If you've used a (variation of a) MultiList field to represent a list of your panels with panels themselves being items somewhere in the shared content area it's not something personalization engine can change based on a condition. Changing a field value is, unfortunately, not on the menu. I am sure you can code around it thanks to Sitecore being so open and flexible but I am not sure you can make it seamless (e.g. variations preview in Page Editor).
Rendering parameters is also not something you can change but if yours are static and defined on the rendering definition item (as opposed to being supplied when component is bound to the placeholder and thus recorded inside the presentation details) you can get away with having two definition items for your carousel component (same code behind it) and picking the right one based on the personalization condition.
Hope it helps.
In Sitecore, I have a field which is re-used by several page templates. I use basepage inheritance, partly so I don't have to configure the source, help-text and so on each time it is used.
However there are times when the field has a slightly different meaning for one particular page template, and I would like to adjust the Title and help text accordingly to make it easier for the content editors.
Can anyone suggest a good way of doing this in Sitecore? Or is the solution just to make another copy of the field and edit that accordingly, especially as that's only a few seconds work.
Update: Thanks for the answers, I agree with all of them. The difference in the purpose of the fields was so subtle that I didn't think it warranted different fields, but I guess that's a kind of micro-optimisation that will just end up confusing everyone anyway, and certainly isn't worth developing a whole UI / datastore just for this purpose.
Good question, and one that most Sitecore people arrive at eventually. That fact is that the help text is part of the field item. So if you want different help text, you need a different field.
As you point out, the fields sometimes have a different meaning. This is an indicator that it should in fact be a different field.
My suspicion is that you're probably better defining the field more than once.
It may well be possible to modify how Sitecore generates the editing controls shown in Content Editor so that your field's title varies. But that implies you need to store some configuration somewhere to say "when should it change" and "what should it change to". And that's likely to take some time to set up. Plus I think that might be confusing to future developers on the project as it's unexpected behaviour for a field to change it's appearance in different places?
So I'd argue that multiple definitions of the field will be easier for other developers to understand, and probably less prone to mistakes.
If this is not a field that is different on every page, I would keep the inherited field, whether or not it is used by the current page, and create a new one to suit the changed purpose. If the field does have a different meaning on every page, then I would remove it from the base template and re-make it for each page template.
If you have this field on your base page template and it is used on most pages, you will want to ensure that you are still able to use it on the other pages that need it, even if there are one or two exceptions where it does not apply. However, if the purpose of this field changes on every page, then it is better architecture to create a separate field on each page.
It is best practice to use each field for a defined, uniform job; you should not be re-purposing fields between items, as it will lead to confusion for both developers and content editors.
Depending on how many templates you have it may be worth taking that field out of the base template and create two separate templates for these fields.
Essentially will probably have the same field name but with a different help text and title.
Then just inherit the one you want.
This way you keep it separate and this makes better sense being separated as mentioned above.
If you have loads of template already using it then maybe a quick script to swap these over before applying the new template to help change existing ones over (only if you have lots of templates using this base template already)
Hopefully I've made sense here.
As everyone has stated, you need different field for different page templates.
I would do the following, create a new template which contains your common field, and make page templates that use this field with same 'meaning' inherits the new template.
And for page templates that use this field with different meaning, add a separate field to each template.
Let's say there exists a presentational component in a project that renders an unordered list (called ListRenderer, perhaps.) We have a couple options of supplying data to any given ListRenderer on a page:
Have a TreeList (or TreeListEx) field on the content item, and have ListRenderer read from it.
Supply a DataSource (or other Parameter) to the ListRenderer via the presentation details.
I usually avoid #1 in my projects because it binds Sublayouts to templates, which gets quite messy. If you go down that path, eventually you'll have fields to support every potential sublayout in your project.
So my solutions tend toward option #2, which gets rid of that problem. It does, however, come with its own bag of questions. Where do I put these various "Lists" for a given ListRenderer to use? To maximize reuse and sharing, I usually create a components directory near the site root that contains all these types of things, if I predict the Lists will be shared. This seems less findable and harder to use for the content author, who suddenly have no idea where the source for their ListRenderer is unless they know how to crack open the presentation details (which is slightly advanced for my average user).
If I feel like Lists won't be shared, and are very specific to the page, I'll put them directly underneath the item in question. This has a tendency to muddle up the content tree, though, and any dynamically generated navigation sublayout then has to check for whether or not an item is an actual page before it generates the link to it. The more I work in Sitecore, the less I use this approach, but it seems easier for the content author. There is much easier access to information when you use this approach.
Is there any industry-accepted way of approaching this problem? It happens in projects all the time, and in my head I struggle to balance technical and content authorship concerns in situations like these.
Great question. I've used all the techniques you mentioned, depending on the audience and specifics of the project. The problem is that, as with all things Sitecore, they are all valid ways of achieving the same goal and you will struggle to find one answer that will work in every situation.
I almost always use #2 as well, but some content author retraining maybe necessary and make sure you add in restrictions to what the content author is able to select as a target. I have (within the same project) structured the items near the root (in a shared content folder) and under the item in question, depending on what I felt would provide the best context.
Also, if other child pages would exist below the item as well as the list items, then I would put the list items in a separate folder (with a common "list items" icon") and re-order it to be the first item for separation and clarity.
If you want to use any kind of personalization and DMS then you will need the ability to switch out the datasource anyway so you shouldn't hard code locations.
You might also (if you have not already) want to consider using:
Convert Data Source Paths to IDs Using the Sitecore ASP.NET CMS
- Useful if you need to restructure your content at a later date
Queryable Datasource Locations
- Useful for multi-site situations when you need to make clones, or setting as the default datasource value in Standard Values when the lists are directly below the item but gives you the flexibility to change it.
I prefer using querable datasources personally, I find the xpath syntax more logical.
As Mark has commented, there is no real industry standard.
I feel like this is something that needs improvement.
Especially when you are using the DataSource option, things become less transparent to the editors and as the size of the site grows, so does the complexity.
All I can tell you is how I would do it, which is most likely much like how you are doing it.
1) For overview pages like news, events and faq items, I will put the items underneath the overview item and use the NewsMover shared source module to auto-create a hierarchy.
2) I will create a Global site that contains items that are shared across sites or pages. DataSource items for components will be put in here.
3) For components that are present on the standard values, I will add a list field to the template (for example, when you display related items on a content page)
Most often it's a logical choice and sometimes it's just a matter of taste.
I'd like to add that I've written a blog post on how to have datasource items created automatically for components that are set on standard values. That might help you if you are using those.
Edit:
"I usually avoid #1 in my projects because it binds Sublayouts to templates, which gets quite messy. If you go down that path, eventually you'll have fields to support every potential sublayout in your project."
Today I've blogged about a method of hiding fields and sections in the content editor if there is no sublayout set on the item that requires those fields, which helps to prevent the mess of having a lot of unused fields on your items.