Okay thanks! That saves me LOTS of time trying to find things out by looking at the source, which is nice but which I try to avoid (since there is so much of it to look at these days, and esp. library- and framework code being so fragmented and full of optimizations good for many things but not readability).
On Apr 7, 11:58 pm, Yehuda Katz <[email protected]> wrote: > Yeah, > > Essentially, the way preprocessing works is by providing a completely > different (static) helper to Erubis at compile-time. You might think of > link_to as static (if you use it that way), but it actually does a whole > slew of request-specific things. Over time, helpers like link_to actually > become more dynamic as Rails tries to reduce the tedium that comes from > having to manually care about request-specific concerns. > > A simple case: the link_to helper use the current environment's host name, > the SCRIPT_NAME (in the case where Rails is nested inside of Rack::UrlMap or > other Rack mapping layer) and the :controller/:action/:id from the current > request (which is how url_for(:action => :index) works. In short, the number > of caveats in even something as simple as link_to is large. > > If you were able to make a purely-static version of link_to, it would be so > simplified that the vast majority of the performance improvement would > likely apply to using that helper in a dynamic context. And of course, we > can always improve the performance of helpers like link_to much more (a > focus of 3.0 and even more in future versions of Rails). > > Yehuda Katz -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
