Is there really any benefit of having header and footer assembled through dynamic binding (placeholder) in comparison to static binding. Sitecore habitat project based on helix uses a lot of common components to assemble header and footer which appears to make the template presentation very bulky. The same can be done easily by static binding which will make it easier for content editors to create pages if required. I would prefer to use static binding for such components unless there is really any benefit.

  • 1
    Personalization? MV testing? it really depends on your client needs and what do you have in header and footer – Marek Musielak Dec 28 '17 at 13:58
  • The pros and cons have been articulated, so won’t cover that ground. I suggest doing 2 layouts, one statically bound for the majority of cases, one with dynamic bindings preset in Std Values for those edge cases where someone wants to change a menu. I would argue that 99.9% of the time the “edge case” is really a mistake, but it’s not impossible that a site logo really does need A/B testing I suppose. Might mean a bit of dev time if there’s a structural change later as you need to reconcile the layouts, but Agile dev says “don’t build features until you need them”. – Richard Hauer Dec 29 '17 at 22:01

This is more of an opinion based question. But I will list the positives and negatives below. A lot of these depend on your preference. I have personally gone with both approaches, so I know that most

Positive/Negative of Static Bindings:

+ Less clutter in your Presentation Details.

+ Less work maintaining your Presentation Details.

- Less control: You would need to define variations to your layouts that don't include the statically binded renderings.

- Less flexibility: Similar to the last point, but with dynamic renderings, you can change the type of control used for example in your header, on specific pages.

- Difficult to pass data to the renderings, you can specific setting items that your renderings pull in, but things are more static in nature.

- You cannot personalize your statically binded renderings.

- You cannot A/B test your statically binded renderings.

- Challenges customizing the statically binded renderings in the Experience Editor. You would need to use Edit Frame functionality, and a lot of customization to the Experience Editor to make these controls easier to customize.

Obviously, if you use dynamic bindings instead, the reverse can be said from the above positives and negatives. The biggest positive to using dynamic bindings, which Marek mentioned as a comment, is the ability to personalize, use A/B testing and much more.

Also one last point to make, since you mentioned Habitat. It's important to keep in mind that Habitat is an example of using Helix. You shouldn't use it to build your site, and you should keep in mind that you can make your own choices that are different from Habitat. Using Static vs Dynamic is really up to you in terms of what works best with your scenario.

  • Thanks Dylan, Can i assume that if i do not have any personalisation requirement in header and footer I can bind them statically? Though i have personalisation requirement on the pages. – rdhaundiyal Dec 29 '17 at 4:55
  • Like I said, this really depends on your requirements. If you use composite renderings and inheritance chaining, than using the dynamic approach doesn't have as many negatives, but there is still not a reason why you can't use a static approach either, just make sure you configure them to have html caching as well. – Dylan Young Dec 29 '17 at 14:47

The real benefit is to allow your editors to change the header to meet their needs without needing a specific template. Example is a landing page for a campaign that requires a smaller header/menu. The editor could change out the header with a new header for that page specifically without requiring development to create a template for this single use.

You want to have x number of page types (i.e. news, content, home, etc...) and stay away from Landing Alternate 1, Landing Alternate 2 where just the header, footer or page shape is the difference. It really is up to the client's needs, but if you are personalizing your site, then having everything component based is a must.

You can make it easier on your editors by having the built header and footer in the standard values for your site pages. I create a base page template and put the header and footer in that, then I make my site page templates inherit from my base page to get the header and footer.

  • 5
    You should be aware that inheritance of Standard Values breaks down as soon as a child template makes any changes, i.e. it breaks the the inheritance chain: cognifide.com/our-blogs/sitecore/… – jammykam Dec 28 '17 at 15:50
  • That is the frustrating part of inheritance. Although with 8, I believe you only break inheritance now when you modify the placeholders that your inherited presentation details use. So if you tough the header, the header is now forever broken. But if I add a 4-8 grid to the page, the header is still inherited. – Chris Auer Dec 28 '17 at 16:43
  • 3
    Rather than use inheritance, use composite components - marketplace.sitecore.net/en/Modules/C/Composite_components.aspx they are awesome. – Richard Seal Dec 28 '17 at 18:35
  • 1
    No - but it makes it a whole lot easier than adding all the elements and updating them in 20 places when inheritance breaks. And you keep testing, personalization etc.. – Richard Seal Dec 28 '17 at 20:40
  • 1
    Thanks Chris, As mentioned in other comments I have also faced issue with inheritance of presentations and prefer to have presentation on individual templates standard value which mean if i have 10 unique data templates for pages i will have to repeatedly adding header footer to those 10 – rdhaundiyal Dec 29 '17 at 4:53

To answer your question directly:

Is there really any benefit of having header and footer assembled through dynamic binding (placeholder) in comparison to static binding

Yes. Flexibility for your content editors to modify the header and footer and enable personalization and easy enhancement without requiring a new release.

Sitecore habitat project based on helix uses a lot of common components to assemble header and footer which appears to make the template presentation very bulky.

To this I would say that Habitat is an example solution and not something which should necessarily be copied or adapted to your needs. You are absolutely right that Habitat has pretty complicated presentation details and in practice, this would be pretty hard work to maintain.

The same can be done easily by static binding which will make it easier for content editors to create pages if required. I would prefer to use static binding for such components unless there is really any benefit.

True. You can indeed use static binding to solve the template standard values mess which can occur. This reduces the flexibility for editors to modify this structure themselves.

Other Options

I would suggest you investigate other possibilities here. One option is Composite Components where you can build experience editor friendly components build from several different renderings which can then be re-used on all pages of your site. I have created a proof of concept Helix solution which uses this module and it is described in more detail here.

There are other approaches such as Brain Jocks SCORE which might be an option.

If your project has the necessary budget, then you should consider the Sitecore Experience Accelerator (usually referred to as SXA) which has partial designs and page designs to address this problem (it also has many many other features worth checking out too).

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.