"Adam Jacob" <[EMAIL PROTECTED]> writes:
> On Tue, Jul 15, 2008 at 12:36 AM, Daniel Pittman <[EMAIL PROTECTED]> wrote:
I recorded this as ticket #1427, and captured Adam's comments and mine
into that -- in large part because I have done some local work on
implementing a solution to this.
It isn't entirely clear to me, though, how that discussion is best
maintained when input on design issues is required: should I restrict
myself exclusively to RedMine, or discuss things here and copy the
content over?
The development guidelines, sadly, are not entirely clear on this. :/
[...]
>> There is also option 3, which I would be happy to work on implementing:
>>
>> 3. Expose puppet variables to ERB through some mechanism other than
>> implementing missing_method, so they are the closest lexical scope
>> value found.
>
> I've done a bit of digging in the template class, and I think you
> might be able to refactor it thusly:
>
> Look up all the variables in @scope, and turn them in to
> instance_variables of the template wrapper class. This would let you
> do:
>
> <%= @operatingsystem == "foo" %>
> Instead of the current
> <%= operatingsystem == "foo" %>
This would work; the only current instance variable is '@scope', used to
support the missing_method code. We could redeclare that with a name
less likely to conflict, and then use this successfully.
There isn't any 'instance variable missing' method, however, which means
that this would give up the ability of ERB templates to report the use
of undefined variables -- which is probably undesirable, given how many
times it caught typos in my own templates.
> If you really want to have local variables, we could do the same thing
> within a lambda, and use that as the binding:
>
> <%= operatingsystem == "foo" %>
>
> That would eliminate the need for the method_missing entirely.
That would be better: using method_missing we could still report some
but not all cases where the template referred to an unbound variable.
However, it still exposes the risk that, for example, an inadvertent use
of an Object method would cause problems; this is much smaller than the
current exposure, however.
Both options have trade-offs in terms of their behaviour and risks, and
both continue to expose the developers of ERB templates to potentially
confusing side-effects.
I think that the member variable approach, of the two, has the lower
risk of trouble, even if it gives up the ability to catch invalid
variable references, as they will show up reasonably quickly in
functional testing by end users.
Is this the general opinion, or is there another approach that I have
missed in this?[1]
Regards,
Daniel
Footnotes:
[1] I have, for now, excluded the approach of using a templating engine
that does not require evaluation of Ruby code generated from the
template, because no such engine ships with the Ruby interpreter.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Developers" 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/puppet-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
