Those of you have been following along in svn or listening on IRC will probably have heard a little about Routes. If you''ve been in the dark until now, allow me to shed some light. Routes are the fulfillment of the native Ruby dispatching wish. Starting with Rails 0.9.6, there will be no requirement webserver mod_rewrite-like support. In addition to enabiling Rails to function on a greater number of servers, Routes provide Rails with a flexible and powerful solution for customizable URLs. For the last week, Routes has been growing on a branch in the Rails svn tree. As of tonight, (2005-02-15) that branch has been merged back into trunk. The latest beta gems include Routes as well as many other new features, some of which were developed alongside Routes. A partial list includes: * Rewritten controller modules which now use true Module objects to provide separate namespaces * Bitsweat''s famed generators which include support for the new controller modules * Routes and related changes to url_rewriter, the dispatcher, and the webrick server * Minor changes to ActionPack''s rescue handling Although the coding for Routes has been completed, documentation for Routes and some of the related features is still forthcoming. Please be patient: I plan to write documention tomorrow. If you would like to view the current state of the documentation, feel free to point your browser at http://manuals.rubyonrails.com/read/book/9 Please don''t hesitate to send any remarks regarding the grammar, spelling, clarity, or content of this manual to my email account. Alternatively, feel free to message me on IRC. Of course, if you are aching to dive in, don''t forget that the testcases can often be an excellent reference. actionpack/tests/controller/routing_tests.rb contains several examples in the form of testcases. Before I finish this email, I would like remark upon the transition process. For sites which do not use custom URLs, the transition will be with zero effort. However, sites which currently employ mod_rewrite and url options such as :controller_prefix will require some work to update. The basic transition process will be to return your application to using default URLs, then update Rails to install Routes, and finally add in custom routes to return to your customized URLs. For this reason, those of you who use custom URLs may wish to put off updating Rails until this process is fully documented. [1] http://manuals.rubyonrails.com/read/book/9 [2] http://weblog.rubyonrails.com/archives/2005/02/15/routing-now-available-in-beta-gems/ [3] http://dev.rubyonrails.com/file/trunk/actionpack/test/controller/routing_tests.rb -- Nicholas Seckar aka. Ulysses
On 15/02/2005, at 4:58 PM, Nicholas Seckar wrote:> Routes are the fulfillment of the native Ruby dispatching wish. > Starting with > Rails 0.9.6, there will be no requirement webserver mod_rewrite-like > support. > In addition to enabiling Rails to function on a greater number of > servers, > Routes provide Rails with a flexible and powerful solution for > customizable > URLs.Very good news! One question though: Can you use the hostname in the routing rules? For example blog.mydomain.com -> blog controller, photos.mydomain.com -> photo controller. - tim
Nicholas Seckar schrieb:> Routes are the fulfillment of the native Ruby dispatching wish. Starting with > Rails 0.9.6, there will be no requirement webserver mod_rewrite-like support. > In addition to enabiling Rails to function on a greater number of servers, > Routes provide Rails with a flexible and powerful solution for customizable > URLs.Thanks for your write up. Exciting stuff. Although as I see it mod_rewrite is still used. Maybe now it would be possible to use the simpler alternative of ErrorDocument 404 dispatch.fcgi Also a little mistake. Search for " tt>http://www.your-cool-domain.com/date/2005/02—we" Also: "Not all webservers support rewriting. By moving this code to the framework Rails is able to function “out of the box” on almost all webservers, most notably lighttpd." This sounds a little like lighttpd doesn''t support mod_rewrite, which is not true of course. Sascha
Nicholas Seckar wrote:> > If you would like to view the current > state of the documentation, feel free to point your browser at > > http://manuals.rubyonrails.com/read/book/9Perhaps the CSS needs tweaking... the <code> and <pre> font is so small in Firefox that I can barely read it. Curt
Nicholas, Routes look amazing. Thankyou. I can''t wait to get my hands dirty with 0.9.6!! --- Justin French, Indent.com.au justin.french-zULN+VWqVOIpAS55Wn97og@public.gmane.org Web Application Development & Graphic Design
I''ve just begun playing with it, and it works like a charm! bigups to those involved with making Routes what it is. At first its a lttle daunting until I realised that I should just cary on as usual and redirect (or link_to or url_for''ing) to my controllers and actions as usual and let Routes take of the rewriting the urls. Which is exactly the point behind routes I guess. I like that I don''t have to fanny about with the :path_params and all the jazz for most things (?) and that I should just do: link_to ''show all cows named Jill'', :controller => ''farm'', :action => ''animals'', :animal_type => ''cows'', :id => ''jill'' and with a route like this: map.connect ''animals/:animal_type/:id'', :controller => ''farm'', :action => ''animal'' and I should get linked to domain.com/animals/cows/jill (unless my silly farmboy example is wrong of couse). I''m digging this! On Tue, 15 Feb 2005 23:25:30 +1100, Justin French <justin.french-zULN+VWqVOIpAS55Wn97og@public.gmane.org> wrote:> Nicholas, > > Routes look amazing. Thankyou. I can''t wait to get my hands dirty > with 0.9.6!! > > --- > Justin French, Indent.com.au > justin.french-zULN+VWqVOIpAS55Wn97og@public.gmane.org > Web Application Development & Graphic Design > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Johan Sørensen Professional Futurist www.johansorensen.com
On Tuesday 15 February 2005 06:20, Sascha Ebach wrote:> Thanks for your write up. Exciting stuff. Although as I see it > mod_rewrite is still used. Maybe now it would be possible to use the > simpler alternative of > > ErrorDocument 404 dispatch.fcgiUsing a pure ErrorDocument setup was attempted, but apache will not forward POST variables to a 404 handler. -- Nicholas Seckar aka. Ulysses
Question: is it possible to define a route that would handle URLs like "/wiki/show/page/with/slashes" ==> :controller => ''wiki'', :action => ''show'', :id => ''page/with/slashes'' If not, how can I work around the problem that a Wiki page can have a name with a slash, (or any other kind of interesting character, really) -- Best regards, Alexey Verkhovsky Ruby Forum: http://ruby-forum.org (moderator) RForum: http://rforum.andreas-s.net (co-author) Instiki: http://instiki.org (maintainer)
err... any "strange" character must be encoded, right? On Wed, 16 Feb 2005 00:29:55 +0200, Alexey Verkhovsky <alex-vV7tgcE2N9Nhl2p70BpVqQ@public.gmane.org> wrote:> Question: is it possible to define a route that would handle URLs like > > "/wiki/show/page/with/slashes" > ==> :controller => ''wiki'', :action => ''show'', :id => ''page/with/slashes'' > > If not, how can I work around the problem that a Wiki page can have a > name with a slash, (or any other kind of interesting character, really) > > -- > Best regards, > > Alexey Verkhovsky > > Ruby Forum: http://ruby-forum.org (moderator) > RForum: http://rforum.andreas-s.net (co-author) > Instiki: http://instiki.org (maintainer) > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- juraci krohling costa
On Tuesday 15 February 2005 17:29, Alexey Verkhovsky wrote:> If not, how can I work around the problem that a Wiki page can have a > name with a slash, (or any other kind of interesting character, really)Most ''interestng'' characters are escaped and unescaped automatically. Using ''/'' is not an option -- surely you can see why: It would lead to ambiguous parsing states whenever two non-static components were adjacent. For example, do we parse "/wiki/show/page/with/slashes" with :action => ''page/with'' and :page => ''slashes'', or in some other possible manner. Although for actions we could deduce the correct parsing, there is little advantage to adding special case logic for this. You can escape your names using any number of techniques and unescape them after request. (You might consider adding Model.escaped_id and Model.find_with_escaped_id) The correct technique depends upon the situation and I won''t bore you by suggesting obvious solutions. One thing I may be tempted to do is to enable the collection of extra path components in a variable to enable paths such as "files/some/arbitrary/path/to/a/file.xyz". Currently routes have little support for variable length paths and a change such as this may remedy that situation. -- Nicholas Seckar aka. Ulysses
On 16.2.2005, at 07:36, Nicholas Seckar wrote:> On Tuesday 15 February 2005 17:29, Alexey Verkhovsky wrote: >> If not, how can I work around the problem that a Wiki page can have a >> name with a slash, (or any other kind of interesting character, >> really) > > Most ''interestng'' characters are escaped and unescaped automatically. > > Using ''/'' is not an option -- surely you can see why: It would lead to > ambiguous parsing states whenever two non-static components were > adjacent. > > For example, do we parse "/wiki/show/page/with/slashes" with :action => > ''page/with'' and :page => ''slashes'', or in some other possible manner.As a ruby function name can''t have a slash in it, I think it shouldn''t be too ambiguous.> One thing I may be tempted to do is to enable the collection of extra > path > components in a variable to enable paths such as > "files/some/arbitrary/path/to/a/file.xyz". Currently routes have little > support for variable length paths and a change such as this may remedy > that > situation.In my current project I have a rewrite rule that goes like this: if the first part of the uri is one of the controllers, go on with normal rails rules. If not, treat it as a page name and rewrite it ?controller=page&action=show&page_name=$1 In .htaccess I have to maintain a list of controller names manually. I hope Routes would help automate this but it is not essential. What I think is important is that Routes make it possible to build a site hierarchy (in a cms-like app) and parse those hierarchic url''s (yes, with a slash ;) easily. //jarkko -- Jarkko Laine http://jlaine.net http://odesign.fi _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Nicholas Seckar wrote:>On Tuesday 15 February 2005 17:29, Alexey Verkhovsky wrote: > > >>If not, how can I work around the problem that a Wiki page can have a >>name with a slash, (or any other kind of interesting character, really) >> >> > >Most ''interestng'' characters are escaped and unescaped automatically. > >Using ''/'' is not an option -- surely you can see why: It would lead to >ambiguous parsing states whenever two non-static components were adjacent. > >For example, do we parse "/wiki/show/page/with/slashes" with :action => >''page/with'' and :page => ''slashes'', or in some other possible manner. >Although for actions we could deduce the correct parsing, there is little >advantage to adding special case logic for this. > >You can escape your names using any number of techniques and unescape them >after request. (You might consider adding Model.escaped_id and >Model.find_with_escaped_id) The correct technique depends upon the situation >and I won''t bore you by suggesting obvious solutions. > >One thing I may be tempted to do is to enable the collection of extra path >components in a variable to enable paths such as >"files/some/arbitrary/path/to/a/file.xyz". Currently routes have little >support for variable length paths and a change such as this may remedy that >situation. > > >OK, how about map.connect('':web/:action/:page_name...'') that would do uri_parts = uri.split(''/'') { :web => uri_parts[0], :action => uri_parts[1], :page_name => uri_parts[2..-1].join(''/'') } Besides, I''m tempted to suggest: map.connect(regexp) { |match_data| # a block that returns a hash } although this will only work one way (to recognize, but not to generate a URI), so should have a different method name. -- Best regards, Alexey Verkhovsky Ruby Forum: http://ruby-forum.org (moderator) RForum: http://rforum.andreas-s.net (co-author) Instiki: http://instiki.org (maintainer)