I like the "provides :xml" or "publish :xml" syntax with the usual options (:only, :except, :if etc.).<div>that way you can manage all the response type from one location.</div><div><br>
</div><div>Sometimes respond_to case-style works well when each response gets something different but many times that's not the case and when it doesn't, it sucks.</div><div><br> </div>
<div>In rails I created a helper that looks at the format param so that I can do something like render :xml => @user.to_xml if requested_as(:xml) </div><div><div><br> </div><div>I personally think that the guys from make_resourceful got it almost right.
</div><div>One thing that I think it's smart is not to use the "def" keyword. Since actions are more than just methods. You could do something more clever. build :index{ something here } that would either define multiple methods or return objects.
</div><div><br> </div><div>You can still make it work with just methods, maybe something like this</div><div><br> </div><div><div>class User < Application
</div><div><br> </div><div> # sets default responses and returns values</div><div> publish :html, :xml, :json, :only => [:show, :edit, :destroy], :returns => {:user => [:login, :email], :head => "success"}
</div><div><br> </div><div> # run filters conditionally to request type</div><div> before :index, :show, :do => [:get_user, :increase_counter] if requested_as(:html, :xml)</div><div><br>
</div><div> # custom responses by request types</div><div> responses_for [:index, :destroy] => {:xml => :user,</div><div><span style="white-space:pre"> </span> :html => render("
index.erb")}</div><div><span style="white-space:pre"> </span> </div><div> def index</div><div><span style="white-space:pre"> </span>#only code in common with all the responses here.
</div><div> end</div><div><br> </div><div>end</div></div><div><br> </div><div>Just trowing some ideas out there.</div><div>Diego</div><div><br>
</div><div>I imagine you could pass reponses_for an array of hashes too.</div><div>responses_for :show => {:xml => :user}, :destroy => {:xml => {:head => "success"}}<br>responses_for :edit => {:xml =>
Proc.new{ render "index.erb"}}</div><div><span class="e" id="q_115291a6e8dfacf5_1"><div><br><div><span class="gmail_quote">On 9/20/07, <b class="gmail_sendername">Ezra Zygmuntowicz</b> <<a href="mailto:ez@engineyard.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
ez@engineyard.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><br> Merb controllers cannot be modules because modules are not<br>instantiatable. The way merb's thread safety works is by
<br>instantiating a new controller object for each new request/thread.<br><br>-Ezra<br><br>On Sep 20, 2007, at 1:13 PM, ry dahl wrote:<br><br>> On 9/20/07, John Weir <<a href="mailto:john@smokinggun.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
john@smokinggun.com
</a>> wrote:<br>>> how would filters and common methods work?<br>><br>> one way this could be done is by attaching a filters as class methods<br>> to the actions. for example<br>><br>> module Controllers::Products
<br>> before Index, Show do |request|<br>> raise Unauthorized unless request.session[:user].admin?<br>> end<br>> ...<br>> end<br>><br>> would take the block argument, add do<br>> Index.class_eval
{ @@before_filter = block }<br>> for both Index and Show. At the time of request, the dispatcher could<br>> call that block before instantiating the action.<br>><br>> this is just an example for entertaining the idea - not a proposal - i
<br>> haven't thought all the way through it<br>><br>><br>>>> For example,<br>>>><br>>>> module Controllers::Products<br>>>> class Index < GetAction<br>>>> def initialize(params)
<br>>>> @products = Product.paginate(params[:page] || 1)<br>>>> end<br>>>><br>>>> def response_json<br>>>> @products.to_json<br>>>> end<br>>>>
<br>>>> def response_html<br>>>> render 'products/index.erb'<br>>>> end<br>>>> end<br>>>><br>>>> class Show < GetAction<br>>>> extra_route ':id'
<br>>>><br>>>> def initialize(params)<br>>>> @products = Product.find(params[:id])<br>>>> end<br>>>><br>>>> def response_html<br>>>> render 'products/show.erb'
<br>>>> end<br>>>> end<br>>>> end<br>>>><br>>>> <%= link_to 'Products', Controllers::Products::Index.url %><br>>>><br>>>><br>>>> On 9/20/07, ry dahl <
<a href="mailto:ry@tinyclouds.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">ry@tinyclouds.org</a>> wrote:<br>>>>> Sometimes it seems like actions deserve to be their own objects: we
<br>>>>> map routes to them, we'd like to know what parameters they
<br>>>>> expect, we<br>>>>> want to say which http methods they accept, we assign them<br>>>>> before/after filters, and we even hold collections of them<br>>>>> (Controller.callable_actions
). This responds_to issue is another<br>>>>> example of how we'd like to treat actions as objects. We would like<br>>>>> for the controller to look at the request, determine which<br>>>>> format to
<br>>>>> send, and then simply call my_action.render_json or<br>>>>> my_action.render_html. Simultaneously, our controllers are not very<br>>>>> class like. They are basically instantiate them only to call the
<br>>>>> action. Changing the Controller class into a module would not be so<br>>>>> hard in the current Merb - they are (more or less) just containers<br>>>>> for<br>>>>> actions.
<br>>>>><br>>>>> Has anyone else been having these thoughts?<br>>>>><br>> _______________________________________________<br>> Merb-devel mailing list<br>> <a href="mailto:Merb-devel@rubyforge.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
Merb-devel@rubyforge.org</a><br>> <a href="http://rubyforge.org/mailman" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://rubyforge.org/mailman</a>/listinfo/merb-devel<br><br>-- Ezra Zygmuntowicz
<br>-- Founder & Ruby Hacker<br>-- <a href="mailto:ez@engineyard.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
ez@engineyard.com</a><br>-- Engine Yard, Serious Rails Hosting<br>-- (866) 518-YARD (9273)<br><br><br>_______________________________________________<br>Merb-devel mailing list<br><a href="mailto:Merb-devel@rubyforge.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
Merb-devel@rubyforge.org</a><br><a href="http://rubyforge.org/mailman" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://rubyforge.org/mailman</a>/listinfo/merb-devel<br></blockquote></div><br>
</div></span></div></div>