We’re finding the Configure Resource Page feature too limited to achieve the Item layout customisations we want:
Different Resource Page layout depending on Class or Resource Template of Item
Customised, multicolumn and/or tabbed layout for Property Values
Custom layout for certain Properties, but not others of the same Type
Including Properties from related Resources
I guess there’s two ways to do this, each with shortcomings:
Use the traditional full custom Page layouts
Use Configure Resource Page by creating custom Resource Page Blocks that embed the custom layouts
Are there other (easier?) options I’m missing for our various requirements?
Ideally what I’d love to be able to do is visually layout a Resource including Values using the same Block and Grid layout tools we now have for regular Pages.
Some of what you’re talking about, like including properties from related resources, sound like things that could just be new resource page blocks (provided by a module, though a future release will allow the theme itself to provide resource page blocks).
Others could be, depending on your need: a block that displays property values which looks at the resource’s class or template to decide what to show and/or how to show it, for example.
Of course you can use the “traditional” layouts and just control the whole page (and do so conditionally based on class/template/metadata), yes.
When you mention tabbed layout for values, you’re thinking about splitting the values between the tabs, right? We’re looking at tabbed layout as an option in the context of the theme-provided blocks I mentioned before, but breaking up the values into different chunks, that still requires separate blocks.
I think there’s definitely room for more options with the resource page blocks… whether that’s additional core-provided blocks, or some block-level configurability, I’m not sure. A smaller step that, say, allowed you to whitelist/blacklist properties from an instance of the Values block to make it easier to set up something like “these two properties are in the main area, everything else is in the sidebar,” is more of the line along which I’ve been thinking.
Thanks John. Currently going down the Resource Block route, as it seems to require less customisation and future maintenance.
Good to hear defining Resource Blocks will be added to Themes soon, it feels a more natural place for them, but fortunately I have to have a custom module anyway.
Yes, we’d like to split the values over tabs. Definitely in favour of something like the block-level configuration you suggest. Perhaps something like Property Groups where you group properties together and can then assign that group to a Block? That way you could say this value block goes in column 1, this block in a tab, this block in the sidebar, etc?
Just to note, the Default theme defines a Right Sidebar area to place resource blocks into, but it doesn’t actually render it. Easy enough to override the show.phtml to include it based on the code in the docs, but a little confusing to start with when you assign the blocks and they don’t show up! Perhaps best to remove it from the Theme?
The property groups thing is along the rough lines I’ve been considering, yes. A module could provide that functionality today with the current block system, and possibly a module like that is the right solution, as it avoids building the level of complexity into the resource page blocks UI that block-level configuration would imply.
Building my resource blocks, something I’ve found that would be useful in the API is for AbstractResourceEntityRepresentation::displayValues() and AbstractResourceEntityRepresentation::values() to take an option for a list of properties you want. Or at least a displayValue() method for a single property. I’ve had to make a copy of displayValues() instead. That would also prove useful for a Property Group module.
You’d like displayValues() for a single property rather than the existing value()? Just for the structure of divs and so on, or for another reason?
displayValues() takes an options array, so an option to only show the given terms, or not show the given terms, shouldn’t be a problem. In terms of what’s there today, do take note of the rep.resource.display_values event, which lets you filter the array of values before the template gets rendered. Though we probably need to make that event take the passed-in options as an argument also to make it really feasible to use the event for this kind of thing.
Yeap. So I have a resource page layout with a Main region and a Right Sidebar region, and I want some of the display values to go in the Right and the rest to go in the Main. At the moment, the only way I can see to do that is in a resource block to call value() for each property I want and then render the partial, i.e. basically recreate displayValues().
For now I’ve just modified versions of values() and displayValues() to take a property term list. All the work to select and order the values is done in values(), all displayValues() does is pass the option through. Happy to do a pull request if you think it’s worth it.
I’m not sure the rep.resource.display_values event would help here, as I would need to know what block I am in to know what values to filter for. Which is why configurable resource blocks would be great, we could have a generic values block that you can then configure with properties to render and reuse that throughout the layout.
My reference to the event was with the idea that you could pass displayValues() an argument of your own creation, then apply it with the event. So you could pass the properties to show, or pass the name of your current block, and then filter accordingly. But it’s a moot point since we don’t pass along the options anyway. It’d be possible to do this now without the options getting passed along (e.g., make a call before the displayValues() call that sets to your module code which properties to filter), but unnecessarily onerous.
We already have code in progress, soon to be merged, to:
pass those options from the method’s options argument to the event, so that kind of pattern of a module adding its own functionality there would be possible in the future, as well as just possibly letting modules take actions based on which of the core options were passed,
implement a “properties” option to limit the displayed properties to the passed terms,
implement an “exclude properties” option to exclude the passed terms from the displayed properties
This is all going into displayValues() and not values(), as the pattern so far has been to keep values() returning all values and to have filtering/selection done at later steps. But I’ll have a think about whether we’d like to shift that.
