I wish to build a project which allows authors to place components in a container, such that they have a great deal of control over how they will be laid out on the page’s bootstrap container grid and how they will be treated in a responsive manner. For example, the author should be able to specify component size (3, 4, 6, or 12) for different devices (xs, sm, md, lg), as well as control how different items will be pushed/pulled as the page resizes. It would also be helpful if I could nest containers inside other containers, though I’m not sure if Hippo supports this.
A few options which I have considered:
Supply component template variants for various different bootstrap layout configurations. This provides some flexibility, but is restricted to the variants which are supplied. It also involves creating several variants for every component, which is not optimal.
Add fields to the component dialogs which allow authors to select from a list of layout configurations or specify their own. This offers more flexibility, but involves more component dialog management. Can component dialogs inherit configuration from a parent component (ie, could I create an abstract responsive component which all components inherited their layout-related dialog fields from)?
Require that all layout be managed by the front end team who supplies their designs and stylesheets.
I’d appreciate any suggestions or ideas you could share about how this can be tackled.
We have implemented the same feature as you required, that is building a responsive dynamic grid page where user can pick the block ( component ) he want to display and positioned it in the grid container.
Here are how we implemented it
Create a document named GridContainer.
Create a compound named GridRow, this compound will be added to GridContainer document.
Within each GridRow user can pick one or many GridComponent and choose its expected width, columns in the row and in each columns size of the screen. For us, we have 4 columns size 1, 2, 3, 4 related to mobile, tablet, laptop and big screen.
With in each GridComponent, we provide enough information how to display the component in the grid cell. Later in the UI file we can use hst:include tag to render the component into the grid cell.
Thanks for the information ThoLe, this was very helpful. We evaluated the solution and prototyped something similar to what you described, but it didn’t quite satisfy what we were looking for.
Instead, we found this thread which lead us to this container documentation. We discovered that we could set our containers to xtype hst.nomarkup, which omitted the additional divs that hst.vbox would add. This allowed us to create a Grid Layout composite for specifying a grid layout in our components’ documents, which we then use as the class of the outermost div of our component templates. This approach seems promising so far.
I’m not certain how we will handle rows. I’m not sure if it will work, but one idea is to have a simple New Row component which would simply add </div><div class="row"> to break the current row (which would wrap the hst.include of the container) into two or more.
Thanks again for your input!
EDIT: I tried creating a New Row component as described, with a template consisting of </div><div class="row">. Unfortunately, that seemed to break the authoring overlays in the channel manager. And it does violate the requirements outlined for components in an hst.nomarkup container, as described here. If there is a way to mark the component as non-editable, perhaps it won’t break editing because the channel manager won’t attempt to add an overlay for that component. Although, I suppose that would also make it impossible to remove these New Row components from the channel manager. Hmm…
