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.