Re: Proposed API change for respond_to

Thu, 04 Oct 2007 04:20:43 -0700


Has anyone had any more thoughts on what is to be done with respond_to?
I'm using it quite a lot now, and it really doesn't feel great, especially when you have quite a large action that has many responses.


Attachment: example.tar.bz2
Description: Binary data



I really liked the ideas with actions as classes... and was playing with syntax, for a router and app layout ... attached should be a prettymuch barebones app with some comments if anyone is interested.

My routing idea basically hands over most of the routing logic to the app developer and simply provides a frame to say 

"if a url matches this regex"..."run this block"... "I expect to get an action class back"

this would make the router code in any framework very small/fast and easy to follow, and put all the routing power in the hands of the dev, who wouldn't have to learn any special syntax.




Regards

Farms.
Design & Dev


Oxygen.

On 22 Sep 2007, at 13:34, Chris Farmiloe wrote:




On 21 Sep 2007, at 21:22, Duane Johnson wrote:
 With this architecture, we could take  
advantage of inheritance in the OO way (as well as map exceptions to  
actions the OO way):

I think this is an interesting point! 



With more of my projects taking the REST view on the world, I'll often have a base controller with common create/update/show/delete methods, that I then overide if they need modifying.

By taking an approach where actions are classes, this situation might be improved.

Worth thinking about ... but is quite a step away from the current "way" that it's not going to be an easy switch.

might the idea maybe be to have:

app/controllers/users/index.rb

class Users::Index < Users::Action
def to_html
render
end

def to_xml
'<xml/>'
end
end

which then renders the template at

app/views/users/index.html.erb


where Users::Action is the base "action" class for users (where you would put all your methods that all user actions require) and Users::Action is inherited from Application::Action (where all the app-level methods are) which is a Merb::Action

I think the GetAction idea is poor and all that sort of logic should stay in the router code.

I like the ideas of the matching up of the action.rb file and the template.erb, but I'm not entirly convinced, the directory structures in /controller and /views would be nicely mirrored.


anyway this is all very theoretical, more things for the _ry-experimental-playground-branch ;)





Regards

Farms.



_______________________________________________
Merb-devel mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/merb-devel

Reply via email to