My controllers have gotten unwieldy. The situation looks well-suited to the use of the MVP pattern but the latest links Google is giving me are from ''07. Looks like there was some pretty good discussion that just fell off a cliff. Has someone come up with a better solution? A little background on my situation in case it helps and you''re still reading ;-) What was initially envisioned as a fairly typical Rails application with a heavy dose of RJS has grown into a soon-to-be RESTful (or soon will be) Rails web service that talks to two Ajax clients, one a single-page and the other a multipage app, and two self-spawned HTTP clients. Each of the clients is pretty-well constrained in terms of the resources / methods it needs. I''m thinking of moving the Ajax clients to using an MVP pattern and keeping the HTTP clients on the standard Rails MVC pattern. My thought is that if each client is restricted to one ''channel'' (HTML | JS | XML) then I''ll not only get better structure / testability on the code serving the Ajax clients, from a security perspective, I can lock down resources by URL, HTTP verb, and protocol. Any thoughts / discussion is much appreciated. Best regards, Bill --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
bill walton wrote:> > Any thoughts / discussion is much appreciated.The original concept of controllers in MVC was that they handled terminal events like mouse and keystrokes. The elaboration of MVC into MVP moved that responsibility into another layer between views and controllers called a presenter. One could argue that what one really has with Rails 2.x is MVP, with the browser acting as the presenter, rather than MVC. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Hi James, Thanks much for the reply! On Mon, 2009-03-30 at 03:59 +0200, James Byrne wrote:> bill walton wrote: > > > > > Any thoughts / discussion is much appreciated. > > The original concept of controllers in MVC was that they handled > terminal events like mouse and keystrokes. The elaboration of MVC into > MVP moved that responsibility into another layer between views and > controllers called a presenter.Interesting. My understanding / impression is that the presenter sits between a controller and a set of models.> One could argue that what one really > has with Rails 2.x is MVP, with the browser acting as the presenter, > rather than MVC.Don''t think I understand this perspective. Say more, plz. My understanding is that one ''purpose'' of the Presenter pattern is to restore the ''silo-like'' source code organization that MVC brings to the table. With MVC, if I need to modify the customer info section of an app, I know I''ll be looking at customers_controller.rb, .rhtml files in the views/customers folder, and the customer.rb file in the models folder. Best regards, Bill --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---