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 > <a...@lab42.it<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 puppet-dev+...@googlegroups.com <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 > a...@puppetlabs.com <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 puppet-dev+unsubscr...@googlegroups.com. 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.
