[ImageJ-devel] Extensions Classes

[Johannes Schindelin]

Hi,

On Wed, 21 Apr 2010, Grant B. Harris wrote:

> I put together a preliminary sketch for a set of classes related to 
> Extensions, intended to spark more discussion:
> 
> http://imagejdev.org/trac/imagej/attachment/ticket/15/Class%20Diagram.png

I would suggest a few changes:

- do not make a common interface for interactive extensions (otherwise, 
  why is there no common interface for non-interactive extensions? 
  besides, what would that common interactive interface contain?)

- the interactive plugin should always just hand off to the 
  non-interactive version of the plugin. If you do not require such a 
  bonding, you will end up with non-recordable actions (or at least with 
  the same problems with headless mode as we have right now)

- do not special-case the stack processor. If you do that, you inherently 
  restrict the Processor to 2 dimensions and you get the whole problem set 
  of ImageProcessor vs ImagePlus vs ImageStack again. A processor should 
  process images, whatever image you throw at it. It _may_ throw an 
  exception (or indicate otherwise what it supports), but the extension 
  interface is not the level at which you want to discern whether it 
  handles 2D or >=3D.

- do not couple the processor with the algorithm that strictly. It should 
  be a 0..n connection. Algorithms offer a flexible Java-based API, while 
  the extension should make it possible for application frameworks to 
  discover user-specifiable parameters (sort of "AUI" -- application 
  users' interface), so they are a different kettle than the extensions.

>From the list I sent to the Skype "channel", your diagram is only missing 
the way to specify menu entries. I really would try to decouple the menu 
entry specification from the actual action behind it, so the menu 
extensions would not be processors.

Ciao,
Johannes