[typo] Sidebars

Scott Laird 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?


Scott

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:
>
> 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=...&asins=<%= 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 <pdcawley at bofh.org.uk>
> Ãhttp://www.bofh.org.uk/
>
> _______________________________________________
> Typo-list mailing list
> Typo-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/typo-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/typo-list/attachments/20060320/ad4a6839/attachment.htm 


More information about the Typo-list mailing list