The Nuptial SXA Experiment - Part 4 (Final Thoughts)
Experiment Artifacts
Some artifacts were produced during the execution of this experiment:
- A Visual Studio Solution, available at https://bitbucket.org/nishtechinc/nuptialsxa/src/master/
* Even though Helix standards are being respected at the database level, the solution has only one Website project, single Core and Master TDS projects.
“You’re not supposed to do this way”
In an enterprise application, you should follow Helix principles and organize your code into multiple projects.
- This series of articles
- Presentations made at Sitecore Usergroups: SUG-JO, SUG-BR, and Queen City.
Conclusions
This was a very interesting experiment, a great opportunity to invest time using SXA to implement strictly defined requirements (functional and non-functional). Even though some customization were required and some caveats are described during this journey, the whole experiment confirms that SXA is amazingly flexible!
The extensible Grid System and the existing Bootstrap Grid definitions made the implementation easier, enabling us to start from the existing base, customize the Grid Layout and continue from there. This is done by duplicating some definition items, which is a common practice in Sitecore. On the other hand, this increases duplicity and potential upgrade issues, so take special care of these cases, have them tracked down and followed closely.
One of the biggest miss was the Site-based Theming to allow native SXA components to use a different View per website. For our delight, the next SXA version (1.8) will support such a mechanism. Even without that, the current SXA version still gets credits for easing the customization of native components.
Having a pre-existent markup, generated and approved outside of SXA, later integrated with the accelerator is possible, but it can be tricky. For instance, we had a few JS/CSS conflicts between our layout and SXA things and forced to adjust our theme to fix them.
At some points of this journey, we were doing pretty much traditional Sitecore development. Which is good, because existing Sitecore developers can be easily ramped-up into SXA. But in the scenario described here, how much of the accelerator was used? Surely a lot for the foundations, multi-tenant/multi-site, page composing, and others. But given the number of custom components we had to build (and the more you have), the efforts for building SXA vs non-SXA can get even.
What you think?
We are very interested to know your thoughts about this experiment. Anything you would do differently? Do you ever faced similar challenges, and how you solved them?
Let us know your thought!