> Q: Where do I put the code for creating the Period? Should I setup a > PeriodController and redirect from CalendarController to > PeriodController.create somehow? Or maybe I should just do Period.save > from CalendarController? This seems to be a point of confusion. A "resource" in the Rails interpretation of the REST convention is not a one-to-one correspondence to "model" objects in an MVC design pattern. It just happens that models tend to be represented by, and as, a resource.
However, you can certainly have resources that are not models and models that are not resources. Think a a resource as anything that can be described by the basic CRUD operations. In other words, anything that can be manipulated by creating, reading, updating or deleting. For example, user sessions are not necessarily represented by a database table, so are not generally ActiveRecord subclasses. Yet you can manipulate them as "resources" using the REST convention. The act of a user signing into an application can be represented by "creating" a new user session resource. And, the act of signing out then becomes a "delete" operation on that resource. Notice that the other two CRUD operations are not really necessary in this case The controller does not have to be involved in the reading or updating of session objects. In this case the object is directly manipulated since the manipulation does not require an independent request-response cycle. So in Rails the controller is not really required here. The original concept of "web resources" defined by the HTTP protocol (independent of anything Rails) were defined by pages and other files stored remotely and accessed though HTTP. POST was intended for pushing new pages/files to the server, PUT was intended to replace existing pages/files with an updated/edited version, GET was to be used to access existing pages/files, and DELETE obviously was used to destroy a specific page/file. Then the web browser was invented, by individuals that didn't seem to understand HTTP, and this whole concept was lost. RESTful conventions are an attempt to return to the original intent of the HTTP protocol, but in the context of the modern dynamic web. REST is intended to be a bridge between HTTP CRUD (POST, GET, UPDATE, DELETE) and database CRUD (INSERT, SELECT, UPDATE, DELETE). REST is also an attempt to bridge the representation of the resources by using existing and well understood formats (XML, JSON, YAML, HTML, RSS, ATOM, etc.) Hopefully, this will help make it clear that REST is not a hard-and-fast set of rules. It is a convention, and a framework, for standardizing the server-client communication over the HTTP protocol. The important thing is for you to "discover" what makes sense for your application and how that best fits into this RESTful framework. And that is not always going to be: "This is an ActiveRecord so it will always be a resource and have it's own controller." Or: "This is not an ActiveRecord so isn't going to be a resource with it's own controller." Well that was a long winded way to say: "It's your application, do what makes sense for your particular use case." Keep the REST design in mind if you think it makes sense and fits your case. That being said a lot of people are finding that the REST approach really does fit a lot, dare I say, most of the use cases people encounter. You just need to get your head wrapped around it. -- 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 [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
