Partials usage best-practices?

[Jon]

Ramping up on Sinatra and am currently playing with partials. As my background is not Rails, I'd appreciate any usage and implementation feedback on best practices with Sinatra + HAML.

In the following (working in Ruby 1.8.6) code snippet, forget for the moment that the templates and CSS are inline and no helpers are used....and imagine that the templates are in separate files.

Is this style of using partials in both the main layout and in sub-templates how templates are best modularized using Sinatra + HAML?

TIA, Jon

# wowee.rb

require 'sinatra'

get '/' do
haml :index
end

__END__
@@ layout
%html
%head
%body
#header= haml :header, :layout => false
= yield
#footer= haml :footer, :layout => false

@@ index
%h1 Hello World

@@ header
%span Default Header

@@ footer
Copyright ©
= Time.now.year
= haml :company, :layout => false

@@ company
%span{ :style => 'font-weight: bold; font-style: italic;' } Dynamically Created Co.

[candlerb]

This is pretty much what I do, and it doesn't cause me any problems,
although if anyone has better suggestions I'm interested to hear them.

I follow the Rails convention of starting "partials" with an
underscore, e.g. haml :_company. I haven't yet bothered to modify the
haml helper so that it defaults to :layout => false in this case. I
will when it annoys me sufficiently :-)

Also, I'd like to be able to replace

haml :_company, :layout=>false, :locals => {:name => @company.name}

with

haml :_company, :name => @company.name

Rails has made some changes along this line:
http://ryandaigle.com/articles/2008/11/20/what-s-new-in-edge-rails-render-stops-being-high-maintenance

[Ryan Tomayko]

Defaulting :layout to false when rendering templates that begin with
"_" is an interesting idea. We're also considering defaulting :layout
to false when rendering a template within another template:

http://sinatra.lighthouseapp.com/projects/9779/tickets/181

I'm not very happy with the patch but it seems like a good concept.

Thanks,
Ryan

[Jon]

> Also, I'd like to be able to replace
>
> haml :_company, :layout=>false, :locals => {:name => @company.name}
>
> with
>
> haml :_company, :name => @company.name
>

+1

While I like the assumptions based upon the leading "_" convention (or Ryan's "where am I rendering from" based idea), should this new behavior be overridable via a set option?

I'm too noob to Sinatra to have a use case yet as to why an option would be useful, but as I'm trying to wrap my head around how to write sub-templates that can select their layout (think overall site layout with ability to have multiple "content section" sub-layouts selectable by the sub-templates similar to ASP.NET's nested Master Pages), my spidey sense thinks we may need the ability to make the :layout => false assumption(s) overridable.

I suspsect there may already be a perfectly great way to do this, and I just haven't stumbled upon it yet. Links appreciated if it does.

[Scott Taylor]

I like this idea.

I've been doing a bunch of refactoring work on the template handlers /
rendering engines. I'll post something to this list if I get around to
adding this feature.

Scott


> >
>

[Christopher Schneider]

I like to wrap haml or erb calls in a custom render() helper. Then you
can add all your magic rendering logic specific for your app.

It's an easy way to get all this sub-layout / collection and other
magic right away without waiting for core Sinatra patches.

Chris

[Daniel Huckstep]

I'm not a huge fan of the "layout => false when within another template" because on one of my apps, I render partials from the main get '/whatever' block in order to do AJAX stuff, and having something like context sensitive rendering won't work for that.

The underscore idea I like, since it would be consistent everywhere.

- Daniel

--
- Daniel

[Tanner Burson]

I created a helper named partial, that just sets the layout to false, and merges the options, which works great for most cases. 

For more complicated tweaks, like support I added for a 'fallback' layout, I wrote a plugin that aliased the erb method and replaced it with my own that ends up calling the original erb method.  This gave me a lot of flexibility in how I wanted to munge the options, without my app having to really be aware of how the plugin worked.

--
===Tanner Burson===
tanner...@gmail.com
http://www.tannerburson.com