I'm in the midst of a project to translate Archetype-driven pages across to use the Grid and am interested in how others are using it.
My current approach is something like this:
One layout, which allows all row configurations
A set of row configurations:
full-width
sidebar
two column
three column
four column
A collection of custom editors:
button set
article list
banner image
and so on
For the custom editors, a lot only have config, not user-entered values (article list, for example, requires a filter term, list type (blog or news) and an optional header, which are set in a config overlay). I've had a bit of a fiddle with the package manifest for grid editors, and am displaying a settings icon in the editor header, clicking on which opens an overlay.
So that means my approach is single layout, then user adds rows to suit the components they want to display. They then add content (via editors) to each cell in the row.
Something about that just doesn't feel quite as elegant as it could...
How are others using the grid for complex property editors?
I started out doing custom grid editors my self when I first started the grid. But because that took a lot of time. I switched to Leblender.
Now I mostly used doctype grid editor.
Only thing that is very hard is getting the preview right. Most of the time I just disabled or put an image in there with a mention that it is just an example of how it can look.
We started out adding settings to grid editors by adding a "parameter-bar" in the manner of the RTE, but then discovered the somewhat hidden editor.config.settings option. I guess that's what you found by fiddling with the package manifest? :)
You can do a lot of cool things with that. Even populate them dynamically like I do here and here
With regards to building the grid, I had a "pre-populating" extension that were basically superseded by content templates.
There are still some ways to go with making the grid super user friendly, but those two tricks combined makes it a bit less cumbersome.
For one, I'm hoping for /pondering prs with more extension points so it's easier to add functionality without "hacking the core".
Like Dave said, started off with custom grid-editors, now it's DocTypeGridEditor for anything complex (within the Grid). (Which is why we originally developed it.)
However, we're using the Grid less on our new client projects, using StackedContent instead. The decision always comes down to whether the website content is "multi-column" or not.
We're finding that more modern "responsive" design is gearing towards single column stacked blocks.
I'm curious how you achieved this with Archetype? Which makes me think that StackedContent may good fit/replacement for you.
Just installed DTGE locally, awesome package. Definitely agree that more sites are tending back to a single drop of content rather than sidebars etc. I think I can get the result I want through a combo of DTGE and some custom editors and macros. Custom editors quickly become tedious and time-intensive though. We haven't use macros widely in the past, but the UX in the grid is pretty slick.
With Archetype, we've got a single 'master' archetype with 18 different fieldset options - different lists, sliders, banners, maps, all sorts. Those are typically rendered as a full-width row, but some fieldsets (news list, for example) have a property to set it as a sidebar. Obvious benefit with custom grid editors is combining some of that 18-strong set (ie we have a slider, lightbox and cards fieldset, which stores the same data for each but uses a different view - it can be a single editor, with the option to choose the render type).
There's then a bit of branching/looping code in the template to start rendering the fieldsets, and when it hits something set as a sidebar, it spits out the appropriate markup to create a sidebar element.
It works ok, but like you said, there's definitely a trend towards single columns again (happily, in my opinion), and that's the direction I want to move in, but I think we'll still need the option of sidebar content (site is really information dense). Better to have the option and not use it...
Like others, I also use DTGE - Although rather than just having one DTGE configuration, I use multiple, usually it's a one-to-one setup, (ie separate config for each doctype)
FYI - DTGE wrapping nested content work well in the grid. Nested content wrapping a grid which contains a DTGE does not work.
That's what I've started looking at today - NC doctypes in DGTEs, 1-to-1.
So for example, a slider - it's a DGTE instance, with one allowed doctype, being 'slider', where that type has a few generic properties then a nested content data type, where the available doctype defines the slide object.
Works beautifully with a surface controller (inheriting DocTypeGridEditorSurfaceController) as everything is simply IPublishedContent (or properties on), with which I can build a custom model to pipe back to my views.
All I've had to write is standard MVC stuff, no custom editors to be seen. Lovely.
How are you using the Grid?
I'm in the midst of a project to translate Archetype-driven pages across to use the Grid and am interested in how others are using it.
My current approach is something like this:
One layout, which allows all row configurations A set of row configurations:
A collection of custom editors:
For the custom editors, a lot only have config, not user-entered values (article list, for example, requires a filter term, list type (blog or news) and an optional header, which are set in a config overlay). I've had a bit of a fiddle with the package manifest for grid editors, and am displaying a settings icon in the editor header, clicking on which opens an overlay.
So that means my approach is single layout, then user adds rows to suit the components they want to display. They then add content (via editors) to each cell in the row.
Something about that just doesn't feel quite as elegant as it could...
How are others using the grid for complex property editors?
Hi Nathan,
I started out doing custom grid editors my self when I first started the grid. But because that took a lot of time. I switched to Leblender.
Now I mostly used doctype grid editor.
Only thing that is very hard is getting the preview right. Most of the time I just disabled or put an image in there with a mention that it is just an example of how it can look.
Dave
We started out adding settings to grid editors by adding a "parameter-bar" in the manner of the RTE, but then discovered the somewhat hidden editor.config.settings option. I guess that's what you found by fiddling with the package manifest? :)
You can do a lot of cool things with that. Even populate them dynamically like I do here and here
With regards to building the grid, I had a "pre-populating" extension that were basically superseded by content templates.
There are still some ways to go with making the grid super user friendly, but those two tricks combined makes it a bit less cumbersome.
For one, I'm hoping for /pondering prs with more extension points so it's easier to add functionality without "hacking the core".
Lars-Erik
Hi Nathan,
Like Dave said, started off with custom grid-editors, now it's DocTypeGridEditor for anything complex (within the Grid).
(Which is why we originally developed it.)
However, we're using the Grid less on our new client projects, using StackedContent instead. The decision always comes down to whether the website content is "multi-column" or not.
I'm curious how you achieved this with Archetype? Which makes me think that StackedContent may good fit/replacement for you.
Cheers,
- Lee
Hi Lee
Just installed DTGE locally, awesome package. Definitely agree that more sites are tending back to a single drop of content rather than sidebars etc. I think I can get the result I want through a combo of DTGE and some custom editors and macros. Custom editors quickly become tedious and time-intensive though. We haven't use macros widely in the past, but the UX in the grid is pretty slick.
With Archetype, we've got a single 'master' archetype with 18 different fieldset options - different lists, sliders, banners, maps, all sorts. Those are typically rendered as a full-width row, but some fieldsets (news list, for example) have a property to set it as a sidebar. Obvious benefit with custom grid editors is combining some of that 18-strong set (ie we have a slider, lightbox and cards fieldset, which stores the same data for each but uses a different view - it can be a single editor, with the option to choose the render type).
There's then a bit of branching/looping code in the template to start rendering the fieldsets, and when it hits something set as a sidebar, it spits out the appropriate markup to create a sidebar element.
It works ok, but like you said, there's definitely a trend towards single columns again (happily, in my opinion), and that's the direction I want to move in, but I think we'll still need the option of sidebar content (site is really information dense). Better to have the option and not use it...
Looks like I have some experimenting to do...
Yeah, if the client/website needs multi-column/sidebars, the Grid is great for this.
I'm of the opinion it's better to have all these things in my tool-belt, rather than just a hammer. Choice is good :-)
If DTGE can help you in reducing the number of custom grid editors - that's a good win too.
Cheers,
- Lee
Like others, I also use DTGE - Although rather than just having one DTGE configuration, I use multiple, usually it's a one-to-one setup, (ie separate config for each doctype)
FYI - DTGE wrapping nested content work well in the grid. Nested content wrapping a grid which contains a DTGE does not work.
That's what I've started looking at today - NC doctypes in DGTEs, 1-to-1.
So for example, a slider - it's a DGTE instance, with one allowed doctype, being 'slider', where that type has a few generic properties then a nested content data type, where the available doctype defines the slide object.
Works beautifully with a surface controller (inheriting DocTypeGridEditorSurfaceController) as everything is simply IPublishedContent (or properties on), with which I can build a custom model to pipe back to my views.
All I've had to write is standard MVC stuff, no custom editors to be seen. Lovely.
is working on a reply...