Rails core - Apr 2010 - (Rails3-master) erubis: how to use things like preprocessing?

(Rails3 latest git master)

Subject says it. I''m trying to figure out how to use erubis features
described here: http://www.kuwata-lab.com/erubis/users-guide.05.html#rails,
especially preprocessing. My question is, where do I place the

  Erubis::Helpers::RailsHelper.preprocessing=true

Not in application.rb, at that point the object does not exist yet it
seems. I wonder why I don''t see ANY mention whatsoever of such an
important feature like erubis preprocessing when someone writes about
"Rails 3 x-times faster"? Or about what it means that erubis is in
Rails 3 now? Or did I (i.e. Google) overlook some blog post :-)

-- 
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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

> Not in application.rb, at that point the object does not exist yet it
> seems. I wonder why I don''t see ANY mention whatsoever of such an
> important feature like erubis preprocessing when someone writes about
> "Rails 3 x-times faster"? Or about what it means that erubis is
in
> Rails 3 now? Or did I (i.e. Google) overlook some blog post :-)
The preprocessing functionality in Erubis is a little brittle.  It
relies on custom implementations of helpers like link_to which can be
evaluated outsite the context of a request / response and statically
be copied into the template source.  It''s kind of a neat trick, but it
won''t work out of the box with rails 3 unless the erubis lib gets
updated or other people ship alternative erubis compilers which do
that kind of thing.

In reality, the use of erubis in rails 3 wasn''t for performance gains
(which were relatively minor)  but  because it''s a much nicer API to
extend and write our own customisations to the rendering phase.
Specifically building the XSS-escaping was quite trivial to do with
erubis but was a huge amount of monkeypatching when I first tried in
with erb.

Don''t expect magical performance gains or anything, it''s just
a nicer
upstream gem for us to use :).


-- 
Cheers

Koz

-- 
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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

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
Developer | Engine Yard
(ph) 718.877.1325


On Wed, Apr 7, 2010 at 1:01 AM, Michael Koziarski
<michael@koziarski.com>wrote:
> > Not in application.rb, at that point the object does not exist yet it
> > seems. I wonder why I don''t see ANY mention whatsoever of
such an
> > important feature like erubis preprocessing when someone writes about
> > "Rails 3 x-times faster"? Or about what it means that erubis
is in
> > Rails 3 now? Or did I (i.e. Google) overlook some blog post :-)
>
> The preprocessing functionality in Erubis is a little brittle.  It
> relies on custom implementations of helpers like link_to which can be
> evaluated outsite the context of a request / response and statically
> be copied into the template source.  It''s kind of a neat trick,
but it
> won''t work out of the box with rails 3 unless the erubis lib gets
> updated or other people ship alternative erubis compilers which do
> that kind of thing.
>
> In reality, the use of erubis in rails 3 wasn''t for performance
gains
> (which were relatively minor)  but  because it''s a much nicer API
to
> extend and write our own customisations to the rendering phase.
> Specifically building the XSS-escaping was quite trivial to do with
> erubis but was a huge amount of monkeypatching when I first tried in
> with erb.
>
> Don''t expect magical performance gains or anything, it''s
just a nicer
> upstream gem for us to use :).
>
>
> --
> Cheers
>
> Koz
>
> --
> 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 rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
>
rubyonrails-core+unsubscribe@googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-core?hl=en.
>
>
-- 
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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

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 <wyc...@gmail.com>
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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.