Right, I’ve just made my last big batch of changes in the sidebar
subsystem for a while (modulo any bug fixes that crop up as a result
of this) and thought I’d better give you the heads up on them.
First of all, and I can’t stress this enough, if your sidebar’s
configure.rhtml looks anything like this:
<%= form_tag … %>
<%= end_form_tag %>
<%= observe_form … %>
then you MUST at least get rid of the form_tag and observe_form parts
of it. Nested forms break browsers.
Ahem.
You might prefer to get rid of your configure.rhtml altogether though.
Here’s archives_controller.rb before the API changes
class Plugins::Sidebars::ArchivesController <
Sidebars::ComponentPlugin
def self.display_name
“Archives”
end
def self.description
'Displays links to monthly archives'
end
def self.default_config
{'count' => 10, 'show_count' => true}
end
def content
...
end
def configure
end
end
And here it is after:
class Plugins::Sidebars::ArchivesController <
Sidebars::ComponentPlugin
display_name ‘Archives’
description ‘Displays links to monthly archives’
setting :show_count => true, :label => 'Show article counts',
:input_type => :checkbox
setting :count, 10, :label => 'Number of Months'
def content
...
end
end
Actually, I lied, it doesn’t have a ‘display_name’ declaration because
Sidebars::ComponentPlugin does a much better job of working out the
default display name.
And here’s its configure.rhtml after the changes:
That’s right, it doesn’t actually have one because the setting
declarations give enough information for us to build the configuration
div automatically. There’s a few wrinkles if you need a text area,
group of radio buttons or a ‘select’ menu, but there are good examples
of all of those to be found in ‘xml_controller.rb’,
‘flickr_controller.rb’ and ‘static_controller.rb’.
Sidebars still aren’t being tested, but I think it might be possible
to test them now. I’m also planning on writing a sidebar generator to
make the sidebar author’s life even easier, but that’s probably way
over on the ‘sometime’ milestone.