>> You could in theory transfer kwalify-like specification to the
>> language ... here is a quick hack for discussion:
>>
>> class bind (
>> $options => {
>
> I imagined it being in the body, and calling a method, until we added
> syntax, but either way would work. Mostly, I figure any solution lets
> us figure out how well Kwalify is a match for our real-world needs.
Good points. This is a very non-intrusive way of experimenting with
kwalify I think. In that case we can drop the use of a file and have
the validate_resource() function take a kwalify schema (in the form of
a puppet hash) as a parameter.
> Hrm. Possibly using an explicitly scoped variable beside the class
> declaration might be a way to get this into the language without so
> much impedence mismatch in where you land the data?
>
> $example::nested::class::options = {...}
> class example::nested::class { ... }
Yeah - its important to make the schema available via REST from an
external ENC or hiera store editor ... if the data is not in a
known/obvious place that can be tapped from say an indirector of some
kind we lose some of the magic.
At the moment I've hacked on Luke's work with the resource_type API
which seemed like the most viable place to have the schema displayed.
I'm struggling to think of a way to extend this without changing core.
I mean - I could create a new indirector - but I'm not sure if its
possible to make an indirector as a plugin. Is this viable and/or a
good idea?
ken.
--
"Join us for PuppetConf, September 22nd and 23rd in Portland, OR:
http://bit.ly/puppetconfsig";
--
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.
