But then I lose the advantage of using a generic type other commands/people
can understand.
E.g. I am now at the stage where I want a nice format for a Map>.
First of all it is generic so I have to make up a type.
Once I do that it is less usable...
Maybe make a "ConfigurationMap extends Map>"
return!
When you print you go around the formatters engine and you cannot pipe as
nicely.
The shell API is designed for returning results from command methods. These
can be complex objects which are much better for piping between commands
than strings on sysout. The formatter engine only kicks
Ok, but the formatter doesn't always do what I want.
Right now I return an array of objects and I want the Converter.INSPECT
level of detail when printing each item in the array.
The formatter uses Converter.INSPECT level for the array, but
Converter.PART or Converter.LINE for each item.
So what
On Fri, Jan 18, 2019 at 10:39 AM Todor Boev wrote:
> Ok, but the formatter doesn't always do what I want.
>
> Right now I return an array of objects and I want the Converter.INSPECT
> level of detail when printing each item in the array.
> The formatter uses Converter.INSPECT level for the
Hi,
When implementing a Gogo shell command are there any rules of thumb on
whether I should return a result from the command method or print it on
System.out? Possibly using the CommandSession to format it first.
What bothers me is that AFAIK the automatic printing of return values from
command
5 matches
Mail list logo