Hey all, I''ve historically been pretty old-school about my app design. But I''m finally taking a look into REST. I have to say I really understand George Baily''s take on the thing, it''s not easy to see the magic coming in. However, I figure I''ll give it a good shot for a new project and see if I end up getting it. That being said, I have a question. What would be the stylistically correct way to approach something like adding methods to controllers like GenericController#returnCountOfAllItemsWhereX (Where X could be all Generics newer than Y, etc) I know the function that gets the value should be in the model, but historically I would have created a method in my controller similar to that (ok, not so verbose, but you know ; ) that retrieved the value from the model and sent it out. Another question would be if I had an association like Project (has_many :tasks) and Task(belongs_to :project), how (being stylistically correct RESTwise) would I go about getting all the Tasks for a Project from the TasksController (ie, I don''t want to get the Project then Tasks, but have the Project.id). This make any sense at all? I''ve considered that maybe I could create other controllers to handle those functions, which from my understanding is what I should do, but everything I''ve thought of in that direction just makes the app more confusing. This seems very anti-REST (per my understanding). How would you REST experts handle these types of situation? Anyway, any help is appreciated, I feel like I''m on the edge of figuring out something very useful, but some issues like this are in my way. I get the impression that REST is a lightbulb kind of thing, and until it lights up it''s just tedious seeming. H P.S. Just because it might help make the 2nd example a little less crazy, I''m working on a Flex/Cairngorm/RAMF/Rails project. I''m not returning associations with the Project data. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
On 05 Jan 2008, at 01:12, Hardy wrote:> Another question would be if I had an association like Project > (has_many :tasks) and Task(belongs_to :project), how (being > stylistically correct RESTwise) would I go about getting all the Tasks > for a Project from the TasksController (ie, I don''t want to get the > Project then Tasks, but have the Project.id). This make any sense at > all?Generally when you enter a url like http://mydomain.com/projects/1/ tasks, in a RESTful environment, it would mean you are planning to use both the tasks and the project as part of the resource you''re getting. I would fetch the project @project (with an :include => :tasks if needed) and get the tasks from there. That said, there''s nothing holding you back from just doing something like Task.find_by_project_id(params[:project_id]) since that''s what you''ll get in your params anyway. With a bit of creativity and ruby juggling it would even be possible to dynamically create instance variables for every foreign key that''s passed in through the params hash. Best regards Peter De Berdt --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
On Saturday 05 January 2008, Hardy wrote:> That being said, I have a question. What would be the > stylistically correct way to approach something like adding methods > to controllers like GenericController#returnCountOfAllItemsWhereX > (Where X could be all Generics newer than Y, etc) I know the function > that gets the value should be in the model, but historically I would > have created a method in my controller similar to that (ok, not so > verbose, but you know ; ) that retrieved the value from the model and > sent it out.I''d map it to a resource like this GET /generics/count?X=Y map.resources :generics, :collection => { :count => :get } class GenericsController < ... def count @count = Generics.count(...params[...]...) ... end end Michael -- Michael Schuerig mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org http://www.schuerig.de/michael/ --~--~---------~--~----~------------~-------~--~----~ 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@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
I have screen cast that shows how to use nested resources using Rails 2.0. The example is on project resource that has many iterations. Here is the link : http://www.rubyplus.org/episodes/24-Nested-Resources-in-Rails-2-.html On Jan 4, 2008 4:12 PM, Hardy <hardaur-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Another question would be if I had an association like Project > (has_many :tasks) and Task(belongs_to :project), how (being > stylistically correct RESTwise) would I go about getting all the Tasks > for a Project from the TasksController (ie, I don''t want to get the > Project then Tasks, but have the Project.id). This make any sense at > all? > >-- http://www.rubyplus.org/ Free Ruby and Rails Screencasts --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Hardy said the following on 04/01/08 07:12 PM:> Another question would be if I had an association like Project > (has_many :tasks) and Task(belongs_to :project), how (being > stylistically correct RESTwise) would I go about getting all the Tasks > for a Project from the TasksController (ie, I don''t want to get the > Project then Tasks, but have the Project.id). This make any sense at > all? > > I''ve considered that maybe I could create other controllers to handle > those functions, which from my understanding is what I should do, but > everything I''ve thought of in that direction just makes the app more > confusing. This seems very anti-REST (per my understanding).As far as I can make out the nested REST end up with URLs like http://example.com/project/1/task/47 I come from the world of Wikis and that makes no sense to me.The ''user friendly version would http://example.com/HouseRenovation/GetBuildingPermit And I don''t have any problem writing a controller that doesn''t have a model behind it as Daniel suggested, and there don''t have to be controllers for each model. If you want to see this ''old school'' look at how Instiki is implemented. Yes, its route as the ''/wiki'' prefix but that''s not needed. None of my wikis have ever had a prefix once I get past the admin scaffolding. To me, a ''clean url'' is one that doesn''t have structural or implementation specific/dependant information in it. I''ve never felt comfortable with that controller-per-model and each controller-needs-a-model way of working except for the Admin:: scaffold.> How would you REST experts handle these types of situation? Anyway, > any help is appreciated, I feel like I''m on the edge of figuring out > something very useful, but some issues like this are in my way. I get > the impression that REST is a lightbulb kind of thing, and until it > lights up it''s just tedious seeming.That''s my feeling too. But sometimes I seem to be the ''deaf, dumb and blind'' kid and it works out and is good stuff and its a ''none of the above''.> I''ve considered that maybe I could create other controllers to handle > those functions, which from my understanding is what I should do, but > everything I''ve thought of in that direction just makes the app more > confusing. This seems very anti-REST (per my understanding).I''ve considered a WebController and TopicController but all I can see them doing is being a Web Service to return lists of Web and lists of Topics. One method in each controller. Just like that hypothetical SearchController. Yes it does make things more confusing. -- Two of my imaginary friends reproduced once.... with negative results. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
On Jan 4, 2008, at 11:24 PM, Anton J Aylward wrote:> As far as I can make out the nested REST end up with URLs like > > http://example.com/project/1/task/47 > > I come from the world of Wikis and that makes no sense to me.The ''user > friendly version would > > http://example.com/HouseRenovation/GetBuildingPermitThere''s absolutely nothing incompatible with this. REST is not about how you structure URLs, it''s about how you structure your application. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Michael D. Ivey said the following on 05/01/08 01:14 AM:> On Jan 4, 2008, at 11:24 PM, Anton J Aylward wrote: >> As far as I can make out the nested REST end up with URLs like >> >> http://example.com/project/1/task/47 >> >> I come from the world of Wikis and that makes no sense to me.The ''user >> friendly version would >> >> http://example.com/HouseRenovation/GetBuildingPermit > > There''s absolutely nothing incompatible with this. REST is not about > how you structure URLs, it''s about how you structure your application.Which is what I''ve been saying. I can do it without REST therefore it has nothing to do with REST. But why, oh, why, oh why do all the examples of nested REST go on about structuring URLs like that? Go back and look at Ryan Bigg''s excellent and comprehensive explanation in this thread. There it is: /forums/1/topics/1 <- showing a single topic If this isn''t a REST matter then why, oh why does it appear in just about every explanation of REST I find on the net? -- Wisdom is earned through bitter experience. Idiocy comes easily. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
2008/1/5, Anton J Aylward <aja-XdPx9462FWc@public.gmane.org>:> > Michael D. Ivey said the following on 05/01/08 01:14 AM: > > On Jan 4, 2008, at 11:24 PM, Anton J Aylward wrote: > >> As far as I can make out the nested REST end up with URLs like > >> > >> http://example.com/project/1/task/47 > >> > >> I come from the world of Wikis and that makes no sense to me.The ''user > >> friendly version would > >> > >> http://example.com/HouseRenovation/GetBuildingPermit > > > > There''s absolutely nothing incompatible with this. REST is not about > > how you structure URLs, it''s about how you structure your application. > > Which is what I''ve been saying. I can do it without REST therefore it > has nothing to do with REST. > > But why, oh, why, oh why do all the examples of nested REST go on about > structuring URLs like that?Because it makes sense. Dumbed down description of REST style: a) you have resource ("noun"), which is identified by URI b) you manipulate that noun with specific request ("verb") to that URI So GET request to http://example.com/project/1/tasks/ will get a list of tasks for the project. POST request to the same http://example.com/project/1/tasks/ will create the new topic. Let''s say its id is 47. PUT request to http://example.com/project/1/tasks/47 will update the new task. DELETE to the same URI will delete task. Even better, by using same URI but different Accept headers: you can get diferent representations (hence the "R"), of the same resource. Same GET request, same http://example.com/project/1/tasks/ URI, but different Accept headers will let you get list of tasks in html, xml, json, etc. That applies to POST and PUT too. That means, that having single piece of information: URI, you already can manipulate that resource. You get intuitive and consistent interface. Now let''s take http://example.com/HouseRenovation/GetBuildingPermit. How do you list all permits? How do you get a list in json? How do you update or delete it? You don''t know, unless you have the list off all URIs you must use for that. If it was REST having only URI you can do a lot.> If this isn''t a REST matter then why, oh why does it appear in just > about every explanation of REST I find on the net?<...> It is REST matter in a sense. As I told earlier, RESTful URI identifies resource, a "noun", which you can then manipulate using standard "verbs" like HTTP''s GET, POST, PUT, DELETE. http://example.com/HouseRenovation/GetBuildingPermit does not identify any noun, it looks more like method name "verb" (which is not standard). This may be nice URI, but it is not very RESTful. Regards, Rimantas -- http://rimantas.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 -~----------~----~----~----~------~----~------~--~---
Anton, go back to what I said earlier. REST is about thinking of your system in terms of resources. Rails REST by convention uses that URL scheme for nested resources, but it''s not required. Until you understand resources, you''re probably not going to see a big deal about REST. I''ll try to blog about this over the weekend, see if I can get you closer to enlightenment. Sent from my iPhone On Jan 5, 2008, at 7:06 AM, Anton J Aylward <aja-XdPx9462FWc@public.gmane.org> wrote:> > Michael D. Ivey said the following on 05/01/08 01:14 AM: >> On Jan 4, 2008, at 11:24 PM, Anton J Aylward wrote: >>> As far as I can make out the nested REST end up with URLs like >>> >>> http://example.com/project/1/task/47 >>> >>> I come from the world of Wikis and that makes no sense to me.The >>> ''user >>> friendly version would >>> >>> http://example.com/HouseRenovation/GetBuildingPermit >> >> There''s absolutely nothing incompatible with this. REST is not about >> how you structure URLs, it''s about how you structure your >> application. > > Which is what I''ve been saying. I can do it without REST therefore it > has nothing to do with REST. > > But why, oh, why, oh why do all the examples of nested REST go on > about > structuring URLs like that? > > Go back and look at Ryan Bigg''s excellent and comprehensive > explanation > in this thread. > There it is: > > /forums/1/topics/1 <- showing a single topic > > If this isn''t a REST matter then why, oh why does it appear in just > about every explanation of REST I find on the net? > -- > Wisdom is earned through bitter experience. > Idiocy comes easily. > > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Thank you all! A few more steps were definitely taken during this whole discussion. . .getting closer. Bala, thanks for the screencast, keep it up! Michael, look forward to that blog post. Hope you''ll post the link here! (web page link in profile doesn''t take me there). H On Jan 5, 10:44 am, "Michael D. Ivey" <michael.i...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Anton, go back to what I said earlier. REST is about thinking of your > system in terms of resources. Rails REST by convention uses that URL > scheme for nested resources, but it''s not required. Until you > understand resources, you''re probably not going to see a big deal > about REST. > > I''ll try to blog about this over the weekend, see if I can get you > closer to enlightenment. > > Sent from my iPhone > > On Jan 5, 2008, at 7:06 AM, Anton J Aylward <a...-XdPx9462FWc@public.gmane.org> wrote: > > > > > Michael D. Ivey said the following on 05/01/08 01:14 AM: > >> On Jan 4, 2008, at 11:24 PM, Anton J Aylward wrote: > >>> As far as I can make out the nested REST end up with URLs like > > >>> http://example.com/project/1/task/47 > > >>> I come from the world of Wikis and that makes no sense to me.The > >>> ''user > >>> friendly version would > > >>> http://example.com/HouseRenovation/GetBuildingPermit > > >> There''s absolutely nothing incompatible with this. REST is not about > >> how you structure URLs, it''s about how you structure your > >> application. > > > Which is what I''ve been saying. I can do it without REST therefore it > > has nothing to do with REST. > > > But why, oh, why, oh why do all the examples of nested REST go on > > about > > structuring URLs like that? > > > Go back and look at Ryan Bigg''s excellent and comprehensive > > explanation > > in this thread. > > There it is: > > > /forums/1/topics/1 <- showing a single topic > > > If this isn''t a REST matter then why, oh why does it appear in just > > about every explanation of REST I find on the net? > > -- > > Wisdom is earned through bitter experience. > > Idiocy comes easily.--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Michael D. Ivey said the following on 05/01/08 01:14 AM:>> I come from the world of Wikis and that makes no sense to me.The ''user >> friendly version would >> http://example.com/HouseRenovation/GetBuildingPermit > There''s absolutely nothing incompatible with this. REST is not about > how you structure URLs, it''s about how you structure your application.I''m not sure I completely agree with this. The above URI feels very much like a Remote Procedure Call (RPC) type of request. If the URI in question was based on REST conventions then why is the verb embedded in the URI? I mean why is it GetBuildingPermit? How many of these remote procedures exist, and how could I ever infer how to access these resources? I''m talking about a client accessing the resources without internal knowledge of the API? SOAP for example makes no attempt at standardizing the API, but rather they attempt to expose the internal API through the WSDL document. In order for a client to use the URI in question something similar must be provided to the consumer of the service. So no, I don''t agree that this URI is compatible with REST. It simply isn''t, in my opinion. Now I''m not saying there is anything wrong with using this type of URI. Just don''t try to call it RESTful (at least not in the pure form). Contrast that with:>> http://example.com/project/1/task/47In this example a client who understands REST would not need to know the internal details of the API in order to perform basic CRUD operations. This URI clearly references one specific resource, a specific task of a specific project. Knowing that this is based on a RESTful API, the consumer would know that they can POST them, GET them, PUT them or DELETE them. They don''t need to know the specific RPC calls for manipulating them. Enter ActiveResouce. They can now have a client that can use these resources directly, without the use of complicated API exposure tools like WSDL. On Jan 5, 12:52 pm, Hardy <hard...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Thank you all! A few more steps were definitely taken during this > whole discussion. . .getting closer. > > Bala, thanks for the screencast, keep it up! > > Michael, look forward to that blog post. Hope you''ll post the link > here! (web page link in profile doesn''t take me there). > > H > > On Jan 5, 10:44 am, "Michael D. Ivey" <michael.i...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > Anton, go back to what I said earlier. REST is about thinking of your > > system in terms of resources. Rails REST by convention uses that URL > > scheme for nested resources, but it''s not required. Until you > > understand resources, you''re probably not going to see a big deal > > about REST. > > > I''ll try to blog about this over the weekend, see if I can get you > > closer to enlightenment. > > > Sent from my iPhone > > > On Jan 5, 2008, at 7:06 AM, Anton J Aylward <a...-XdPx9462FWc@public.gmane.org> wrote: > > > > Michael D. Ivey said the following on 05/01/08 01:14 AM: > > >> On Jan 4, 2008, at 11:24 PM, Anton J Aylward wrote: > > >>> As far as I can make out the nested REST end up with URLs like > > > >>> http://example.com/project/1/task/47 > > > >>> I come from the world of Wikis and that makes no sense to me.The > > >>> ''user > > >>> friendly version would > > > >>> http://example.com/HouseRenovation/GetBuildingPermit > > > >> There''s absolutely nothing incompatible with this. REST is not about > > >> how you structure URLs, it''s about how you structure your > > >> application. > > > > Which is what I''ve been saying. I can do it without REST therefore it > > > has nothing to do with REST. > > > > But why, oh, why, oh why do all the examples of nested REST go on > > > about > > > structuring URLs like that? > > > > Go back and look at Ryan Bigg''s excellent and comprehensive > > > explanation > > > in this thread. > > > There it is: > > > > /forums/1/topics/1 <- showing a single topic > > > > If this isn''t a REST matter then why, oh why does it appear in just > > > about every explanation of REST I find on the net? > > > -- > > > Wisdom is earned through bitter experience. > > > Idiocy comes easily.--~--~---------~--~----~------------~-------~--~----~ 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@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Jan 6, 2008 2:54 AM, Robert Walker <rwalker348-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Michael D. Ivey said the following on 05/01/08 01:14 AM: > > >> I come from the world of Wikis and that makes no sense to me.The ''user > >> friendly version would > >> http://example.com/HouseRenovation/GetBuildingPermit > > There''s absolutely nothing incompatible with this. REST is not about > > how you structure URLs, it''s about how you structure your application. > > I''m not sure I completely agree with this. The above URI feels very > much like a Remote Procedure Call (RPC) type of request. > > If the URI in question was based on REST conventions then why is the > verb embedded in the URI? I mean why is it GetBuildingPermit?Good, question, but get here might actually not be a verb in the "API", perhaps this refers to a resource (say a page which describes how to apply for a building permit from the local government) which is part of or related to another resource called HouseRenovation.> How many > of these remote procedures exist, and how could I ever infer how to > access these resources? I''m talking about a client accessing the > resources without internal knowledge of the API? SOAP for example > makes no attempt at standardizing the API, but rather they attempt to > expose the internal API through the WSDL document. In order for a > client to use the URI in question something similar must be provided > to the consumer of the service. > > So no, I don''t agree that this URI is compatible with REST. It simply > isn''t, in my opinion.Well it might or might not be depending on whether GetBuildingPermit in this case is the name of a resource, or actually does embed get as part of the API. -- Rick DeNatale My blog on Ruby http://talklikeaduck.denhaven2.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 -~----------~----~----~----~------~----~------~--~---
On Jan 6, 2008, at 1:54 AM, Robert Walker wrote:>>> I come from the world of Wikis and that makes no sense to me.The >>> ''user >>> friendly version would >>> http://example.com/HouseRenovation/GetBuildingPermit >> There''s absolutely nothing incompatible with this. REST is not about >> how you structure URLs, it''s about how you structure your >> application. > > I''m not sure I completely agree with this. The above URI feels very > much like a Remote Procedure Call (RPC) type of request.I read it that "GetBuildingPermit" was the name of a Wiki page inside a ''web'' named "HouseRenovation". So it''s 2 nouns, one inside the other. If I mis-interpreted that, I agree with everything you said, not quoted here. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Robert Walker said the following on 06/01/08 02:54 AM:> Michael D. Ivey said the following on 05/01/08 01:14 AM: > >>> I come from the world of Wikis and that makes no sense to me.The ''user >>> friendly version would >>> http://example.com/HouseRenovation/GetBuildingPermit >> There''s absolutely nothing incompatible with this. REST is not about >> how you structure URLs, it''s about how you structure your application. > > I''m not sure I completely agree with this. The above URI feels very > much like a Remote Procedure Call (RPC) type of request. > > If the URI in question was based on REST conventions then why is the > verb embedded in the URI? I mean why is it GetBuildingPermit? How many` NO!! I picked a bad example. Its not a ''get", its the name of an item, like on a to-do-list or on a work breakdown structure. In some municipalities you need obtain a building permit in order to do renovations. There is no Http-GET being referred to. A project has a number of stages: obtain financing, obtain material, obtain manpower. and one of the thing to obtain my be a building permit. I''m sorry that this irrelevancy has come up. My point was that a lot of the literature and example for Rails, all the way back to AWDWR use find-by_id and so things get hung up on numbers. Real people will talk of things like ''the house renovation project''. The work breakdown structure gets discussed similarly: "has the floor been sanded and re-varnished?" http://example.com/HouseRenovation/SandAndRevarnishFloor What I was getting at is that the ''nested route'' need not declare the controller: http://example.com/project/HouseRenovation/step/SandAndRevarnishFloor -- "The greatest composer does not sit down to work because he is inspired, but becomes inspired because he is working." -- Ernest Newman --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Rick DeNatale said the following on 06/01/08 08:40 AM:> On Jan 6, 2008 2:54 AM, Robert Walker <rwalker348-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> Michael D. Ivey said the following on 05/01/08 01:14 AM: >> >>>> I come from the world of Wikis and that makes no sense to me.The ''user >>>> friendly version would >>>> http://example.com/HouseRenovation/GetBuildingPermit >>> There''s absolutely nothing incompatible with this. REST is not about >>> how you structure URLs, it''s about how you structure your application. >> I''m not sure I completely agree with this. The above URI feels very >> much like a Remote Procedure Call (RPC) type of request. >> >> If the URI in question was based on REST conventions then why is the >> verb embedded in the URI? I mean why is it GetBuildingPermit? > > Good, question, but get here might actually not be a verb in the > "API", perhaps this refers to a resource (say a page which describes > how to apply for a building permit from the local government) which is > part of or related to another resource called HouseRenovation.Right. You''ve just described a step in the renovation. "We need a building permit for the house renovation project." -- It is an error to imagine that evolution signifies a constant tendency to increased perfection. That process undoubtedly involves a constant remodelling of the organism in adaptation to new conditions; but it depends on the nature of those conditions whether the directions of the modifications effected shall be upward or downward. Thomas H. Huxley --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Michael D. Ivey said the following on 06/01/08 11:02 AM:> On Jan 6, 2008, at 1:54 AM, Robert Walker wrote: >>>> I come from the world of Wikis and that makes no sense to me.The >>>> ''user >>>> friendly version would >>>> http://example.com/HouseRenovation/GetBuildingPermit >>> There''s absolutely nothing incompatible with this. REST is not about >>> how you structure URLs, it''s about how you structure your >>> application. >> I''m not sure I completely agree with this. The above URI feels very >> much like a Remote Procedure Call (RPC) type of request. > > I read it that "GetBuildingPermit" was the name of a Wiki page inside > a ''web'' named "HouseRenovation". So it''s 2 nouns, one inside the other.Thank you! Dead Right. The point I was trying to make is that this need not be written http://example.com/web/HouseRenovation/topic/GetBuildingPermit ^^^ ^^^^^ I make this point because all the examples I''ve given of ''nested resources'' have the names of the controllers in the URL. If putting the names of the controllers in the URL is not a REST thing, then why do the people proposing REST keep on doing it? Its like they''re obsessed with it. Ever last example I''ve see, in this thread and on the ''Net, has it. -- If you can''t describe what you are doing as a process, you don''t know what you''re doing. -- W. Edwards Deming --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
> If putting the names of the controllers in the URL is not a REST thing, > then why do the people proposing REST keep on doing it? Its like > they''re obsessed with it. Ever last example I''ve see, in this thread > and on the ''Net, has it.REST thing is URIs pointing at resources. It is not about the "names of controllers" it is about resources, "nouns". Regards, Rimantas -- http://rimantas.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 -~----------~----~----~----~------~----~------~--~---
On Sunday 06 January 2008, Anton J Aylward wrote:> The point I was trying to make is that this need not be written > > http://example.com/web/HouseRenovation/topic/GetBuildingPermit > ^^^ ^^^^^ > > I make this point because all the examples I''ve given of ''nested > resources'' have the names of the controllers in the URL. > > If putting the names of the controllers in the URL is not a REST > thing, then why do the people proposing REST keep on doing it? Its > like they''re obsessed with it. Ever last example I''ve see, in this > thread and on the ''Net, has it.Because it is easy, you can get it automatically, and often it fits. In Rails it''s what map.resources gives you for free. If it doesn''t suit your needs, well, feel free to customize all the way you want. It''ll be a bit more work, but can be RESTful all the same. For example, I''m using some fairly generic code to audit changes to resources. Display of audit logs is handled by a single controller across all resources and I can get logs for everything, a particular resource type, or a single resource; all of this in various formats. Rails routing doesn''t provide the URLs I want automatically, of course, but I can easily persuade it to do my bidding map.with_options(:controller => ''audits'', :action => ''show'') do |a| a.audits ''/audits'', :format => ''html'' a.audits ''/audits.:format'' a.audits '':resources/audits'', :format => ''html'' a.audits '':resources/audits.:format'' a.audits '':resources/:id/audits.:format'' a.audits '':resources/:id/audits'', :format => ''html'' end Michael -- Michael Schuerig mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org http://www.schuerig.de/michael/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
On Jan 6, 2008, at 12:26 PM, Anton J Aylward wrote:> The point I was trying to make is that this need not be written > > http://example.com/web/HouseRenovation/topic/GetBuildingPermit > ^^^ ^^^^^ > > I make this point because all the examples I''ve given of ''nested > resources'' have the names of the controllers in the URL. > > If putting the names of the controllers in the URL is not a REST > thing, > then why do the people proposing REST keep on doing it? Its like > they''re obsessed with it. Ever last example I''ve see, in this thread > and on the ''Net, has it.Because that is the default way to do it in Rails. Most people use the defaults. Adding custom routes doesn''t break REST, though. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Michael Schuerig said the following on 06/01/08 01:44 PM:> On Sunday 06 January 2008, Anton J Aylward wrote: >> The point I was trying to make is that this need not be written >> >> http://example.com/web/HouseRenovation/topic/GetBuildingPermit >> ^^^ ^^^^^ >> >> I make this point because all the examples I''ve given of ''nested >> resources'' have the names of the controllers in the URL. >> >> If putting the names of the controllers in the URL is not a REST >> thing, then why do the people proposing REST keep on doing it? Its >> like they''re obsessed with it. Ever last example I''ve see, in this >> thread and on the ''Net, has it. > > Because it is easy, you can get it automatically, and often it fits. In > Rails it''s what map.resources gives you for free. If it doesn''t suit > your needs, well, feel free to customize all the way you want. It''ll be > a bit more work, but can be RESTful all the same. > > For example, I''m using some fairly generic code to audit changes to > resources. Display of audit logs is handled by a single controller > across all resources and I can get logs for everything, a particular > resource type, or a single resource; all of this in various formats. > Rails routing doesn''t provide the URLs I want automatically, of course, > but I can easily persuade it to do my bidding > > map.with_options(:controller => ''audits'', :action => ''show'') do |a| > a.audits ''/audits'', :format => ''html'' > a.audits ''/audits.:format'' > a.audits '':resources/audits'', :format => ''html'' > a.audits '':resources/audits.:format'' > a.audits '':resources/:id/audits.:format'' > a.audits '':resources/:id/audits'', :format => ''html'' > endHave you deliberately chosen a bad example? You''ve still got the name of the controller in each URL. Which is what I''m trying to address in this part of the thread. And yes, Understand "its a design decision" you made. But how could you have made it differently? How would it for my wiki look, then? Not much different from what I have for non REST, I should imagine. Which gets back to my original concern about the HOW. Or if it doesn''t look any different and the ''wiki'' is the resource, not the tables that are used, then isn''t whatever I write, by definition, RESTful? -- "Our vision is to speed up time, eventually eliminating it." -- Alex Schure --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Rimantas Liubertas said the following on 06/01/08 01:42 PM:>> If putting the names of the controllers in the URL is not a REST thing, >> then why do the people proposing REST keep on doing it? Its like >> they''re obsessed with it. Ever last example I''ve see, in this thread >> and on the ''Net, has it. > > REST thing is URIs pointing at resources. It is not about the > "names of controllers" it is about resources, "nouns".Then you''re just reinforcing my question. Why do all the examples put the names of the controllers in the URL? I can understand it as a ''teaching example'', to emphasize the nesting structure by labelling it, but are the ''labels'' mandatory? Can''t we move past the ''learning examples''? ARE the labels mandatory? As I say, why does every example keep doing it? -- "Challenge everything you do. Expand your thinking. Refocus your efforts. Rededicate yourself to your future." -- Patricia Fripp --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
On Jan 6, 2008, at 2:24 PM, Anton J Aylward wrote:> Why do all the examples put the names of the controllers in the URL? > > I can understand it as a ''teaching example'', to emphasize the nesting > structure by labelling it, but are the ''labels'' mandatory? Can''t we > move past the ''learning examples''? ARE the labels mandatory? > > As I say, why does every example keep doing it?Asked and answered: it''s the way Rails does it by default. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
On Sunday 06 January 2008, Anton J Aylward wrote:> Michael Schuerig said the following on 06/01/08 01:44 PM: > > On Sunday 06 January 2008, Anton J Aylward wrote: > >> The point I was trying to make is that this need not be written > >> > >> http://example.com/web/HouseRenovation/topic/GetBuildingPermit > >> ^^^ ^^^^^ > >> > >> I make this point because all the examples I''ve given of ''nested > >> resources'' have the names of the controllers in the URL. > >> > >> If putting the names of the controllers in the URL is not a REST > >> thing, then why do the people proposing REST keep on doing it? > >> Its like they''re obsessed with it. Ever last example I''ve see, in > >> this thread and on the ''Net, has it. > > > > Because it is easy, you can get it automatically, and often it > > fits. In Rails it''s what map.resources gives you for free. If it > > doesn''t suit your needs, well, feel free to customize all the way > > you want. It''ll be a bit more work, but can be RESTful all the > > same. > > > > For example, I''m using some fairly generic code to audit changes to > > resources. Display of audit logs is handled by a single controller > > across all resources and I can get logs for everything, a > > particular resource type, or a single resource; all of this in > > various formats. Rails routing doesn''t provide the URLs I want > > automatically, of course, but I can easily persuade it to do my > > bidding > > > > map.with_options(:controller => ''audits'', :action => ''show'') do > > |a| a.audits ''/audits'', :format => ''html'' > > a.audits ''/audits.:format'' > > a.audits '':resources/audits'', :format => ''html'' > > a.audits '':resources/audits.:format'' > > a.audits '':resources/:id/audits.:format'' > > a.audits '':resources/:id/audits'', :format => ''html'' > > end > > Have you deliberately chosen a bad example? > You''ve still got the name of the controller in each URL. > Which is what I''m trying to address in this part of the thread.Feel free to rename the controller to ''something_else_entirely''. I don''t know why you would do that, though, because it comes quite naturally that a specific resource or a specific representation format is handled by a single controller.> And yes, Understand "its a design decision" you made. But how could > you have made it differently?See above, I could easily have used a special controller on each of the routes above and I could have given those controllers some weird names, but why should I? Michael -- Michael Schuerig mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org http://www.schuerig.de/michael/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
> Then you''re just reinforcing my question. > Why do all the examples put the names of the controllers in the URL?If you talking about the default routes provided by Rails then you''re completely missing something. It''s not the names of the controllers that are in the URI, they are the names of the resources. The Rails convention happens to name the controllers after the resource names. This works well because of the same reasons that naming ActiveRecord attributes after their column in the database makes things much easier. This removes the need for complex object relational mapping configuration files (convention over configuration). What Rails is attempting to do with REST is similar. Just like with ActiveRecord, if you decide to develop you own conventions then it''s just going to make your life, and the life of consumer of your service, more difficult. There''s not anything particularly wrong with that, it comes down to choice. Do it the Rails way and it''s easy and well understood. Do it your way and put in the extra effort to work around the conventions. Every decision that remains with the developer adds complexity to the system. When those decisions are made for you by the framework it serves to simplify your design. That''s the goal of the REST implementation in Rails. Whether they have achieved that goal is another story altogether. On Jan 6, 3:24 pm, Anton J Aylward <a...-XdPx9462FWc@public.gmane.org> wrote:> Rimantas Liubertas said the following on 06/01/08 01:42 PM: > > >> If putting the names of the controllers in the URL is not a REST thing, > >> then why do the people proposing REST keep on doing it? Its like > >> they''re obsessed with it. Ever last example I''ve see, in this thread > >> and on the ''Net, has it. > > > REST thing is URIs pointing at resources. It is not about the > > "names of controllers" it is about resources, "nouns". > > Then you''re just reinforcing my question. > Why do all the examples put the names of the controllers in the URL? > > I can understand it as a ''teaching example'', to emphasize the nesting > structure by labelling it, but are the ''labels'' mandatory? Can''t we > move past the ''learning examples''? ARE the labels mandatory? > > As I say, why does every example keep doing it? > > -- > "Challenge everything you do. Expand your thinking. Refocus your > efforts. Rededicate yourself to your future." -- Patricia Fripp--~--~---------~--~----~------------~-------~--~----~ 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@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Michael D. Ivey said the following on 06/01/08 03:33 PM:> On Jan 6, 2008, at 2:24 PM, Anton J Aylward wrote: >> Why do all the examples put the names of the controllers in the URL? >> >> I can understand it as a ''teaching example'', to emphasize the nesting >> structure by labelling it, but are the ''labels'' mandatory? Can''t we >> move past the ''learning examples''? ARE the labels mandatory? >> >> As I say, why does every example keep doing it? > > Asked and answered: it''s the way Rails does it by default.OK, not back up to the other questions? It may be default but its no mandatory? Can you take one of those ''learning examples'' and show it without the ''labels''? -- Give a man a fish, and you''ll feed him for a day. Give him a religion, and he''ll starve to death while praying for a fish. --Timothy Jones --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Robert Walker said the following on 06/01/08 04:50 PM:>> Then you''re just reinforcing my question. >> Why do all the examples put the names of the controllers in the URL? > > If you talking about the default routes provided by Rails then you''re > completely missing something. It''s not the names of the controllers > that are in the URI, they are the names of the resources. The Rails > convention happens to name the controllers after the resource names. > This works well because of the same reasons that naming ActiveRecord > attributes after their column in the database makes things much > easier. This removes the need for complex object relational mapping > configuration files (convention over configuration).True, but it neither addresses my question nor helps me figure out how I can make use of this in my applications. Back to my "HOW" set of questions. And as a note, some of the examples have had quote involved routes files and generated routes for all the extra methods. Which really is ''configuration''. -- We''ll give you your money back if not satisfied, but we do suspect that we will be quite satisfied with your money. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Michael Schuerig said the following on 06/01/08 04:39 PM:> On Sunday 06 January 2008, Anton J Aylward wrote: >> Michael Schuerig said the following on 06/01/08 01:44 PM: >>> On Sunday 06 January 2008, Anton J Aylward wrote: >>>> The point I was trying to make is that this need not be written >>>> >>>> http://example.com/web/HouseRenovation/topic/GetBuildingPermit >>>> ^^^ ^^^^^ >>>> >>>> I make this point because all the examples I''ve given of ''nested >>>> resources'' have the names of the controllers in the URL. >>>> >>>> If putting the names of the controllers in the URL is not a REST >>>> thing, then why do the people proposing REST keep on doing it? >>>> Its like they''re obsessed with it. Ever last example I''ve see, in >>>> this thread and on the ''Net, has it. >>> Because it is easy, you can get it automatically, and often it >>> fits. In Rails it''s what map.resources gives you for free. If it >>> doesn''t suit your needs, well, feel free to customize all the way >>> you want. It''ll be a bit more work, but can be RESTful all the >>> same. >>> >>> For example, I''m using some fairly generic code to audit changes to >>> resources. Display of audit logs is handled by a single controller >>> across all resources and I can get logs for everything, a >>> particular resource type, or a single resource; all of this in >>> various formats. Rails routing doesn''t provide the URLs I want >>> automatically, of course, but I can easily persuade it to do my >>> bidding >>> >>> map.with_options(:controller => ''audits'', :action => ''show'') do >>> |a| a.audits ''/audits'', :format => ''html'' >>> a.audits ''/audits.:format'' >>> a.audits '':resources/audits'', :format => ''html'' >>> a.audits '':resources/audits.:format'' >>> a.audits '':resources/:id/audits.:format'' >>> a.audits '':resources/:id/audits'', :format => ''html'' >>> end >> Have you deliberately chosen a bad example? >> You''ve still got the name of the controller in each URL. >> Which is what I''m trying to address in this part of the thread. > > Feel free to rename the controller to ''something_else_entirely''. I don''t > know why you would do that, though, because it comes quite naturally > that a specific resource or a specific representation format is handled > by a single controller. > >> And yes, Understand "its a design decision" you made. But how could >> you have made it differently? > > See above, I could easily have used a special controller on each of the > routes above and I could have given those controllers some weird names, > but why should I???? I''m not asking for ''weird names''. I''m not asking to rename the controller. Go back to my ''projects'' example. http://example.com/web/HouseRenovation/topic/SandAndvarnishFloor vs http://example.com/HouseRenovation/SandAndvarnishFloor I''m asking WHY do you keep on putting that FIXED STRING that identifies the controller (even indirectly via the ''with options''). As I say, its chronic for nested controllers/resources. I can understand it for the operations like /login and /signup that are ''out of band'' of the normal flow of the application (though I know many CAs who believe that auditing is part of the normal flow of operations of a business, and a lot of recent legislation seems to support that view), but why do people keep putting it into the normal flow? I''m asking if its mandatory. If its not mandatory then why do it? Please don''t say ''its easier'' or ''less work'' or something along those lines. I''ve experimented with (non REST) routing in my wiki and the difference between http://example.com/wiki/System/Homepage and http://example.com/System/Homepage is just a few characters in routes.rb. Its about the same ''work'' either way. And I do even have a way to make the ''login'' and ''signup'' "in band" when I choose to implement it. How can I tell that you''re no making a ''virtue out of a necessity''? -- "To be conscious of one''s ignorance is the beginning of wisdom". -- Sri Ram --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
On Sunday 06 January 2008, Anton J Aylward wrote:> I''m asking WHY do you keep on putting that FIXED STRING that > identifies the controller (even indirectly via the ''with options''). > As I say, its chronic for nested controllers/resources.I''m not sure I''m able to follow you. I need that fixed string, because in some way requests have to be mapped to controllers. If I use map.resources, Rails does the mapping behind the scenes; if I use plain map.connect, I have to do the mapping myself.> http://example.com/web/HouseRenovation/topic/SandAndvarnishFloor > vs > http://example.com/HouseRenovation/SandAndvarnishFloormap.connect ''/*categories'', :controller => ''products'', :action => ''index'' class ProductsController < ActionController::Base def index @items = Product.find_by_categories(params[categories]) ... end end class Product < ActiveRecord::Base def self.find_by_categories(categories) # find all products assigned to the most specific category end end Michael -- Michael Schuerig mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org http://www.schuerig.de/michael/ --~--~---------~--~----~------------~-------~--~----~ 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@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> I'm not asking for 'weird names'. I'm not asking to rename the controller. > Go back to my 'projects' example. > > http://example.com/web/HouseRenovation/topic/SandAndvarnishFloor > vs > http://example.com/HouseRenovation/SandAndvarnishFloor > > I'm asking WHY do you keep on putting that FIXED STRING that identifies > the controller (even indirectly via the 'with options'). As I say, its > chronic for nested controllers/resources.<...> I am about to give up :( If there is fixed string it usually identifies resource (which is core for REST), but of course it may be that controller has the same name. It's controller named after resource not the other way around, so you have names of the resources in your URI and you may have controllers with the same names. Let's take another bad example blog. You may have: http://blog.example.com/posts/ -> this way you can get list of resources, blog postings. http://blog.exampe.com/posts/1 -> there you identify single resource, a blog post. You may choose different way to go, let's say http://blog.example.com/posts/the-first-post or even http://blog.example.com/the-first-post it doesn't really matter, except that you get the first for free and another options will require some additional work. Now, there come comments. http://blog.example.com/posts/1/comments - a list of comments for the current entry. You may as well have http://blog.example.com/posts/the-first-post/comments or http://blog.example.com/the-first-post/comments/ Going down the nested resources road you will have http://blog.example.com/posts/1/comments/2 http://blog.example.com/posts/the-first-post/comments/2 http://blog.example.com/the-first-post/comments/2 If you want you can event get rid of /comments/ and implement http://blog.example.com/post-id-or-name/comment-id identification schema it does not really matter. As for http://blog.example.com/posts/1/comments/2 it is not putting the names of the controllers into URI, it's still about identification of resources: /posts/ identifies collection of posts /posts/1 identifies specific post from that collection /posts/1/comments identifies collection of comments for that specific post /posts/1/comments/2 identifies specific comment. Of course, you can implement your own identification schema, making all more obscure, but it can soon make life more difficult. This may make sense if your site provides quite limited set of resources. You can sure map your blog posts and comments to http://blog.example.com/post-id-or-name/comment-id but then you will have to think, how to do with categories, tags, etc. http://blog.example.com/rest-way - is that post, or is that name of the category? http://blog.example.com/categories/rest-way now it is clear. Basicaly having full path to resource in URI makes life easier. Just don't think about it as about controllers. Think resources. Regards, Rimantas -- http://rimantas.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@googlegroups.com To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Rimantas Liubertas said the following on 06/01/08 07:09 PM:> [snip - clarification of resoruce vs controller acceped and skipped]> If you want you can event get rid of /comments/ and implement > http://blog.example.com/post-id-or-name/comment-id identification schema – > it does not really matter.Yes, "I want". How? -- Some day, on the corporate balance sheet, there will be an entry which reads, "Information"; for in most cases the information is more valuable than the hardware which processes it. - Adm. Grace Murray Hopper, USN Ret. --~--~---------~--~----~------------~-------~--~----~ 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@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Jan 6, 2008, at 3:59 PM, Anton J Aylward wrote:> Can you take one of those ''learning examples'' and show it without the > ''labels''?map.resources :webs do |webs| webs.resources :pages end map.page "/:web_name/:page_name", :controller => "pages", :action => "show" However, most apps DON''T have just one resource type. Most have lots of Things: users, accounts, places, pages, monkeys ... etc. So be sure to put your extra resource route last. Is that what you''re asking for? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Well, it''s /possible/, but you do get confusion. If you add this snippet to the top of routes.rb (There should be a better place to put it, but I was trying to do this quickly) module ActionController module Resources class Resource def path @path ||= "#{path_prefix}" # this is normally @path ||= "#{path_prefix}/#{plural}" end end end end If you then do a ''map.resources :projects'' you will get the full array of REST routes, (GET, POST, PUT, DELETE) linked up as appropriate. ''rake routes'' produces the following: projects GET / {:controller=>"projects", :action=>"index"} formatted_projects GET /.:format {:controller=>"projects", :action=>"index"} POST / {:controller=>"projects", :action=>"create"} POST /.:format {:controller=>"projects", :action=>"create"} new_project GET /new {:controller=>"projects", :action=>"new"} formatted_new_project GET /new.:format {:controller=>"projects", :action=>"new"} edit_project GET /:id/edit {:controller=>"projects", :action=>"edit"} formatted_edit_project GET /:id/edit.:format {:controller=>"projects", :action=>"edit"} project GET /:id {:controller=>"projects", :action=>"show"} formatted_project GET /:id.:format {:controller=>"projects", :action=>"show"} PUT /:id {:controller=>"projects", :action=>"update"} PUT /:id.:format {:controller=>"projects", :action=>"update"} DELETE /:id {:controller=>"projects", :action=>"destroy"} DELETE /:id.:format {:controller=>"projects", :action=>"destroy"} Which is as you wanted, routing-wise. Using def to_param self.name end In our project model means that the name is used instead of the id number for any generated links, and a similar change in the controller from ''find_by_id(params[:id])'' to ''find_by_name(params[:id])'' works similarly. Obviously all the project names should be unique, and in addition, you should disallow a project named ''new''. However, the problem comes when we decide that each project should have tasks. map.resources :projects, :has_many => :tasks I won''t post the full routing list, as it is rather long, but I will pull out two lines from it: ... project GET /:id {:controller=>"projects", :action=>"show"} ... project_tasks GET /:project_id {:controller=>"tasks", :action=>"index"} ... As you can see, the two routes, for two different resources (the project and it''s subsidiary tasks) are indentical. Rails has a ''first declared, first served'' policy for routing, so it''s impossible to get a list of all the tasks of a project. (Well, not impossible, but requires some thought to get around - see later) It''s also not REST, which is based around the idea of each url pointing to one (and only one) resource. That is actually the only conflict you get in the case of a project with many tasks, but if a project also has notes, then suddenly you''re also posting to the same place to create several seperate resources. And obviously, in addition to notes and tasks needing unique names within themselves, you can''t have a note and a task with the same name. (''name'' used here as a placeholder for whatever id parameter is used to find projects by) Of course, with more hacking of the Resources module, you could probably make it such that the controller name was used for the index action. So /projects gave you a list of all the projects /:project_name was an individual project /:project_name/tasks was all the tasks associated with a project /:project_name/:task_name was an individual task etc. Obviously, you''d need further constrains on allowed names to stop people using projects, tasks, etc. as names of projects or tasks, by accident or with malicious intent. Or if monkeying around in the actionpack source isn''t what you want, hook up all your routes manually in routes.rb. The full REST routing for a single resource is 14 routes, once you take into account the format and edit and new actions, but none of them are especially complicated to write. You start with something like map.projects ''/'', :controller => ''projects'', :action => ''index'', :conditions => { :method => :get } map.project ''/:id'', :controller => ''projects'', :action => ''show'', :conditions => { :method => :get } and so on, changing the action and condition as appropriate. So, that''s how you /can/ have URLs in the form you desire, but it is not a trivial task, at least without some thought on how you will handle such things as route generation and the overlaps in URLs I mentioned earlier. I hope this helps, however, Jonathan. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
namelessjon said the following on 07/01/08 05:56 AM:> [.. snip ..] > > If you then do a ''map.resources :projects'' you will get the full > array of REST routes, (GET, POST, PUT, DELETE) linked up as > appropriate. ''rake routes'' produces the following: > >Could you repost that formatted differently, please. It seems to have wrapped in a confusing manner. Thanks.> end > > In our project model means that the name is used instead of the id > number for any generated links,Which I strongly advocate for both security reasons (see other thread) and user intelligibility.> However, the problem comes when we decide that each project should > have tasks.I don''t see why its a problem. The reason I asked about this was that in my Wiki is a real short piece of routing. Two lines in a "map.with_options" wrapper.> map.resources :projects, :has_many => :tasks > > I won''t post the full routing list, as it is rather long, but I will > pull out two lines from it:Perhaps you could explain WHY it has to be long. As I said, my ''old'' way doesn''t make the routing long.> ... project GET /:id {:controller=>"projects", :action=>"show"} ... > project_tasks GET /:project_id {:controller=>"tasks", > :action=>"index"} ... > > As you can see, the two routes, for two different resources (the > project and it''s subsidiary tasks) are indentical. Rails has a > ''first declared, first served'' policy for routing, so it''s impossible > to get a list of all the tasks of a project.??? Only a problem if the spec requires that the UI has that. Things like generating html select lists can still be one ''internally''. If its not a requirement its not a problem, and for my design its not a requirement. Lists of topics in a web are handled differently since they have to have metadata, links and access control applied. Its a design difference. Yes, I''m making a ''virtue out of a necessity''.> (Well, not impossible, but requires some thought to get around - see > later) It''s also not REST, which is based around the idea of each url > pointing to one (and only one) resource.> That is actually the only conflict you get in the case of a project > with many tasks, but if a project also has notes, then suddenly > you''re also posting to the same place to create several seperate > resources. And obviously, in addition to notes and tasks needing > unique names within themselves, you can''t have a note and a task with > the same name. (''name'' used here as a placeholder for whatever id > parameter is used to find projects by)So the ''old way'' is superior for this class of problem. I can keep nesting it with not much effort. Heck, http://Webname/Topicname/edit from /:web/:topic/:action could equally well be http://Webname/Topicname?action=edit I''ve got a lot of flexibility.> Of course, with more hacking of the Resources module, you could > probably make it such that the controller name was used for the index > action. So /projects gave you a list of all the projects > /:project_name was an individual project /:project_name/tasks was all > the tasks associated with a project /:project_name/:task_name was an > individual task etc.Indeed: effectively taking out-of-band of the normal ''address space''. In effect, /login, /signup are out of band and its not that difficult to think of /web/:webname a being an administrative ''out of band'' interface. Some Wikis are obsessive about having EVERYTHING as a wiki page, login, signup, creating new webs, changing access control. Personally I see those as ''out of band'' of the working with the wiki pages. So for me, its not a problem. And slotting /web/:webname in as an admin function is a easy way for me to segue into using REST.> Obviously, you''d need further constrains on allowed names to stop > people using projects, tasks, etc. as names of projects or tasks, by > accident or with malicious intent.:-) I was just going to ask about that. :-) In my present setup I have :requirements => { :web => /[A-Z][a-z]+/, :topic => /([A-Z][a-z]+){2,}/, That is, the topic has to be a CamelWord. (that RE probably needs refinement in due course) and the web has only a leading uppercase. I also have :action => /[a-z][a-z_]{3,}/ for where its appropriate. Can these requirements be re-mapped?> Or if monkeying around in the actionpack source isn''t what you want,At my level of experience with it, it feels a bit daunting.> hook up all your routes manually in routes.rb. The full REST routing > for a single resource is 14 routes,OUCH!> once you take into account the > format and edit and new actions, but none of them are especially > complicated to write. You start with something like > > map.projects ''/'', :controller => ''projects'', :action => ''index'', > :conditions => { :method => :get } map.project ''/:id'', :controller => > ''projects'', :action => ''show'', :conditions => { :method => :get } and > so on, changing the action and condition as appropriate.ARRGH! Wrapping confusion! Again.> So, that''s how you /can/ have URLs in the form you desire, but it is > not a trivial task, at least without some thought on how you will > handle such things as route generation and the overlaps in URLs I > mentioned earlier.One of the benefits being touted for REST is that it makes things simpler. But what I''m seeing is that for what I''m doing it makes it more complicated.> I hope this helps, however, Jonathan.Yes. -- The way that can be followed is not the Way The truth that can be told is not the Truth --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
On Jan 7, 1:57 pm, Anton J Aylward <a...-XdPx9462FWc@public.gmane.org> wrote:> namelessjon said the following on 07/01/08 05:56 AM: > > > [.. snip ..] > > > If you then do a ''map.resources :projects'' you will get the full > > array of REST routes, (GET, POST, PUT, DELETE) linked up as > > appropriate. ''rake routes'' produces the following: > > Could you repost that formatted differently, please. > It seems to have wrapped in a confusing manner. > > Thanks. >There, a pastie should avoid the confusion and formatting: http://pastie.caboo.se/136143> > end > > > In our project model means that the name is used instead of the id > > number for any generated links, > > Which I strongly advocate for both security reasons (see other thread) > and user intelligibility.Yes, it does aid in the readability, and I generally do use ''name''- type URLs when I make applications, REST non-withstanding. The security aspect I am less sold on. Not, I should hasten to add that I think security is bad, just that in many cases, the resources/pages/ whatever you want to call them already have a publically avaiable indexes and so it''s rather trivial to iterate over all of them anyway.> > > However, the problem comes when we decide that each project should > > have tasks. > > I don''t see why its a problem. > The reason I asked about this was that in my Wiki is a real short piece > of routing. Two lines in a "map.with_options" wrapper. > > > map.resources :projects, :has_many => :tasks > > > I won''t post the full routing list, as it is rather long, but I will > > pull out two lines from it: > > Perhaps you could explain WHY it has to be long. > As I said, my ''old'' way doesn''t make the routing long.Well, it''s the REST that makes it so long (essentially) Or more specifically, connecting things such that the four HTTP verbs are mapped to appropriate URLs and Controller methods, e.g. GET matched to show, DELETE mapped to destroy, etc. If you used your old method, but still wanted to REST, then you would need a lot of "if request.post?" "if request.put?" "if request.get?" etc. in your controller methods. In a RESTful controller, you have a more complex routing and several small methods.> > > ... project GET /:id {:controller=>"projects", :action=>"show"} ... > > project_tasks GET /:project_id {:controller=>"tasks", > > :action=>"index"} ... > > > As you can see, the two routes, for two different resources (the > > project and it''s subsidiary tasks) are indentical. Rails has a > > ''first declared, first served'' policy for routing, so it''s impossible > > to get a list of all the tasks of a project. > > ??? > Only a problem if the spec requires that the UI has that. > Things like generating html select lists can still be one ''internally''. > If its not a requirement its not a problem, and for my design its not a > requirement. Lists of topics in a web are handled differently since > they have to have metadata, links and access control applied. Its a > design difference. > > Yes, I''m making a ''virtue out of a necessity''.Well, when I said ''impossible'' I was talking within the constraints of REST, at least as I understand it, rather than ''impossible in the grand scheme of things''. In REST, the project is not the list of its subtasks, they are separate entities, and so should be ''GETable'' separately, hence they should have individual URLs. [SNIP]> > Some Wikis are obsessive about having EVERYTHING as a wiki page, login, > signup, creating new webs, changing access control. Personally I see > those as ''out of band'' of the working with the wiki pages. So for me, > its not a problem. > > And slotting /web/:webname in as an admin function is a easy way for me > to segue into using REST.See the end of the email for comments on that, I orginally missed it up here.> > > Obviously, you''d need further constrains on allowed names to stop > > people using projects, tasks, etc. as names of projects or tasks, by > > accident or with malicious intent. > > :-) > I was just going to ask about that. :-) > > In my present setup I have > > :requirements => { > :web => /[A-Z][a-z]+/, > :topic => /([A-Z][a-z]+){2,}/, > > That is, the topic has to be a CamelWord. > (that RE probably needs refinement in due course) > and the web has only a leading uppercase. > I also have > > :action => /[a-z][a-z_]{3,}/ > > for where its appropriate. > > Can these requirements be re-mapped?Well, keeping them within the routing is probably a good thing, but you probably also want to add them as validations to the Web / Topic model With: def Topic < ActiveRecord::Base validates_format_of :name, :with => /([A-Z][a-z]+){2,}/ validates_uniqueness_of :name end Or similar, so that when people create invalid names, they can''t, rather than creating a page they subsequently can''t access.> > > Or if monkeying around in the actionpack source isn''t what you want, > > At my level of experience with it, it feels a bit daunting.That''s no excuse. ;) Looking for that routing code was the first time I really have tried hacking at the Rails source.> > > hook up all your routes manually in routes.rb. The full REST routing > > for a single resource is 14 routes, > > OUCH! > > ARRGH! Wrapping confusion! Again.I am most sorry about that. It seems that if you go over the line limit, it''s all treated as a paragraph and wrapped together. map.projects ''/'', :controller => ''projects'', :action => ''index'', :conditions => { :method => :get } map.project ''/:id'', :controller => ''projects'', :action => ''show'', :conditions => { :method => :get } and so on, changing the action and condition as appropriate. I should note here that it is actually 7 ''normal'' routes, and then 7 ''formatted'' routes, for providing xml, yaml, etc. representations of the data.> One of the benefits being touted for REST is that it makes things > simpler. But what I''m seeing is that for what I''m doing it makes it > more complicated.Well, it depends. It makes it simple to logically extract information from a collection of resources, nested or otherwise. It makes it simple represent data in a variety of ways. It does make it harder to have arbitrary URL schema, due to the nature of the system, and the need for everything to have a unique URL for performing operations on. So for a wiki with URL requirements such as yours, being non-RESTful probably makes more sense. Although, if you did still want to be RESTful, a RESTful backend, with the full and unambiguous, though perhaps wasteful, REST routing of "topics/:topic_id/pages/:page_id". This could be under an ''/api/'' namespace, or something of that nature. The public requests pages with the /:topic/:page/:action routing, but the forms all POST/PUT/DELETE to the appropriate REST controller. There would be the need for some small logic used to correctly find the page depending on which route was used, but it wouldn''t be complicated. Which, reading your email more closely up, you considered. Or just not use REST for this application. It isn''t for everything. Regards, Jonathan --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
namelessjon said the following on 07/01/08 11:16 AM:> On Jan 7, 1:57 pm, Anton J Aylward <a...-XdPx9462FWc@public.gmane.org> wrote: > ... >> > There, a pastie should avoid the confusion and formatting: > > http://pastie.caboo.se/136143Thank you. Much appreciated. That''s the rake output? What''s the input?>>> In our project model means that the name is used instead of the id >>> number for any generated links, >> Which I strongly advocate for both security reasons (see other thread) >> and user intelligibility. > > Yes, it does aid in the readability, and I generally do use ''name''- > type URLs when I make applications, REST non-withstanding. The > security aspect I am less sold on. Not, I should hasten to add that I > think security is bad, just that in many cases, the resources/pages/ > whatever you want to call them already have a publically avaiable > indexes and so it''s rather trivial to iterate over all of them > anyway.Which is why I "don''t do that, then".>>> However, the problem comes when we decide that each project should >>> have tasks. >> I don''t see why its a problem. >> The reason I asked about this was that in my Wiki is a real short piece >> of routing. Two lines in a "map.with_options" wrapper. >> >>> map.resources :projects, :has_many => :tasks >>> I won''t post the full routing list, as it is rather long, but I will >>> pull out two lines from it: >> Perhaps you could explain WHY it has to be long. >> As I said, my ''old'' way doesn''t make the routing long. > > Well, it''s the REST that makes it so long (essentially) > Or more specifically, connecting things such that the four HTTP verbs > are mapped to appropriate URLs and Controller methods, e.g. GET > matched to show, DELETE mapped to destroy, etc. > If you used your old method, but still wanted to REST, then you would > need a lot of "if request.post?" "if request.put?" "if request.get?" > etc. in your controller methods. > In a RESTful controller, you have a more complex routing and several > small methods.Thanks for clearing that up. So it''s about trade-offs.>>> ... project GET /:id {:controller=>"projects", :action=>"show"} ... >>> project_tasks GET /:project_id {:controller=>"tasks", >>> :action=>"index"} ... >>> As you can see, the two routes, for two different resources (the >>> project and it''s subsidiary tasks) are indentical. Rails has a >>> ''first declared, first served'' policy for routing, so it''s impossible >>> to get a list of all the tasks of a project. >> ??? >> Only a problem if the spec requires that the UI has that. >> Things like generating html select lists can still be one ''internally''. >> If its not a requirement its not a problem, and for my design its not a >> requirement. Lists of topics in a web are handled differently since >> they have to have metadata, links and access control applied. Its a >> design difference. >> >> Yes, I''m making a ''virtue out of a necessity''. > > Well, when I said ''impossible'' I was talking within the constraints of > REST, at least as I understand it, rather than ''impossible in the > grand scheme of things''. In REST, the project is not the list of its > subtasks, they are separate entities, and so should be ''GETable'' > separately, hence they should have individual URLs. > > > [SNIP] > >> Some Wikis are obsessive about having EVERYTHING as a wiki page, login, >> signup, creating new webs, changing access control. Personally I see >> those as ''out of band'' of the working with the wiki pages. So for me, >> its not a problem. >> >> And slotting /web/:webname in as an admin function is a easy way for me >> to segue into using REST. > > See the end of the email for comments on that, I orginally missed it > up here. > >>> Obviously, you''d need further constrains on allowed names to stop >>> people using projects, tasks, etc. as names of projects or tasks, by >>> accident or with malicious intent. >> :-) >> I was just going to ask about that. :-) >> >> In my present setup I have >> >> :requirements => { >> :web => /[A-Z][a-z]+/, >> :topic => /([A-Z][a-z]+){2,}/, >> >> That is, the topic has to be a CamelWord. >> (that RE probably needs refinement in due course) >> and the web has only a leading uppercase. >> I also have >> >> :action => /[a-z][a-z_]{3,}/ >> >> for where its appropriate. >> >> Can these requirements be re-mapped? > > Well, keeping them within the routing is probably a good thing, but > you probably also want to add them as validations to the Web / Topic > modelI told you I was paranoid. Guess what I do? The purpose of the routing is send it to the right controller & method. I could have just use *url and done all the work in the controller. I chose not to. Trade-offs.> With: > > def Topic < ActiveRecord::Base > > validates_format_of :name, :with => /([A-Z][a-z]+){2,}/ > > validates_uniqueness_of :name > > end > > Or similar, so that when people create invalid names, they can''t, > rather than creating a page they subsequently can''t access.Yes, that validates the creation. But validating the routing counts too, so that invalid URLs get routed: http://CamelName/Noncamelname http://nonCamelName/Noncamelname http://Noncamelname/nonname and they don''t even touch the controller. I see this as pushing error checking back as early in the process as possible.>>> Or if monkeying around in the actionpack source isn''t what you want, >> At my level of experience with it, it feels a bit daunting. > > That''s no excuse. ;)I don''t carry a 50mm machine gun for the same reason. Are you suggesting I should? :-) Let''s think what else I don''t think I''m inexperienced enough to be doing? Do you need brain surgery or an organ transplant?:-)> Looking for that routing code was the first time I really have tried > hacking at the Rails source.I''ll stick to OS and compilers :-)>>> hook up all your routes manually in routes.rb. The full REST routing >>> for a single resource is 14 routes, >> OUCH! >> >> ARRGH! Wrapping confusion! Again. > > I am most sorry about that. It seems that if you go over the line > limit, it''s all treated as a paragraph and wrapped together. > > map.projects ''/'', :controller => ''projects'', > :action => ''index'', :conditions => { :method => :get } > > map.project ''/:id'', :controller => ''projects'', > :action => ''show'', :conditions => { :method => :get } > > and so on, changing the action and condition as appropriate.Thanks you. I see now. Is there some equivalent to :requirements => { :web => /[A-Z][a-z]+/ } for this? That the id-as-name has to meet some pattern or other constraint? Side question: Do these "requirements" have to be REs ?> I should note here that it is actually 7 ''normal'' routes, and then 7 > ''formatted'' routes, for providing xml, yaml, etc. representations of > the data. > >> One of the benefits being touted for REST is that it makes things >> simpler. But what I''m seeing is that for what I''m doing it makes it >> more complicated. > > Well, it depends. > It makes it simple to logically extract information from a collection > of resources, nested or otherwise. > It makes it simple represent data in a variety of ways. > It does make it harder to have arbitrary URL schema, due to the nature > of the system, and the need for everything to have a unique URL for > performing operations on.Trade-offs :-/> So for a wiki with URL requirements such as yours, being non-RESTful > probably makes more sense. Although, if you did still want to be > RESTful, a RESTful backend, with the full and unambiguous, though > perhaps wasteful, REST routing of "topics/:topic_id/pages/:page_id". > This could be under an ''/api/'' namespace, or something of that > nature. The public requests pages with the /:topic/:page/:action > routing, but the forms all POST/PUT/DELETE to the appropriate REST > controller. There would be the need for some small logic used to > correctly find the page depending on which route was used, but it > wouldn''t be complicated.I''ll put that on the queue for a later revision.> Which, reading your email more closely up, you considered. > > Or just not use REST for this application. It isn''t for everything.You''ve been patient and helpful. I hope others have benefited from this thread. -- "The Singapore government isn''t interested in controlling information, but wants a gradual phase-in of services to protect ourselves. It''s not to control, but to protect the citizens of Singapore. In our society, you can state your views, but they have to be correct." - Ernie Hai, coordinator of the Singapore Government Internet Project --~--~---------~--~----~------------~-------~--~----~ 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 guys, I was rewatching the Railsconf 2006 keynote from David and its all about REST. He talks about the implementation of REST in combination with has_many :through. I think its a very good talk if you want to know more about REST. Even without the slides you can follow a long quite well. It gives a clear insight on how he was thinking at the time. Its up for grabs here. http://blog.scribestudio.com/pages/rails/ You want the David Heinemeier Hansson download. And do yourself a favor and watch Martin Fowler. Now don''t go hammer the server all at once :-) Regards. Peter Dierx http://www.railstation.eu/blog PS I will post this in ''REST Style'' and ''WHY Rest'' -- 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 -~----------~----~----~----~------~----~------~--~---
> Thank you. Much appreciated. > That''s the rake output? > What''s the input? >I was sure I said, but anyway That is the output of ''rake routes'' (which you will need to be using rails 2.0 to use - I think that''s the first gem it appeared in, anyway) when my routes.rb consisted of: map.resources :projects And I had done the bit of monkey patching I pasted into an earlier email. ( reproduced in this pastie for future reference, and syntax highlighting. http://pastie.caboo.se/136412 ). I would be grateful if someone more experienced with rails could suggest a better place to put this than the top of routes.rb [Massive snipping]> > > Well, keeping them within the routing is probably a good thing, but > > you probably also want to add them as validations to the Web / Topic > > model > > I told you I was paranoid. > Guess what I do? > > The purpose of the routing is send it to the right controller & method. > > I could have just use > > *url > > and done all the work in the controller. I chose not to. > Trade-offs. > > > With: > > > def Topic < ActiveRecord::Base > > > validates_format_of :name, :with => /([A-Z][a-z]+){2,}/ > > > validates_uniqueness_of :name > > > end > > > Or similar, so that when people create invalid names, they can''t, > > rather than creating a page they subsequently can''t access. > > Yes, that validates the creation. > But validating the routing counts too, so that invalid URLs get routed: > > http://CamelName/Noncamelname > http://nonCamelName/Noncamelname > http://Noncamelname/nonname > > and they don''t even touch the controller. > > I see this as pushing error checking back as early in the process as > possible.Oh, no. Sorry, I should have been more positive in my agreement/ endorsement, rather than ''is probably a good thing''. I fully agree, keeping them in the routing is a good thing, and catching the errors earlier rather than later is a good thing. Though I think that catching them later would allow you to be more specific with an error, should that be your desire. I was just pointing out the importance of also having some model validations, so that people couldn''t make pages they can''t access (and because of that, probably can''t delete).> > >>> Or if monkeying around in the actionpack source isn''t what you want, > >> At my level of experience with it, it feels a bit daunting. > > > That''s no excuse. ;) > > I don''t carry a 50mm machine gun for the same reason. > Are you suggesting I should? :-) > Let''s think what else I don''t think I''m inexperienced enough to be > doing? Do you need brain surgery or an organ transplant?:-) >Funny you should mention it, but ... no. ;) Though messing in the rails source is /probably/ less dangerous than brain surgery.> > Looking for that routing code was the first time I really have tried > > hacking at the Rails source. > > I''ll stick to OS and compilers :-) > >I think I will leave that to you. :-)> > >>> hook up all your routes manually in routes.rb. The full REST routing > >>> for a single resource is 14 routes, > >> OUCH! > > >> ARRGH! Wrapping confusion! Again. > > > I am most sorry about that. It seems that if you go over the line > > limit, it''s all treated as a paragraph and wrapped together. > > > map.projects ''/'', :controller => ''projects'', > > :action => ''index'', :conditions => { :method => :get } > > > map.project ''/:id'', :controller => ''projects'', > > :action => ''show'', :conditions => { :method => :get } > > > and so on, changing the action and condition as appropriate. > > Thanks you. I see now. > Is there some equivalent to > > :requirements => { :web => /[A-Z][a-z]+/ } > > for this? That the id-as-name has to meet some pattern or other > constraint? >Well, according to the docs, yes. It''s :requirements , the same as for normal routes. map.project ''/:id'', :controller => ''projects'', :action => ''show'', :conditions => { :method => :get }, :requirements => { :id => /[A-Z][a-z]+/ }> Side question: Do these "requirements" have to be REs ? >And, yes, they do. So far as I know, anyway. [--snip--]> > > Well, it depends. > > It makes it simple to logically extract information from a collection > > of resources, nested or otherwise. > > It makes it simple represent data in a variety of ways. > > It does make it harder to have arbitrary URL schema, due to the nature > > of the system, and the need for everything to have a unique URL for > > performing operations on. > > Trade-offs :-/ >Most things are in web design, no? I mean, if there weren''t there wouldn''t be so many jobs going round, as people would be much better placed to get it right all the time. [--snip--]> > > Or just not use REST for this application. It isn''t for everything. > > You''ve been patient and helpful. > I hope others have benefited from this thread. >Well, I''m glad I could help you at least. Regards, Jonathan --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---