(This post assumes that Project Feather layout files supersedes the PowerTools approach for root templates—if this assumption is incorrect, perhaps you could direct me to the best practice?)
In an effort to keep my HTML as DRY as possible, I have been attempting to use nested razor layout files with Project Feather layouts/templates. My goal is to establish a single root template for all pages on my site.
In a regular MVC project, nested layouts can easily be achieved using @RenderBody. While I met with some initial success using this approach (the page renders fine, assuming I don't use any section helpers), attempting to use @Html.Section helper extension methods fail at page-load time with:
A section with name "head" could not be found.
Parameter name: head
Where I registered a section called "head" in my root template.
Are nested layouts using @RenderBody fully supported by Project Feather? If so, what am I doing wrong? If not, is there an appropriate alternative to allow for a root template that supports registering @Html.Sections?
Here is the code I have so far (bare minimum to encounter this issue):
Root template: ~/Mvc/Views/Shared/Root.cshtml
Child template: ~/Mvc/Views/Layouts/Standard.cshtml
Layout = "~/Mvc/Views/Shared/Root.cshtml";
Thanks for your time!
Thanks for your response!
I came to a similar conclusion after looking through the Feather code. It's unfortunate the custom Section helpers don't work alongside the native RenderBody call. Being able to add section content (from a child template) to a parent layout is kind of the point of "sections" as a concept. In this case, adding jQuery was just an example, but was only meant to be included if that particular child template was being used. Placing it in the parent layout defeats the very point of the requirement.
Also, with the addition of the sfPublicWrapper markup, it's a little disappointing to find that Sitefinity isn't quite as HTML agnostic as I had hoped. One of the main advantages of ASP.NET MVC (compared to say Web Forms) is the control the developer is given with respect to HTML output. Convention over configuration is great for file and class names etc., but doesn't work so well for rendered content (be it HTML, CSS or otherwise). Porting sites to Sitefinity now requires a little more time and tweaking than should be necessary—and I no longer have that great feeling knowing I have full control over my HTML. Oh well, not a deal breaker, at this point.
Thanks again for your feedback, it's much appreciated.
Is this still the case?
In our scenario we have a master template which defines our basic layout that's used for the majority of the site. We also have subsections of the site with their own sub-navigations, so we decided to create child templates (using the Sitefinity template designer) which inherit the master template. These child templates simply add navigation for the subsection.
What we're finding now is that when we call @Html.Script(..., "bottom") from any widget used inside these child layouts, the script is appearing in the head instead of the bottom.