On Thursday, May 15, 2014 6:08:44 PM UTC+2, Andy Parker wrote: > > On Thu, May 15, 2014 at 7:46 AM, Alessandro Franceschi > <[email protected]<javascript:> > > wrote: > >> Hallo everybody, >> I've tried to look around in the group for past discussions about this >> topic but haven't found any. >> If this has been already debated , please forgive me and point me to the >> right direction. >> >> > I tried to find the original ticket about data binding to see if there had > been a previous discussion and came up with > http://projects.puppetlabs.com/issues/11608 and > http://projects.puppetlabs.com/issues/8235. There is also the commit that > brought it in: > https://github.com/puppetlabs/puppet/commit/3ac5b50ce66948d9488bd394c169022d55ecf0d1 > > I wasn't able to figure out if there had been any discussion on this topic > either. > > >> I wonder what do you thing about a feature request to have data bindings >> also for defines' parameters. >> >> Naming is straightforward, a define like: >> apache::vhost { 'example.com': } >> >> could have its params looked in this namespace: >> apache::vhost::example.com::<parameter> >> > > The problem with using that key for lookup is that it clashes with a class > with the same name: > > class a::b($param) {} => a::b::param > > collides with > > define a($param) {} > a { b: } => a::b::param > > A better approach would possibly be to follow the resource reference > syntax and have the key be A[b]::param or even A[b][param], which is the > syntax in the language for puppet 4 to access resource parameter values > (see > https://tickets.puppetlabs.com/browse/PUP-488<https://www.google.com/url?q=https%3A%2F%2Ftickets.puppetlabs.com%2Fbrowse%2FPUP-488&sa=D&sntz=1&usg=AFQjCNF7oYK2Nn1T3W-U5y1StJSJhpYfnA> > ) >
Good point. Any sane naming is ok. What do you think of such a feature? Doable? Useful? > My poor understanding of Puppet code points me to: >> >> https://github.com/puppetlabs/puppet/blob/master/lib/puppet/resource.rb#L343 >> and makes me guess that such a change should not be too difficult. >> >> I see many wonderful use cases for such a feature and no apparent cons. >> >> What do you think? >> >> I've opened a ticket about this: >> >> https://tickets.puppetlabs.com/browse/PUP-2528 >> >> >> al >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/puppet-dev/6f9e8c23-53c2-420f-b7af-9b9fe7d5c1b0%40googlegroups.com<https://groups.google.com/d/msgid/puppet-dev/6f9e8c23-53c2-420f-b7af-9b9fe7d5c1b0%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Andrew Parker > [email protected] <javascript:> > Freenode: zaphod42 > Twitter: @aparker42 > Software Developer > > *Join us at PuppetConf 2014 <http://www.puppetconf.com/>, September > 22-24 in San Francisco* > *Register by May 30th to take advantage of the Early Adopter discount > <http://links.puppetlabs.com/puppetconf-early-adopter> **—**save $349!* > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/f08abda4-ccab-47ea-bc14-1759c3ccbfba%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
