4

I am working on Helix based project. This one is multi-site project. The html for same features different so I've decided to move views to project layer to support html difference.

Is it allowed to move views to project layer?

What the consequences might be?

Improve this question

2 Answers 2

Reset to default
2

Well there's probably a few approaches you could take with this. Ideally with a Helix pattern, you would build for example a blog that would exist within a feature module. If there's a project specific variation, moving the views to the project could present some challenges depending on how the renderings are defined. If you created View Renderings to represent your views, you would have multiple listings in the layout section of the same rendering. Ex. Blog Listing - Site A & Blog Listing - Site B. I would avoid that. Alternatively if you were using a controller rendering, yes you could only have one rendering definition, but then your controller would need to render the correct view depending on the site. So you would need to make the Controller's more intelligent.

You could also go a different approach, if you wanted to keep everything in one layer. You could build another feature/foundation element that could handle rendering variations. It would be like taking some of the implementation ideas from SxA, where they use rendering variants that allows you to have one rendering that for example is a blog listing display, but with the concept of a rendering variation, you could vary the rendering html (and fields used) for your rendering depending on the site it's on. And this would allow you to eliminate the need for multiple views per site.

Improve this answer
2
  • Thanks! Can you please describe more the last approach? How it can be done?
    – Vlad
    Nov 22, 2016 at 21:13
  • Yeah that's a good point. It's a limitation and definitely presents a challenge, especially if your views are quite drastically different between sites. It's probably something you should consider trying to avoid. As for Option 2, I will try to provide a little more detail by updating my answer tomorrow. If you pull down a copy of SxA, you can get a general sense of how it uses "Rendering Variants" to allow for alterations of the View per page the rendering appears on. That same concept could be applied to what you'd like to achieve.
    – Dylan Young
    Nov 23, 2016 at 2:51
2

One approach you could take, if you are using MVC, is an approach we used to take in multisite a few years ago. You can create a new View Engine for MVC and make it check for Project sites first.

~/Views/Project/CompanyABC/{1}/{0}.cshtml

If it doesn't find it, then just resort back to the default feature location.

I don't have access to that code anymore, but its very similar to these examples. Make sure you do not use Application_Start as it is private in Sitecore 8.2. Use the Initialization pipeline instead.

http://www.martywoods.nl/organize-mvc-views-like-sitecore-renderings/

http://beendaved.blogspot.com/2015/03/organizing-views-in-sitecore.html

Improve this answer
6
  • what should be used instead of {0} and {1}?
    – Vlad
    Nov 23, 2016 at 19:13
  • {0} and {1} is still used. {0} is the controller name and {1} is the Action. An example is /Views/Project/CompanyABC/Navigation/MainMenu.cshtml. Navigation is the controller. MainMenu is the action.
    – Chris Auer
    Nov 23, 2016 at 20:02
  • In this case where I should store controllers? project layer or feature layer?
    – Vlad
    Nov 24, 2016 at 9:33
  • Controllers stay in the feature. The way I understood it, your views were different. But the data was the same. If your data is different per project, the controllers are in project folder. And if the controllers are in the project folder, then really each one is a one off and non-reusable.
    – Chris Auer
    Nov 24, 2016 at 12:55
  • I agree with @dnstommy the views are the challenge because their presentation may change, but the overall business logic is different, so that should stay in the Feature layer. However everything comes down to what is different. If you had a blog, but one blog on Site A acts completely different than Site B, beyond just adding settings etc. Then it could make sense to completely separate them, and you could end up with two features. If you can achieve the same code base, just with rendering parameters etc. then leave one in feature, and any variations could occur in the project views.
    – Dylan Young
    Nov 24, 2016 at 13:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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