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.
On 11/8/07, Sean Cribbs <[EMAIL PROTECTED]> wrote:
>
> Ryan,
>
> No, you shouldn't have to make any changes to your extensions.
>
> Sean
>
> Ryan Heneise wrote:
> > I like it - looks clean.
> >
> > Will we need to make any changes in current plugins that use Shards?
> >
> >
> >
> > On Nov 8, 2007, at 2:27 PM, Sean Cribbs wrote:
> >
> >
> >> 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 %>
> >> <div id="profile">...</div>
> >> <% end %>
> >> <% my.sidebar do %>
> >> <div id="sidebar">...</div>
> >> <% 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
> >> _______________________________________________
> >> Radiant mailing list
> >> Post: [email protected]
> >> Search: http://radiantcms.org/mailing-list/search/
> >> Site: http://lists.radiantcms.org/mailman/listinfo/radiant
> >>
> >>
> >
> > _______________________________________________
> > Radiant mailing list
> > Post: [email protected]
> > Search: http://radiantcms.org/mailing-list/search/
> > Site: http://lists.radiantcms.org/mailman/listinfo/radiant
> >
> >
>
> _______________________________________________
> Radiant mailing list
> Post: [email protected]
> Search: http://radiantcms.org/mailing-list/search/
> Site: http://lists.radiantcms.org/mailman/listinfo/radiant
>
_______________________________________________
Radiant mailing list
Post: [email protected]
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
