Hi There! With new project I am getting an opportunity to work with Helix patterns, along with leading a team who is awaiting instructions and pointers from me, I am re-inventing and looking at sitecore from a totally different perspective. Since, the whole sitecore world is moving towards Helix and embracing it, I was bent to take a step forward as well. I am subtly nervous about this, but, hey, we got a a great team both internally and in community who would pitch in to help us take some decisions.
As I roll along, I plan to share what I learned and how we solved each question/concern that came up while implementing Helix for the first time ever.
Two of them so far. Below are those noted and steps I took based on recommendations of my fellow super stars. Do you agree? Do you have some totally different direction that we could lean towards. I would look forward to getting some different thoughts around this.
- Helix does not support base page template and advice to have the page templates inherit from several interface templates instead.
- Pain point – This would mean, every time there is a need for Global interface template to be added to all page templates, some one has to go to each template and add that in. Hopefully, if architecture is planned correctly, this should not happen very often, but, yeah, I might have to install powershell for sure to do bulk operations very soon. I can totally see it.
- I had no option left at this time other than manually adding couple of those sections that are Global to all templates.
- Helix proposes to use a different project per feature/module, but, I guess I agree to use grouping instead to group tightly related siblings(I think you may call it that) in to one project instead. For example, you have similar looking Hero Slider modules, but, we all know that there is not just one Hero on your website, you will have different flavors for this kind of modules. So, instead of creating one feature project for each Hero, we tend to group them in to one Feature project instead. Keeping this balanced, like not abusing it, but, at the same time judging each module case by case basis.
- In this paradigm, I feel a little confused once in a while especially when Client says any module could be used any where on the site, well technically you could use any module any where on Sitecore, assuming not too many restrictions are placed using placeholder settings, but, saying all modules are Global kind of puts the categorizing in terms of Helix in jeopardy or confused state.
- What I did to overcome this is – Think about different ways of grouping a module based on name of the module, fields/sitecore items in use for the module, where this module is likely to be used, what is the generic purpose of this module. Few such questions I answered to myself to give clarity on naming the feature projects. If the module seems to be really generic and not fitting in to any category, we would then plan to drop it under Modules project. Again, being careful to not abuse this.
Will definitely bump in to more. Also, cool find, I see that the unit testing feedback provided on Helix/Habitat is pretty cool if you wanna check out