[LRUG] Rails : Drying Up Views

[Tom Armitage]

Various options for your "sidebar" example, notably, providing  
everything you want the sidebar in a different layout. Or conditional  
stuff (ew) in the layout. Or, as I've done in places, a directory  
called /views/partial and then calling render on "/views/ 
partial" (opening slash important).

I'm also a big fan of building helpers by functionality as well as by  
method. Usually, you have very few controller-specific methods, and a  
massive application_helper.rb . We went some way in refactoring that  
by creating links_helper.rb (wherein all our link_to_foos lie),  
formatting_helper.rb (which contains everything to do with eg  
formatting textile, formatting for email, formatting for rss, etc)  
and images_helper.rb (which our app needed).

All these are referenced in application.rb :

[:links, :formatting, :image].each { |each| helper each }

It does the same thing, but makes it a whole lot more atomic. And  
easier to test - we have helper_tests too.

On one project, we had one partial used throughout the application.  
It was beautifully DRY, but the partial was 200 lines of code, with  
loads of toggleable bits dependent on how you wanted it to look. You  
passed in a hash of options when you rendered the partial. In the  
end, this just turned out to be unwieldy - far easier to just put  
each slightly-different bit of HTML into the appropriate set of  
controller views once. More repetetive, but more easily maintained,  
too. So don't obsess too much about DRY if there are lots of slight  
variations here and there, I'd say.

Finally, here's what our standard link_to_object helper looks like:

   def link_to_user(user, text = nil, options = {})
     link_to h(text || user.name), profile_url(:keyword =>  
user.keyword), options
   end

which is a pattern we use a lot, and one I'm a big fan of - easily  
overridden, but means you can write link_to_user(@user) a lot.

t.

On 11 Sep 2007, at 17:01, Anthony Green wrote:

>
>
> Does anyone have any techniques for sharing view code generators
> (partials, helpers, yielding to content_for) across actions in  
> different
> controllers.
>
> I’m finding most techniques blogged about only deal with situations  
> where
> there is more commonality between view/actions within a controller  
> than
> view/actions (with the same name) across controllers.
>
>
> -- 
> Anthony Green
> Client Side Developer - Programme Information Tool
> Audio & Music Interactive
> BBC Future Media & Technology
>
>
>
> http://www.bbc.co.uk/
> This e-mail (and any attachments) is confidential and may contain  
> personal views which are not the views of the BBC unless  
> specifically stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in  
> reliance on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
> 					
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org


---
Tom Armitage
tom at infovore.org
07813 060578