Yeah, more or less. The issue is that it's really time-consuming to compile a Haml or ERB template, so Rails minimizes it by re-using locals.
On Thu, Jun 11, 2009 at 1:31 PM, Ben Fyvie <[email protected]>wrote: > Thanks for the insight Nathan. It sounds like some sort of built in > caching of variables, is that right? Does this caching take place only on > the mongrel instance that handled the request? If that is the case then it > would explain why the exception is raised on our production server where we > have a total of 6 mongrels across two servers, so the AJAX request is likely > sent to a different mongrel and possibly even a different server than the > initial index request. But when running locally we only every have one > mongrel or webrick instance to handle all requests and so the AJAX request > is being sent to the same instance that also received the index request. > This automatic caching behavior of Rails seems a bit odd to me in that is > seems to do more harm than good and doesn’t really serve any purpose when > running more than a single mongrel instance. > > > > > > Ben Fyvie > > ------------------------------ > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of > *Nathan Weizenbaum > *Sent:* Thursday, June 11, 2009 3:11 PM > > *To:* [email protected] > *Subject:* [haml] Re: Haml not consistently raising "undefined local > variable or method" exceptions > > > > Ah, I see what the problem is. It's not from Haml, it's from Rails, and > it's pretty inescapable due to the way locals are handled in templates. What > happens is that each template has a set of locals associated with it - the > locals that have been used in that template before. When you try to render a > template with more locals than it has, it's recompiled with those locals > added in. > > What that means is that when you run your partial via AJAX, it's already > been run when generating the index view, so it's been compiled with those > locals. They're set to nil if you don't pass them in, but they're still > there. > > The upshot of all this is that if you ever pass locals in to a given > partial, you can't rely on them raising an error ever. > > On Thu, Jun 11, 2009 at 9:10 AM, Ben Fyvie <[email protected]> > wrote: > > Thanks for offering to help. I’ve included a very simple rails app that > reproduces the problem. Included in the app is a frozen version of Rails as > well as two frozen versions of HAML, the bug is occurring in both versions. > To change the frozen gem that is used, simply modify environment.rb. > > > > > > Ben Fyvie > ------------------------------ > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of > *Nathan Weizenbaum > *Sent:* Wednesday, June 10, 2009 11:26 AM > *To:* [email protected] > *Subject:* [haml] Re: Haml not consistently raising "undefined local > variable or method" exceptions > > > > What is the output of "haml --version"? > > Since you're finding this difficult to reproduce, I imagine I will as well. > Could you create a minimal Rails app that demonstrates the problem and send > it to me? > > On Wed, Jun 10, 2009 at 8:21 AM, Ben Fyvie <[email protected]> > wrote: > > > We have a very very simple problem that I am hoping somebody can > resolve. > > We are running the following: > > Frozen Rails Gem 2.1.2 > Frozen Haml Gem 2.1.0 > Ruby 1.8.6 patch level 287 > > Our problem is very simple. The following code in haml should always > raise an exception: > > -p my_undefined_variable > -p my_undefined_variable.class > > > This is true in our production and staging environments (hosted at > EngineYard); however, on our local dev machines we get output of nil > and NilClass with no exceptions being raised. If we change from haml > to erb the exception is raised as expected. We have a windows and a > mac dev machine, neither of which are able to get the exception > raised. > > Any ideas? > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
