Issue #6752 has been updated by Daniel Pittman.
Tracker changed from Feature to Bug
OK, after discussing this with a bunch of people we identified the
following specific requirements:
* rendering for humans must be available to third parties extending faces.
* rendering for humans must be available when adding an action to an
existing face.
* rendering for humans should not require adding a second file (eg:
inline rendering.)
* rendering for humans must not break users of the Ruby API.
* rendering for humans must not break faces over non-CLI (eg: web,
STOMP, MCollective.)
To implement this we have the proposed API:
<pre>
action :example do
when_invoked do |a, b, c|
# whatever
return my_data
end
when_rendering :for_humans do |returned_data|
# perform whatever transformation you desire on returned_data here, and...
return "human friendly version of the data"
end
end
</pre>
This is an extensible model: you can also hook, for example,
`when_rendering :json` using this model, and perform similar arbitrary
transformations based on the target format, without requiring users to
request it.
Additionally, we will have a `default_format` for the face, and
perhaps the action, that will default to `:for_humans` when the CLI is
run, but will default to `:json` or some other machine-focused format
when the HTTP or STOMP API is in force. (A global CLI switch to
prefer machine format data will be added, too.)
Faces that specify an explicit default format will just use that,
whatever facade they have.
Finally, we will implement some sensible default rendering in the
command line for folks who *don't* specify their own rendering hook:
* return a `String` and you get printed directly, no modification.
* return a `Hash` and you get printed as a "table" to the screen.
(no bars, just whitespace alignment.)
* return anything else (including an array) and you get `pp object` printed
That has fairly reasonable behaviour out of the box, presents useful
data as well as we can, and makes it easy for people to do useful
transformation in their render methods, too. Also, it means that if
someone is enthused to return a rich object and implement
`pretty_print` they get the right™ behaviour there, too.
The only thing undecided at this point is what to call the
`:for_humans` rendering mode; I have no better idea, but don't
over-much like that name. Suggestions welcome.
----------------------------------------
Bug #6752: Allow action-specific render methods
https://projects.puppetlabs.com/issues/6752
Author: Paul Berry
Status: Accepted
Priority: Normal
Assignee:
Category: interfaces
Target version: 2.6.x
Affected Puppet version:
Keywords:
Branch:
The current implementation of interfaces allows a render method to be specified
at the interface level but not at the action level. (The render method is in
fact specified in the application file, not the interface file).
This is unfortunate because not all actions in the same interface generate the
same kind of output, so it does not necessarily make sense to have their output
rendered in the same way. For example, "puppet catalog find" generates a
catalog, which should probably be rendered as YAML or JSON, whereas "puppet
catalog select" generates a list of resources.
It would be nice if interface-specific render methods could be specified in the
declaration of the interface, and action-specific render methods could be
specified in the declaration of the action.
The current implementation works around this situation by having "puppet
catalog select" direct its output straight to stdout (instead of returning
it)--this means that "puppet catalog select" cannot be effectively used from
within Ruby.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" 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-bugs?hl=en.
