As a first hands-on experience with SXA at NishTech, we chose to implement one of the Development Tests we have in-house. It's not an exercise specific to SXA nor Sitecore, but it can certainly be implemented with these tools.
The use case we are going to implement has some specific functional and non-functional requirements, but it is overall quite simple, with only two pages and four dynamic (editable) components.
But what appeared to be a straight-forward task at first glance, proved to be an interesting SXA challenge.
From the test, this is how non-functional requirements are specified:
The last two bullets give the excuse we needed to risk this experiment with Sitecore, and if it can be done with Sitecore it should be doable with SXA, right. Why not?
It's the very first bullet, however, that reflects the biggest challenge of using SXA for this mission: The HTML layout, a Bootstrap-compatible template, is already implemented. Having it done means we should respect its CSS, JS, and markups for the pages to render properly.
But if you look to the "normal" implementation flow of SXA, here is what you will see:
The sequence is:
You build Wireframes (2) using SXA OOTB components, creating pages with proper content, putting texts and images in place (3). Until now it is only wireframes, we are not taking care of the final layout. Then you will build the final themes (4), using SXA's Creative Exchange to export and import themes into zip files. Creative agencies with no required Sitecore skills, can unzip that file to work out with the CSS and JS files, then zip it up again and send it back.
So this sequence is good:
But this one is not:
There are also some limitations to what the agency can do with the markups (source: SXA official documentation)
Front-ends cannot (will not be imported back to the system and can damage your site):
“You’re not supposed to do this way”
Out of the box, you simply can't make SXA adapt to a certain predefined markup.
For the lack of a better wording, apparently, our First Non-functional Requirement is not supported by SXA's "happy implementation path", using Creative Exchange (or not). Out of the box, you simply can't make SXA adapt to a certain predefined markup. Instead, you should start with the markup that SXA gives, and make it look how it should by modifying CSS files.
At this point, given all the constraints and limitations described above, we seriously considered aborting our experiment. But we decided to continue...
The next parts of this series of articles will cover the functional requirements, describing the lines of thought that guided our decisions and specifying the steps followed during the execution. Being an experiment, not all architectural decisions are appropriate for real-life scenarios, and some of them can be taken as wrong decisions. Exactly because of the experimental characteristics of this exercise, we are not only concerned to be very descriptive to make things understandable, but equally interested in your inputs.
In terms of files, it is also not a big deal. Everything boils down to:
And of course, some beautiful pictures from Groom & Bride
A look at the page skeleton brings up some of the challenges that we are going to face. We have Page <head> at the top, some scripts at the bottom. We have a couple opening DIV's and their custom IDs, which is something that SXA does not support OOTB. Inside those DIVs we have everything else that makes the website looks like it should. Respecting these IDs, wrapper DIVs and markups is critical for the pages to render correctly.
Here we have an expanded look at the markup of the Hero Banner component. Again, we have some custom attributes at some DIVs, classes, hardcoded styles, an empty DIV, as well as a very peculiar arrange of internal DIVs. Unfortunately, none of the Components at the SXA Toolbar supports that kind of things, even when you play with Rendering Variants. Cases like that will require either to customize existent SXA Components or create totally new ones.
In the next article, we are going to implement our Milestone 1, including the whole setup and basic structure, we are going to implement the Homepage. For now, it will be composed by static HTML blocks, not very good in terms of Content Edition Experience, but functional.