hi all, how are other people passing and accessing ''get'' parameters from their apps? what is the best way to do it? ie: www.example.com/controller/action/id/extra/extra2/ ?? or www.example.com/controller/action/id/~extra/extra2/ or what ever.... are there built in methods for passing and accessing extra parameters? thanks for your suggestions -felix
Check out the documentation on routing and config/routes.rb It''s all automagically delicious. :-) -- -- Tom Mornini On Oct 5, 2005, at 9:12 PM, Felix wrote:> hi all, > > how are other people passing and accessing ''get'' parameters from > their apps? > > what is the best way to do it? > > ie: > > www.example.com/controller/action/id/extra/extra2/ ?? > > or > > www.example.com/controller/action/id/~extra/extra2/ > > or what ever.... > > are there built in methods for passing and accessing extra parameters? > > thanks for your suggestions > > -felix > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
The url would look something like: www.example.com/controller/action/id?param1=value1¶m2=value2 In which case, you can access param1 and param2 via p1 = params[:param1] #value1 p2 = params[:param2] #value2 And the url is constructed via url_for(:controller => controller, :action => action, :id => id, :param1 => param1, :param2 => param2) -----Original Message----- From: rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org [mailto:rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org] On Behalf Of Felix Sent: Thursday, 6 October 2005 2:13 PM To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org Subject: [Rails] accessing extra request parameters hi all, how are other people passing and accessing ''get'' parameters from their apps? what is the best way to do it? ie: www.example.com/controller/action/id/extra/extra2/ ?? or www.example.com/controller/action/id/~extra/extra2/ or what ever.... are there built in methods for passing and accessing extra parameters? thanks for your suggestions -felix _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On Oct 5, 2005, at 10:03 PM, Neville Burnell wrote:> The url would look something like: > > www.example.com/controller/action/id?param1=value1¶m2=value2 > > In which case, you can access param1 and param2 via > > p1 = params[:param1] #value1 > p2 = params[:param2] #value2 > > And the url is constructed via > > url_for(:controller => controller, :action => action, :id => > id, :param1 > => param1, :param2 => param2)That''s an incomplete answer that doesn''t answer the question. He showed the form of the URLs that he was looking for, and they''re perfectly achievable with Rails. In fact, the form you''ve shown is somewhat anathema to the concept of pretty URLs. Routing and routes.rb is the Rails Way answer. -- -- Tom Mornini
> He showed the form of the URLs that he was looking for, > and they''re perfectly achievable with Rails.Umm, well, ok, I didn''t read the OP like that.> In fact, the form you''ve shown is somewhat anathema to the concept > of pretty URLs.ok, that''s your opinion ... Plenty of room for diversity> Routing and routes.rb is the Rails Way answer.And I''m happy to change my ways ... How about a full example for me and the OP? Neville
On Oct 6, 2005, at 2:37 AM, Neville Burnell wrote:>> He showed the form of the URLs that he was looking for, >> and they''re perfectly achievable with Rails. > > Umm, well, ok, I didn''t read the OP like that. > >> In fact, the form you''ve shown is somewhat anathema to the concept >> of pretty URLs. > > ok, that''s your opinion ... Plenty of room for diversitySee my other post on the subject of diversity. :-) Additionally, it''s not my opinion that counts in any way, shape or form. It''s DHH''s that''s at issue. And, NO, I don''t pretend to speak for him, but when he says that he prefers to write less code with more opinions, I''ll take him at his word. :-)>> Routing and routes.rb is the Rails Way answer. > > And I''m happy to change my ways ... How about a full example for me > and > the OP?OK, two params on the URL, named :param1 and :param2: config/routes.rb map.connect '':controller/:action/:param1/:param2'' That''s it. It''s bidirectional in that incoming requests will now be routed and parsed as such, and link_to and url_for will choose this format when their input matches this pattern. -- -- Tom Mornini
I find you do get into some slight difficulties when you want one of the parameters to be called id, but you want another parameter, earlier in the URL, in some cases. If you still want the normal :controller/:action/:id route, you have to disambiguate things. For example, I want URLs where I have :id parameters for whatever I''m working with, but I need a ''branch'' parameter that I also pass around some parts of the admin system (to represent the id of the regional branch/office of an organisation). I end up with routes like: map.connect '':controller/:action/b/:branch_id/:id'' Where the /b/ in the path is a static element which disambiguates the path. Without it, I get confusion about which is the branch id (in operations on things which do not have an id to pass). I know I could always have it as a parameter at the end of the URL, and have :id first, but this flies in the face of URL structure for me. And yes, I know I could also just pick up the branch id as a property from the objects I''m working on - but forcing two url parameters to identify a database object is a useful security measure, and I can lock out non-branch-admins right at the beginning this way. Is there a neater way to disambiguate the routes? It''s not untidy, I suppose, but I''m open to ideas. (I should note that I have items within the branch, and I have sub-operations on those items, so I use another disambiguation for those. I''m less attached to this one, but I''d still like to do it). Incidentally, all of the controllers using this route are subclassed from a common base class, with a default_url_options method that puts the branch ID in, unless I pass a parameter in the url_for options to supress it, so the links function as if they are ''local'' to the branch. Thoughts, anyone? Mike On 6 Oct 2005, at 16:05, Tom Mornini wrote:> On Oct 6, 2005, at 2:37 AM, Neville Burnell wrote: > >>> He showed the form of the URLs that he was looking for, >>> and they''re perfectly achievable with Rails. >> >> Umm, well, ok, I didn''t read the OP like that. >> >>> In fact, the form you''ve shown is somewhat anathema to the concept >>> of pretty URLs. >> >> ok, that''s your opinion ... Plenty of room for diversity > > See my other post on the subject of diversity. :-) > > Additionally, it''s not my opinion that counts in any way, shape or > form. It''s DHH''s that''s at issue. > > And, NO, I don''t pretend to speak for him, but when he says that > he prefers to write less code with more opinions, I''ll take him > at his word. :-) > >>> Routing and routes.rb is the Rails Way answer. >> >> And I''m happy to change my ways ... How about a full example for me >> and >> the OP? > > OK, two params on the URL, named :param1 and :param2: > > config/routes.rb > > map.connect '':controller/:action/:param1/:param2'' > > That''s it. It''s bidirectional in that incoming requests will now be > routed and parsed as such, and link_to and url_for will choose this > format when their input matches this pattern. > > -- > -- Tom Mornini > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
In order to disambiguate some routes, I used a fixed prefix and hardcoded :controller as such: map.connect ''prefix/:action/:branch_id/:id'', :controller => ''prefix'' -- -- Tom Mornini On Oct 6, 2005, at 8:46 AM, Michael Houghton wrote:> I find you do get into some slight difficulties when you want one > of the parameters to be called id, but you want another parameter, > earlier in the URL, in some cases. If you still want the > normal :controller/:action/:id route, you have to disambiguate things. > > For example, I want URLs where I have :id parameters for whatever > I''m working with, but I need a ''branch'' parameter that I also pass > around some parts of the admin system (to represent the id of the > regional branch/office of an organisation). > > I end up with routes like: > > map.connect '':controller/:action/b/:branch_id/:id'' > > Where the /b/ in the path is a static element which disambiguates > the path. Without it, I get confusion about which is the branch id > (in operations on things which do not have an id to pass). > > I know I could always have it as a parameter at the end of the URL, > and have :id first, but this flies in the face of URL structure for > me. And yes, I know I could also just pick up the branch id as a > property from the objects I''m working on - but forcing two url > parameters to identify a database object is a useful security > measure, and I can lock out non-branch-admins right at the > beginning this way. > > Is there a neater way to disambiguate the routes? It''s not untidy, > I suppose, but I''m open to ideas. > > (I should note that I have items within the branch, and I have sub- > operations on those items, so I use another disambiguation for > those. I''m less attached to this one, but I''d still like to do it). > > Incidentally, all of the controllers using this route are > subclassed from a common base class, with a default_url_options > method that puts the branch ID in, unless I pass a parameter in the > url_for options to supress it, so the links function as if they are > ''local'' to the branch. > > Thoughts, anyone? > > Mike > > > On 6 Oct 2005, at 16:05, Tom Mornini wrote: > > >> On Oct 6, 2005, at 2:37 AM, Neville Burnell wrote: >> >> >>>> He showed the form of the URLs that he was looking for, >>>> and they''re perfectly achievable with Rails. >>>> >>> >>> Umm, well, ok, I didn''t read the OP like that. >>> >>> >>>> In fact, the form you''ve shown is somewhat anathema to the concept >>>> of pretty URLs. >>>> >>> >>> ok, that''s your opinion ... Plenty of room for diversity >>> >> >> See my other post on the subject of diversity. :-) >> >> Additionally, it''s not my opinion that counts in any way, shape or >> form. It''s DHH''s that''s at issue. >> >> And, NO, I don''t pretend to speak for him, but when he says that >> he prefers to write less code with more opinions, I''ll take him >> at his word. :-) >> >> >>>> Routing and routes.rb is the Rails Way answer. >>>> >>> >>> And I''m happy to change my ways ... How about a full example for >>> me and >>> the OP? >>> >> >> OK, two params on the URL, named :param1 and :param2: >> >> config/routes.rb >> >> map.connect '':controller/:action/:param1/:param2'' >> >> That''s it. It''s bidirectional in that incoming requests will now be >> routed and parsed as such, and link_to and url_for will choose this >> format when their input matches this pattern. >> >> -- >> -- Tom Mornini >> >> _______________________________________________ >> Rails mailing list >> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >> http://lists.rubyonrails.org/mailman/listinfo/rails >> >> > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Right. I can''t fix the controller in my case, so perhaps I have found the neatest way to identify those controllers which take the branch_id first. for example, I have: /admin/branch/item/edit/b/1/5 for controller Admin::Branch::ItemController, action ''edit'', branch 1, item 5. /admin/branch/item/new/b/1 for a new item, same branch. My default_url_options override always sticks in the branch id for any controller within a branch, so I can basically forget about having to pass it around. Elsewhere, in the admin system, but outside the branches, I still need :controller/:action/:id. I''ve tried various meddlings with reordering to put the branch id between controller and action, but encountered a few ambiguities as I went along (albeit still learning as I did). This system works fine, but I''d prefer something without the /b/. Ideally I would movie to a to_param method for identifying the branch by its short name, so anything that relies on matching /\d+/ is out. Can named routes help me here? It seems to me that the problem is: any simpler route becomes a one-way mapping, and we don''t want that. Don''t interpret this as complaint, merely intrigue! Mike On 6 Oct 2005, at 17:00, Tom Mornini wrote:> In order to disambiguate some routes, I used a fixed prefix and > hardcoded :controller as such: > > map.connect ''prefix/:action/:branch_id/:id'', :controller => ''prefix'' > > -- > -- Tom Mornini > > On Oct 6, 2005, at 8:46 AM, Michael Houghton wrote: > >> I find you do get into some slight difficulties when you want one of >> the parameters to be called id, but you want another parameter, >> earlier in the URL, in some cases. If you still want the normal >> :controller/:action/:id route, you have to disambiguate things. >> >> For example, I want URLs where I have :id parameters for whatever I''m >> working with, but I need a ''branch'' parameter that I also pass around >> some parts of the admin system (to represent the id of the regional >> branch/office of an organisation). >> >> I end up with routes like: >> >> map.connect '':controller/:action/b/:branch_id/:id'' >> >> Where the /b/ in the path is a static element which disambiguates the >> path. Without it, I get confusion about which is the branch id (in >> operations on things which do not have an id to pass). >> >> I know I could always have it as a parameter at the end of the URL, >> and have :id first, but this flies in the face of URL structure for >> me. And yes, I know I could also just pick up the branch id as a >> property from the objects I''m working on - but forcing two url >> parameters to identify a database object is a useful security >> measure, and I can lock out non-branch-admins right at the beginning >> this way. >> >> Is there a neater way to disambiguate the routes? It''s not untidy, I >> suppose, but I''m open to ideas. >> >> (I should note that I have items within the branch, and I have >> sub-operations on those items, so I use another disambiguation for >> those. I''m less attached to this one, but I''d still like to do it). >> >> Incidentally, all of the controllers using this route are subclassed >> from a common base class, with a default_url_options method that puts >> the branch ID in, unless I pass a parameter in the url_for options to >> supress it, so the links function as if they are ''local'' to the >> branch. >> >> Thoughts, anyone? >> >> Mike >> >> >> On 6 Oct 2005, at 16:05, Tom Mornini wrote: >> >> >>> On Oct 6, 2005, at 2:37 AM, Neville Burnell wrote: >>> >>> >>>>> He showed the form of the URLs that he was looking for, >>>>> and they''re perfectly achievable with Rails. >>>>> >>>> >>>> Umm, well, ok, I didn''t read the OP like that. >>>> >>>> >>>>> In fact, the form you''ve shown is somewhat anathema to the concept >>>>> of pretty URLs. >>>>> >>>> >>>> ok, that''s your opinion ... Plenty of room for diversity >>>> >>> >>> See my other post on the subject of diversity. :-) >>> >>> Additionally, it''s not my opinion that counts in any way, shape or >>> form. It''s DHH''s that''s at issue. >>> >>> And, NO, I don''t pretend to speak for him, but when he says that >>> he prefers to write less code with more opinions, I''ll take him >>> at his word. :-) >>> >>> >>>>> Routing and routes.rb is the Rails Way answer. >>>>> >>>> >>>> And I''m happy to change my ways ... How about a full example for me >>>> and >>>> the OP? >>>> >>> >>> OK, two params on the URL, named :param1 and :param2: >>> >>> config/routes.rb >>> >>> map.connect '':controller/:action/:param1/:param2'' >>> >>> That''s it. It''s bidirectional in that incoming requests will now be >>> routed and parsed as such, and link_to and url_for will choose this >>> format when their input matches this pattern. >>> >>> -- >>> -- Tom Mornini >>> >>> _______________________________________________ >>> Rails mailing list >>> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >>> http://lists.rubyonrails.org/mailman/listinfo/rails >>> >>> >> >> _______________________________________________ >> Rails mailing list >> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >> http://lists.rubyonrails.org/mailman/listinfo/rails >> > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >