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.
ImageJ-devel mailing list
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 . 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!
On Fri, Jul 19, 2013 at 9:11 AM, Lee Kamentsky <[hidden email]> wrote:
ImageJ-devel mailing list
|Free forum by Nabble||Edit this page|