On 6 ene, 06:43, "Nathan Weizenbaum" <[email protected]> wrote:
> A few possibilities spring to my mind. Rails has some weird plugin-loading
> corner cases, so it's possible that there's a different (older) version of
> Haml installed there that's getting loaded instead of the one you expect.
> You might try checking out Haml::VERSION. It could also be that your options
> aren't getting loaded properly; try printing _hamlout.options within a
> template and seeing what's there.
Thanks very much Nathan. Emitting Haml::VERSION in a template yields:
2.0.6
And _hamlout.options yields:
{:preserve=>["textarea", "pre"], :attr_wrapper=>"'", :autoclose=>
["meta", "img", "link", "br", "hr", "input", "area", "param", "col",
"base"], :ugly=>false, :format=>:xhtml}
So that narrows things down quite a bit. I had actually already
inspected Haml::Template::options[:ugly] and that returns true. As
soon as I saw the discrepancy I knew what the problem would be because
I'd seen it before in other areas.
Turns out to be a another load-ordering issue, the first of quite a
few I've run into with the latest rails.
Basically, there are three places you can have "Haml::Template::options
[:ugly] = true" during application startup.
1. in environment.rb, _inside_ the Rails::Initializer.run block, after
your "config.gem 'haml'" declaration
2. in environment.rb, _after_ the Rails::Initializer.run block
3. in an initializer in config/initializers
Option "1" won't work because Haml hasn't been loaded yet.
Option "2" used to work but doesn't any more because as of Rails 2.2
it seems, Haml is already loaded at that point, set up, and presumably
the templates are precompiled (my understanding of exactly what has
happened by that point is a bit fuzzy, but that's the basic gist of
it). Whatever the exact mechanics of it, but the time you set "ugly"
to true it's already too late.
Option "3" is the right one and fixes the problem. These initializers
are evaluated at the end of the initializer block, before returning
control to the rest of the environment.rb file, but presumably _after_
loading Haml and _before_ doing some other initialization.
The reason I saw it on my development machine is because locally I
have class caching (config.cache_classes) turned off in the
development environment, and the sensitivity to load ordering only
manifests itself when class caching is turned on, as is the case on
the production machine.
Should have realized this of course seeing as it's actually about the
fourth time I've been bitten by this change in the move to Rails 2.2,
but like I said, it was 5 AM and I was running out of ideas...
So that's very much for your help Nathan. Hopefully my comments here
may be of use to anybody else who runs into the problem.
Cheers,
Wincent
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Haml" 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/haml?hl=en
-~----------~----~----~----~------~----~------~--~---
