[ImageJ-devel] Tables / TableDisplays / ResultsTables as input parameters

[Curtis Rueden]

Hi Lee,

Two years later!

> I've tried using TableDisplay as an input and it works adequately, but
> I'd like to conform to the standard and avoid creating two ways of
> asking for table inputs and outputs.

In the short term (by some definition of "short"...), it is fine to use
either TableDisplay or ResultsTable as an input. I agree it is annoying to
have two ways of asking, but that is the current situation with the API as
things stand.

In the longer term, the next design iteration of the SciJava display model
will eliminate the Data/DataView/Display/DisplayViewer stack in favor of
something much simpler [1]. Then we will just have ResultsTables—it would
be rare indeed to need any sort of TableDisplay as input.

> future developers might suffer from the ambiguous nature of
> TableDisplay - which of the tables should be used for an operation if
> there are more than one?

Yes, I think it was a mistake to make Displays be Lists. That will be
remedied in the next design iteration: a Display displays one thing at a
time. If you need a Display that shows a list of things, type it on a List
and support that on a per-Display basis.

> The problem with using ResultsTable as an input is that it's not
> registered in the ObjectService.

That is a good point. Right now the reference counting stuff is part of
Data/AbstractData, so anything built on that inherits the reference
counting. We might want to do reference counts for tables so that we can
manage them in the ObjectService. Another possibility would be to enhance
the ObjectService to support weak references for some things, so reference
counting stops being needed—that comes with its own dangers though.

Filed an issue for it!
https://github.com/imagej/imagej-common/issues/55

Regards,
Curtis

[1] https://github.com/scijava/scijava-common/issues/157


On Fri, Jul 19, 2013 at 9:11 AM, Lee Kamentsky <leek at broadinstitute.org>
wrote:

> Hi all,
> I have a command plugin that needs a table as an input parameter. There
> are plugins in the code base that take tables as output parameters (e.g.
> imagej.core.commands.display.ShowLUTAsTable), but I can't find an example
> of one as an input parameter. A ResultsTable is used as an output parameter
> in ShowLUTAsTable; an alternate choice might be to use a TableDisplay
> instead. Commands use ImageDisplay as an input - it would seem symmetrical
> to use TableDisplay for tables. I've tried using TableDisplay as an input
> and it works adequately, but I'd like to conform to the standard and avoid
> creating two ways of asking for table inputs and outputs.
>
> The problem with using ResultsTable as an input is that it's not
> registered in the ObjectService. I think the situation is simpler than for
> Data objects which have reference counts. The controlled type of a
> Display<T> is wholly owned by the display, so no reference count is needed
> and the Table can be added and removed from the ObjectService as it's added
> or removed from the Display via ObjectCreated and ObjectDeleted events.
> Perhaps this could be done in AbstractDisplay and be similarly applied to
> views? I guess you could sign me up for the work since I'll end up using
> and testing it.
>
> Alternatively, I am fine with using TableDisplay as input and ResultsTable
> as output, although future developers might suffer from the ambiguous
> nature of TableDisplay - which of the tables should be used for an
> operation if there are more than one? I think using TableDisplay as input
> and output is the best choice if ResultsTables aren't added to the
> ObjectService and existing plugins with ResultsTable outputs should be
> modified to output TableDisplay instead so that all ImageJ object parameter
> inputs and outputs can be fetched using the ObjectService.
>
> --Lee
>
> _______________________________________________
> ImageJ-devel mailing list
> ImageJ-devel at imagej.net
> http://imagej.net/mailman/listinfo/imagej-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20150821/419c113b/attachment.html>