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 -~----------~----~----~----~------~----~------~--~---
