Skip to end of metadata
Go to start of metadata

Based upon the Taverna 1 renderers, translate/refactor for use within the T2 Preview plugin. Renderers should follow an SPI pattern, and be discovered by being matched to the mime-type of the workflow output data. Avoid dependencies on the original T1 code-base.

Currently mime-types are not stored in the translated T2 dataflow, though the annotation type. It should be investigated whether to use these annotations now, or refer back to the original scufl model to determine the mime-type (but be done in a flexible way such that it can easily be updated to use the annotations in the future).

Requires some UI changes to the T2 Preview perspective to allow the rendered result to be displayed in a suitable fashion. 

  • Determine how to handle mime-types. 4hr
  • Convert 1 renderer for use in T2 (image would be good). 4hr
  • Add ability to click on the result and view the rendered result. 8hr
  • Build into existing perspective. 4hr
  • Convert the remaining renderers based on the previous one. 8hr
  • TOTAL = 28hr

Part 1 - The Activities have a Configuration Bean, if this Bean extends the ActivityPortDefinitionBean then the mime-types are stored during the call to the translator.  Beanshell works like this.  However, if it does not extend the ActivityPortDefinitionBean (and most don't since it is an arbitrary parameterized object in the AbstractActivityTranslator then the mime-types are not automatically stored and must be forced in somehow.

One way could be to put extra code in the WorkflowModelTranslator to handle the mime-types when creating the output ports from the ScuflModel.  An idea was to add them as an annotation on the DataflowOutputPort, making a call in the createOutputs method of the translator like edits.getCreateDataflowOutputPortEdit(dataflow, sinkPort.getName(), sinkPort.getMetadata().getMIMETypeList()).doEdit() and then doing outputPort.getAddAnnotationEdit(--new mime-type Annotation--) for each DataflowOutputPort. However, the MimeType code would need a MimeType assertion etc. and we are not sure how this will all be done (there are only interfaces at the moment). So....

in the T2Plugin component you can get the mime-type from the actual SCUFL model, create a map of mime type to port name and pass this down to the result model.  The result model can then compare it's port name (from the data token flowing through it) and then get the mime type.  It then gets passed to the result tree node which can then render the result correctly in a lovely pop-up.

  • None
  1. 2008-02-21

    Renderer code checked into CVS.  Not all types complete yet but JMol, SVG, Image, Text, Text/HTML, Seq Vista & XMLTree should be OK.

  2. 2008-03-12

    All from T1 except CollectionAsTable added.

  3. 2008-03-12

    There is an issue with the AWTComponentRenderer causing the DataFacade to throw an Exception because it doesn't know what a Component.class is.  The T2plugin probably needs to handle the error better since even if a renderer throws an exception it doesn't mean that another one can't render it.

  4. 2008-03-13

    The AWTComponentRenderer seems a bit out of place at the moment.  Not really sure how it fits in with the pattern of resolving by mime type since it will never work with  the DataFacade resolve method unless we change how we do things.  I have stopped it from being discovered for the moment.