wingedmonkey/wingedmonkey — pull request #41 by tzumainn (2012-11-28 20:28:15+00:00)
Title: Use partials to accommodate differing provider views

This patchset adds render_provider_partial to application_helper.rb. The method is pretty simple:

def render_provider_partial(partial_name, locals = {})
provider_name = current_provider.type
if provider_partial_exists?(provider_name, partial_name)
partial = provider_partial(provider_name, partial_name)
elsif provider_partial_exists?("default", partial_name)
partial = provider_partial("default", partial_name)
end

if partial
render :partial => partial, :locals => locals
end
end

The generic views/launchables/_launchables_list.html.haml calls the above as follows:

- @launchables.each do |launchable|
.box{:style => "margin-bottom: 10px"}
.blueprint
.left
= render_provider_partial("launchable", {:launchable => launchable})
.control{:style => "display:block"}
= link_to "Launch", new_provider_application_path(:launchable_id => launchable.id)

In the case of the mock provider, render_provider_partial renders views/mock/_launchable.html.haml; for any other provider, it would default to views/default/_launchable.html.haml.

So when a developer creates a general workflow, he creates his views as normal - except for the bit that may change for different providers. That bit is replaced with a call to render_provider_partial, and a default partial is added.

Later, when provider-specific views are needed, a developer simply needs to add the provider-specific partial in the views/*provider*/ directory.

If we ever want to pull provider stuff out into its own engine, we simply remove the provider models and provider views, and we're done.

Anyway, that's the theory, let me know what you think!