[Freeipa-devel] freeIPA v2: Changes to output_for_cli() signature

[Dmitri Pal]

Simo Sorce wrote:
> On Sun, 2008-11-16 at 21:41 -0700, Jason Gerard DeRose wrote:
>   
>> The output_for_cli() method signature has changed from:
>>
>>   output_for_cli(self, result)
>>
>> to:
>>
>>   output_for_cli(self, textui, result, *args, **options)
>>
>> Rob had the excellent idea of passing the args and options the command
>> was called with (thus the new *args, **options in the signature).
>>
>> I've been thinking about how output should be formatted when a command
>> is called through the CLI, and my conclusion was that we really don't
>> want commands using the print statement directly... we want the commands
>> to provide a consistent experience to the user, and that's too difficult
>> to do if every command does its own output totally willy-nilly.
>>
>> So I started work on a new "textui" backend plugin. The goal is to
>> provide maybe a dozen or so high-level methods for common output
>> scenarios, and then have each command's output_for_cli() method use only
>> this textui API. This way we can tweak the CLI output by just modifying
>> the textui plugin, but have it affect all the commands simultaneously.
>> This textui plugin will also do things like determine the tty width and
>> word wrap appropriately.
>>
>> The textui plugin is in ipalib/cli.py
>>
>> The best examples so far of using textui are probably the "env" and
>> "plugins" commands in ipalib/plugins/f_misc.py
>>
>> I also added two related sections in the tutorial.  I still haven't
>> figured out how to make epydoc include anchors, but the two new sections
>> are named:
>>
>>   "Allowed return values from your command"
>>
>> and
>>
>>   "How your command should print to stdout"
>>
>> They are about half way down the page. As always, the latest build of
>> the tutorial can be found here:
>>
>>   http://freeipa.org/developer-docs/ipalib-module.html
>>
>>     
>
> This is an excellent idea!
> It is indeed fundamental that we do not do any printing directly, but
> let application developers choose how to mange the output.
>
> Thanks,
> Simo.
>
>   
Yes makes sense. +1.