Question/Poll for Shards developers

Shards developers,

I’m about to make a major change to the Shards extension’s API and I
want a little feedback from those who are using it. This is not a
breaking change, per se, but a behavioral one. Let me set it up for
you.

Right now, the views (especially new/edit) for the Admin::PageController
are broken into a bajillion little pieces so that we can have many
points of insertion into the template. This is great for flexibility,
but results in a bunch of tiny files and the need to dig through them to
find the proper region when you want to insert something. I’d like to
dramatically reduce the number of partials that ship with the extension.

The solution to this, which I have working, is to move the partials back
into one (or a few) files and provide a way to specify defaults, but
still allow overriding of the partials in the file system. Here’s an
example of what I’m talking about. Normally, when you render a region,
a line like this exists in the template:

<%= render_region :my_region %>

Via the ‘admin’ object, you would populate this region with partial
names, which would be rendered from the file system in the order
specified. If this region has default partials, as do the ones that
come with Shards, they would instead be specified inline, where
appropriate. Let’s say “my_region” has default partials of “profile”
and “sidebar”; this is how you would specify them (notice the removal of
the =):

<% render_region :my_region do |my| %>
<% my.profile do %>


<% end %>
<% my.sidebar do %>

<% end %>
<% end %>

This adds a bit of weight and noise to the templates, but significantly
cuts down the number of partials. Regions that don’t have any default
partials could still be rendered in the manner shown in the first
example (with the =). Let me know how you feel about this change.

Sean

I like it - looks clean.

Will we need to make any changes in current plugins that use Shards?

Ryan,

No, you shouldn’t have to make any changes to your extensions.

Sean

why not implement a default_content_for() method that you use to display
the
radiant admin’s content and then provide methods to extension writters
to
use the basic rails content_for() methods to override.

What’s the rationale behind ‘render_region’ ?

Also, if possible give extension authors a choice.
In the radiant ‘core’ you might define part of the page edit screen with
default_content_for(“edit_submit_buttons”)

Then, give extension authors the option of either creating a
_edit_submit_buttons partial OR putting a
content_for(“edit_submit_buttons”)
into a general “_edit_defaults” partial…

something like that…

With a bajillion little files, it’s clear what I need to name my file
and
where to put it in order to override a particular one of those files, If
the
structure of these partials is going to change, it should be possible
for an
extension to take the same structure and specifically override parts
with
content_for like blocks…

just some ideas.

Jacob,

At this point, I wasn’t looking to change the usage of the extension,
only its internals. You can still override the partials named in the
admin object, it’s just when they fail to render from the filesystem,
they fall back to the inline version.

The reason for using the region idea (which has been in there since
shards was the facets branch) is that we want flexibility in the way
that extension authors can manipulate the interface, without clobbering
each other’s changes. Yes, it’s still possible, but if you play nice
(i.e. not removing all partials from a region), you won’t normally break
another extension.

If you can provide a prototype of the alternative implementation you
propose, I’d be glad to consider it.

Sean

P.S. I already committed the core changes to the extension and will
finish updating the views today.