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?


Scott

On 3/20/06, Piers Cawley <[EMAIL PROTECTED]> wrote:
"Scott Laird" <[EMAIL PROTECTED]> 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:

lib/amazon_sidebar.rb
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 page"
  end

  # 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[0].new(params[actives][0])

  # 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 => ''
    end
  end

  def configure
  end
end

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 %>
</div>
<% end -%>

views/amazon/_link.rhtml
<iframe src="" asin %>...&t=<%= sidebar.assoc_id %>


views/amazon/_configure.rhtml
<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
layout.

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 <[EMAIL PROTECTED]>
Ãhttp://www.bofh.org.uk/

_______________________________________________
Typo-list mailing list
Typo-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/typo-list

_______________________________________________
Typo-list mailing list
Typo-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/typo-list

Reply via email to