scott at sigkill.org
Mon Mar 20 14:17:04 EST 2006
I'd really, *really* like to find a way to keep the sidebar code and views
bundled together in the same directory structure. From what I can see here,
you're breaking the two apart as a sort of natural consequence of dropping
components. Can we please find a way to stick them back together?
On 3/20/06, Piers Cawley <pdcawley at bofh.org.uk> wrote:
> "Scott Laird" <scott at sigkill.org> writes:
> > This looks pretty reasonable, at least in principal. Care to
> > providean example of what one of the existing sidebars would look
> > like, andhow the sidebar views fit into the picture?
> Okay, here's how I hope to make the amazon controller work:
> Given a basedir of RAILS_ROOT/vendor/plugins/pluggable_controllers/ we
> would have:
> class AmazonSidebar < PluggableSidebar
> # self.display_name defaults to self.short_name.ucfirst, so no need
> # to implement it here because short_name defaults to 'amazon'
> def self.description
> "Adds sidebar links to any amazon books linked in the body of the
> # config_accessor defines an attr accessor with a default.
> # Could possibly have it take enough information that the nice form
> # helpers that rails provides can build a config form automagically,
> # but that's for later
> config_accessor :associate_id, :default => 'justasummary=20'
> config_accessor :maxlinks, :default => 4
> config_accessor :title, :default => 'Cited books'
> # default initializer works like the standard ActiveRecord::Base
> # initializer, so the admin controller can do things like:
> # sidebar_class_for.new(params[actives])
> # self.default_config -- no need to implement, we just
> # AmazonSidebar.new will set the correct defaults.
> attr_accessor :asins
> def content
> self.asins = params[:contents].to_a.inject() do |list, item|
> list | item.whiteboard[:asins].to_a
> end.compact[0, self.maxlinks]
> if asins.empty?
> render :text => ''
> def configure
> views/amazon/_content.rhtml # possibly content.rhtml
> <% unless sidebar.asins.blank? -%>
> <h3><%=h sidebar.title %></h3>
> <div id='amazon_links'><%=
> render :partial => 'link', :collection => sidebar.asins %>
> <% end -%>
> <iframe src=...&asins=<%= asin %>...&t=<%= sidebar.assoc_id %>
> <label>Associate ID</label>
> <%= text_field_tag "sidebars[associate_id]", sidebar.associate_id %><br
> <label>Max links</label>
> <%= text_field_tag "sidebars[maxlinks]", sidebar.maxlinks %><br />
> <label>Sidebar Title</label>
> <%= text_field_tag "sidebars[title]", sidebar.maxlinks %>
> The thinking here is admin/sidebar has a single form, ordering gets
> sorted out by drag'n'drop without having to keep sending stuff back to
> the server, 'publish changes' then just submits a single form. Also,
> the superclass's configure_wrapper needs to add a "<hidden
> id='sidebars[class]' value='AmazonSidebar'/>" as part of its pseudo
> Even if we can't make admin/sidebar into a single form view, the
> _configure partial really doesn't need to set its own form up...
> Implementing this won't necessarily be straightforward, and it won't
> happen overnight, but there's *far* too much DRY violation going on
> with sidebars at the moment. Things like layouts to set the config
> form up can be implemented independently of any larger changes.
> Piers Cawley <pdcawley at bofh.org.uk>
> Typo-list mailing list
> Typo-list at rubyforge.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Typo-list