I like the "provides :xml" or "publish :xml" syntax with the usual options
(:only, :except, :if etc.).that way you can manage all the response type
from one location.
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.
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)
I personally think that the guys from make_resourceful got it almost right.
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.
You can still make it work with just methods, maybe something like this
class User < Application
# sets default responses and returns values
publish :html, :xml, :json, :only => [:show, :edit, :destroy], :returns =>
{:user => [:login, :email], :head => "success"}
# run filters conditionally to request type
before :index, :show, :do => [:get_user, :increase_counter] if
requested_as(:html, :xml)
# custom responses by request types
responses_for [:index, :destroy] => {:xml => :user,
:html => render(" index.erb")}
def index
#only code in common with all the responses here.
end
end
Just trowing some ideas out there.
Diego
I imagine you could pass reponses_for an array of hashes too.
responses_for :show => {:xml => :user}, :destroy => {:xml => {:head =>
"success"}}
responses_for :edit => {:xml => Proc.new{ render "index.erb"}}
On 9/20/07, Ezra Zygmuntowicz <[EMAIL PROTECTED]> wrote:
>
>
> Merb controllers cannot be modules because modules are not
> instantiatable. The way merb's thread safety works is by
> instantiating a new controller object for each new request/thread.
>
> -Ezra
>
> On Sep 20, 2007, at 1:13 PM, ry dahl wrote:
>
> > On 9/20/07, John Weir <[EMAIL PROTECTED] > wrote:
> >> how would filters and common methods work?
> >
> > one way this could be done is by attaching a filters as class methods
> > to the actions. for example
> >
> > module Controllers::Products
> > before Index, Show do |request|
> > raise Unauthorized unless request.session[:user].admin?
> > end
> > ...
> > end
> >
> > would take the block argument, add do
> > Index.class_eval { @@before_filter = block }
> > for both Index and Show. At the time of request, the dispatcher could
> > call that block before instantiating the action.
> >
> > this is just an example for entertaining the idea - not a proposal - i
> > haven't thought all the way through it
> >
> >
> >>> For example,
> >>>
> >>> module Controllers::Products
> >>> class Index < GetAction
> >>> def initialize(params)
> >>> @products = Product.paginate(params[:page] || 1)
> >>> end
> >>>
> >>> def response_json
> >>> @products.to_json
> >>> end
> >>>
> >>> def response_html
> >>> render 'products/index.erb'
> >>> end
> >>> end
> >>>
> >>> class Show < GetAction
> >>> extra_route ':id'
> >>>
> >>> def initialize(params)
> >>> @products = Product.find(params[:id])
> >>> end
> >>>
> >>> def response_html
> >>> render 'products/show.erb'
> >>> end
> >>> end
> >>> end
> >>>
> >>> <%= link_to 'Products', Controllers::Products::Index.url %>
> >>>
> >>>
> >>> On 9/20/07, ry dahl < [EMAIL PROTECTED]> wrote:
> >>>> Sometimes it seems like actions deserve to be their own objects: we
> >>>> map routes to them, we'd like to know what parameters they
> >>>> expect, we
> >>>> want to say which http methods they accept, we assign them
> >>>> before/after filters, and we even hold collections of them
> >>>> (Controller.callable_actions ). This responds_to issue is another
> >>>> example of how we'd like to treat actions as objects. We would like
> >>>> for the controller to look at the request, determine which
> >>>> format to
> >>>> send, and then simply call my_action.render_json or
> >>>> my_action.render_html. Simultaneously, our controllers are not very
> >>>> class like. They are basically instantiate them only to call the
> >>>> action. Changing the Controller class into a module would not be so
> >>>> hard in the current Merb - they are (more or less) just containers
> >>>> for
> >>>> actions.
> >>>>
> >>>> Has anyone else been having these thoughts?
> >>>>
> > _______________________________________________
> > Merb-devel mailing list
> > [email protected]
> > http://rubyforge.org/mailman/listinfo/merb-devel
>
> -- Ezra Zygmuntowicz
> -- Founder & Ruby Hacker
> -- [EMAIL PROTECTED]
> -- Engine Yard, Serious Rails Hosting
> -- (866) 518-YARD (9273)
>
>
> _______________________________________________
> Merb-devel mailing list
> [email protected]
> http://rubyforge.org/mailman/listinfo/merb-devel
>
_______________________________________________
Merb-devel mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/merb-devel
