Nicholas Seckar and I have been working on a rewrite of the routing code, making it leaner, faster, and easier to understand. It will also be easier to extend, so it is an all-around win. However, because it is a rewrite, the internals have changed significantly. If you have code (a plugin or otherwise) that messes with routing, there is a good chance this rewrite will break that code. The public-facing API (things you use in config/routes.rb) will remain the same, but expect anything else to break. The simply_restful plugin, for instance, will not work with the new routes until some (minor) modifications are made to it. I''ll be working this afternoon on merging the new routing code in, and depending on how smoothly it goes, this may be finished as soon as tomorrow. If I hit some bumps, it may take longer. Just wanted to give everyone a heads-up. - Jamis
Will there now be a way to get the long url back? Here''s an example. map.connect '''', :controller => "pragmatic", :action => ''index'' Can we now map this back to /pragmatic/index by using url_for? I don''t know if anyone else uses this, but it would really help me out on the page expiration plugin I wrote (Broomstick). On Tue, 2006-05-30 at 12:46 -0600, Jamis Buck wrote:> Nicholas Seckar and I have been working on a rewrite of the routing > code, making it leaner, faster, and easier to understand. It will > also be easier to extend, so it is an all-around win. > > However, because it is a rewrite, the internals have changed > significantly. If you have code (a plugin or otherwise) that messes > with routing, there is a good chance this rewrite will break that > code. The public-facing API (things you use in config/routes.rb) will > remain the same, but expect anything else to break. > > The simply_restful plugin, for instance, will not work with the new > routes until some (minor) modifications are made to it. > > I''ll be working this afternoon on merging the new routing code in, > and depending on how smoothly it goes, this may be finished as soon > as tomorrow. If I hit some bumps, it may take longer. > > Just wanted to give everyone a heads-up. > > - Jamis > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core >Charlie Bowman Programmer Castle Branch Inc. _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Hi Jamis, Thanks for the notice. I''ll keep an eye on it and make adjustments to the Request Routing plugin as necessary. I''m looking forward to a rewrite of the routing code, it''s the most difficult to extend of part of Rails. Cheers, Dan On 5/30/06, Jamis Buck <jamis@37signals.com> wrote:> Nicholas Seckar and I have been working on a rewrite of the routing > code, making it leaner, faster, and easier to understand. It will > also be easier to extend, so it is an all-around win. > > However, because it is a rewrite, the internals have changed > significantly. If you have code (a plugin or otherwise) that messes > with routing, there is a good chance this rewrite will break that > code. The public-facing API (things you use in config/routes.rb) will > remain the same, but expect anything else to break. > > The simply_restful plugin, for instance, will not work with the new > routes until some (minor) modifications are made to it. > > I''ll be working this afternoon on merging the new routing code in, > and depending on how smoothly it goes, this may be finished as soon > as tomorrow. If I hit some bumps, it may take longer. > > Just wanted to give everyone a heads-up. > > - Jamis > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core >-- Dan Webb http://www.danwebb.net
It would be nice if route parameters could be dinamicly accessible by
default values.
Something like this:
map.dashboard '':module'', :controller =>
''#{module}/dashboard''
So http://thedomain.com/organizer would actually call :controller =>
"organizer/dashboard'', :action => ''index''
But there''s a problem, url_for(:controller =>
''organizer/dashboard'', :action
=> ''index'') wouldn''t be possible cause it
wouldn''t know which route to use,
but probably dashboard_url(:module => ''organizer'') would be
just fine.
Please, write a decent documentation, since the current one is kinda
missing. :)
Cheers,
Rodrigo Kochenburger
On 5/30/06, Dan Webb <dan@danwebb.net> wrote:>
> Hi Jamis,
>
> Thanks for the notice. I''ll keep an eye on it and make
adjustments to
> the Request Routing plugin as necessary. I''m looking forward to a
> rewrite of the routing code, it''s the most difficult to extend of
part
> of Rails.
>
> Cheers,
>
> Dan
>
> On 5/30/06, Jamis Buck <jamis@37signals.com> wrote:
> > Nicholas Seckar and I have been working on a rewrite of the routing
> > code, making it leaner, faster, and easier to understand. It will
> > also be easier to extend, so it is an all-around win.
> >
> > However, because it is a rewrite, the internals have changed
> > significantly. If you have code (a plugin or otherwise) that messes
> > with routing, there is a good chance this rewrite will break that
> > code. The public-facing API (things you use in config/routes.rb) will
> > remain the same, but expect anything else to break.
> >
> > The simply_restful plugin, for instance, will not work with the new
> > routes until some (minor) modifications are made to it.
> >
> > I''ll be working this afternoon on merging the new routing
code in,
> > and depending on how smoothly it goes, this may be finished as soon
> > as tomorrow. If I hit some bumps, it may take longer.
> >
> > Just wanted to give everyone a heads-up.
> >
> > - Jamis
> > _______________________________________________
> > Rails-core mailing list
> > Rails-core@lists.rubyonrails.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails-core
> >
>
>
> --
> Dan Webb
> http://www.danwebb.net
> _______________________________________________
> Rails-core mailing list
> Rails-core@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-core
>
_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
On May 30, 2006, at 1:11 PM, Charlie Bowman wrote:> Will there now be a way to get the long url back? Here''s an example. > > map.connect '''', :controller => "pragmatic", :action => ''index'' > > Can we now map this back to /pragmatic/index by using url_for? I > don''t know if anyone else uses this, but it would really help me > out on the page expiration plugin I wrote (Broomstick).Charlie, I''m afraid I don''t understand. How would it know to build /pragmatic/ index from {:controller => "pragmatic", :action => "index"}, when you''ve connected it to ''''? You can''t have one route that maps to two paths, I''m afraid. - Jamis
ah but a documentation patch is being worked on: http://dev.rubyonrails.org/ticket/5165> Please, write a decent documentation, since the current one is kinda > missing. :)
> Charlie, > > I''m afraid I don''t understand. How would it know to build /pragmatic/ > index from {:controller => "pragmatic", :action => "index"}, when > you''ve connected it to ''''? You can''t have one route that maps to two > paths, I''m afraid. > > - JamisThat''s what I thought. I spent quite a long time trying to figure out the long url, but resorted to doing this in my routes. map.connect ''/pragmatic/'', :controller => "pragmatic" map.connect '''', :controller => "pragmatic" It works, but page caching is now broken with the the url "my_app.com/pragmatic". When I call url_for(:controller => ''pragmatic'') it returns ''/pragmatic/'' instead of ''''. My plugin works for all controllers now, but if you browse to my_app.com/pragmatic/ you will not receive the cached version. If I browse to "my_app.com", I do get the cached page. I''m sure this is caused by my duplication in the routes, but it''s a necessary evil that I''ll live with to make page expiration easier. For now I just don''t worry about caching "my_app.com/pragmatic/". My plugin allows me to expire all pages under a particular controller or controller/action combo. If I allow url_for to return '' '', then my expire method would delete the entire public folder if that is where the cached pages were stored. That''s why I was looking for an easy method that would return the long url.> _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core >Charlie Bowman Programmer Castle Branch Inc. _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
On May 30, 2006, at 3:11 PM, Charlie Bowman wrote:> Will there now be a way to get the long url back? Here''s an example. > > map.connect '''', :controller => "pragmatic", :action => ''index'' > > Can we now map this back to /pragmatic/index by using url_for? I > don''t know if anyone else uses this, but it would really help me > out on the page expiration plugin I wrote (Broomstick).It would not be hard to make a plugin to do this... Most of this is copied from the new impl: class RouteSet def generate_all(options, recall) options = options_as_params(options) expire_on = build_expiry(options, recall) merged = expire_on[:controller] ? options : recall.merge(options) routes.collect {|r| r.generate(options, merged, expire_on)}.compact end end
On May 30, 2006, at 4:04 PM, Charlie Bowman wrote:>> Charlie, I''m afraid I don''t understand. How would it know to >> build /pragmatic/ index from {:controller => "pragmatic", :action >> => "index"}, when you''ve connected it to ''''? You can''t have one >> route that maps to two paths, I''m afraid. - Jamis > > That''s what I thought. I spent quite a long time trying to figure > out the long url, but resorted to doing this in my routes. > > map.connect ''/pragmatic/'', :controller => "pragmatic" > map.connect '''', :controller => "pragmatic" > > It works, but page caching is now broken with the the url > "my_app.com/pragmatic". When I call url_for(:controller => > ''pragmatic'') it returns ''/pragmatic/'' instead of ''''. My plugin > works for all controllers now, but if you browse to my_app.com/ > pragmatic/ you will not receive the cached version. If I browse to > "my_app.com", I do get the cached page. I''m sure this is caused by > my duplication in the routes, but it''s a necessary evil that I''ll > live with to make page expiration easier. For now I just don''t > worry about caching "my_app.com/pragmatic/". My plugin allows me > to expire all pages under a particular controller or controller/ > action combo. If I allow url_for to return '' '', then my expire > method would delete the entire public folder if that is where the > cached pages were stored. That''s why I was looking for an easy > method that would return the long url.Could you just have the '''' url redirect to the cached url? - Jamis
On May 30, 2006, at 6:35 PM, Nicholas Seckar wrote:> It would not be hard to make a plugin to do this...Actually Nicholas, putting this into core would be a good idea, as we could ''fix'' caching -- we could save page caches to all the paths for a parameter set, and sweepers would be able to properly purge all the urls. Kind Regards, self
Sorry, for the slow reply. I''m only registered for this list at my work address and there''s no way I''m going to set my home computer to check that email! You''re right I could definitely use a redirect statement to make caching work, but it seems like a hackish maneuver. As soon as this rewrite goes into the core, I''ll work on a plugin to retrieve the long_url_for. On Tue, 2006-05-30 at 16:39 -0600, Jamis Buck wrote:> Could you just have the '''' url redirect to the cached url? > > - Jamis > > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-coreCharlie Bowman http://www.recentrambles.com _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
On May 31, 2006, at 7:49 AM, Charlie Bowman wrote:> Sorry, for the slow reply. I''m only registered for this list at my > work address and there''s no way I''m going to set my home computer > to check that email! > > You''re right I could definitely use a redirect statement to make > caching work, but it seems like a hackish maneuver. As soon as > this rewrite goes into the core, I''ll work on a plugin to retrieve > the long_url_for.Really what is required is to produce all the urls for a given resource. The two main problems with page caching are: - A cached page may be located at several paths. The big issue here is that only the first route matched will be swept on changes. - Query parameters mess up caching; if you create a cache page with query parameters, then the same request without query parameters will hit the cache, even though there is a strong probability that it shouldn''t. Adding a mechanism to generate all valid paths for a param set can help us fix sweepers so that they erase all the cached versions, as they probably should.
> Really what is required is to produce all the urls for a given > resource. The two main problems with page caching are: > - A cached page may be located at several paths. The big issue > here is that only the first route matched will be swept on changes.Yes, this is how I deleted my entire public directory during testing. This is also why I could retrieve the long url by adding the extra route.> - Query parameters mess up caching; if you create a cache page > with query parameters, then the same request without query parameters > will hit the cache, even though there is a strong probability that it > shouldn''t.I think most people who rely heavily on page caching have started putting all query parameters into the url. I''m of the group that advocates putting all query parameters into the url if possible. Although, I agree that if page caching worked with query parameters, there would be a lot of happy users out there!> Adding a mechanism to generate all valid paths for a param set can > help us fix sweepers so that they erase all the cached versions, as > they probably should.I think I fall into the "common" user category, nothing too basic and nothing too complicated yet, and this would really help me with page expiration. This would also eliminate the need for me to have a long_url_for method. Charlie Bowman http://www.recentrambles.com _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core