Wow. Whoops. I guess that's..wow. On May 17, 11:51 am, Tom Bagby <[EMAIL PROTECTED]> wrote: > I wrote the patch that applies this behaviour and I don't think you > have to worry. > > 1) As to Erb's behaviour, this is a clone of how ActionView/Erb work > together to apply locals, including the superset behaviour. If you > call a template once with one set of locals, then again with a smaller > set of locals, the locals you don't pass in are defined and set to nil > in the compiled template in Erb. I'd be interested in examples of > where you are depending on a different behaviour. > > 2) Passing in assignments to nil works as you would expect. The > supported local assigns are determined by the keys in the locals > hash. If you assign nil to a local, the local will be defined and > have the value nil. No special treatment is required. > > I would think that passing in different sets of locals is kind of > unusual behaviour. Especially since Haml encourages not putting too > much logic into templates, it seems like in the vast majority of > cases, leaving a local undefined that is referenced in the template > will result in an error. Which is why I think it's fine to deal with > different sets of local variables as a corner case to prevent bugs but > not worry too much about efficiency. > > However, I agree with Nathan's assessment that it would be faster to > store the precompiled template so you could shove new local assigns > into it and recreate the render function. In practice, I believe the > ActionView implementation has the option to do this and doesn't. They > build the render function and assignments bit in the template part, > and the rendering of the erb inside of the erb engine and then kind of > glue them together. So they could just cache the erb precompiled > function and reuse it when they make the new template and assigns > function, but I don't remember seeing this actually happening. Like I > said, I think for most people's use cases, this doesn't happen much, > I've certainly not seen it happen even once in our relatively large > project. > > -Tom > > On May 16, 9:22 pm, Nick Howell <[EMAIL PROTECTED]> wrote: > > > Bingo; never mind the last message. I see now that in > > Engine#initialize you ensure that a superset is supported. > > > Problem with this is that a lot of people (myself included) depend on > > locals that have not been sent explicitly remaining undefined. That's > > pretty standard behavior with erb and earlier versions of haml, though > > I understand if you want to break with this. Another question: what if > > someone passes in nil for one of their locals? I guess they'd need a > > workaround; a special MyNilClass. Or maybe just pass in false? > > > Admittedly, you get better performance with this method, but I'm not > > sure it's worth the lack of "niceness." > > > Nick > > > On May 16, 10:25 pm, Nathan Weizenbaum <[EMAIL PROTECTED]> wrote: > > > > Whoops! I should have caught that. I'll fix it as soon as I'm able (I > > > just got a new computer, and I have yet to install Ruby or Subversion on > > > it - soon, though!). > > > > - Nathan > > > > Nick Howell wrote: > > > > Thought I'd seen the last of this one[1]. > > > > > engine.rb: > > > > 421 @scope_object.class.instance_eval do > > > > 422 include CompiledTemplates > > > > 423 end > > > > > Should be > > > > @scope_object.extend(CompiledTemplates) > > > > > [1]:http://groups.google.com/group/haml/browse_frm/thread/c6a681ae92ae1b1... > > > > > What're the chances? > > > > > I'd be careful of ever doing .class.instance_eval. > > > > > Nick
--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
