Skip to content

Generalized Function run GUI and argument declarations

J. Christopher Anderson edited this page Jun 17, 2014 · 3 revisions

Mainly for Max: like with Sharable Editor, I think we can have a generalized Function execution GUI in Clotho and thereby avoid having to make custom GUIs for every Function. A Function declares its arguments and their type. Effectively, they define a Schema, and you have already successfully been able to contruct a GUI provided a Schema. So, having a GUI in which you declare the arguments for a 'run' is indistinguishable from the SharableEditor. The only difference is the output, which must be added and visually distinguished. The Schema of the output is also declared by the Function (though it is not currently captured in the Function SharableEditor). Thus, the appropriate visual presentation of the output can also be deduced by inspection of the Function.

When a user types 'revcomp' into the searchbar, it is first trying to confirm which tool they really meant, and that is the purpose of autocomplete. Once a user has picked a tool, ideally the searchbar is contextualizing the remaining suggestions or providing hints about how to express arguments. One challenge here is that conversion will also take place and thus the user might not really need to provide all the information asked for by the algorithm. In terms of how Functions are written, what I already see us doing, and what I think is actually the right solution, is for Functions to only take in as argument the information they actually care about to complete their task. For example, PCRPredict just needs three Strings, and perhaps indication of their strandedness. The simplest definition of a sequence object would be:

{
"sequence" : "atcgRNSDWu",
"isCircular" : true,
"isSingleStranded" : false
}

And that is all a PCRPredict algorithm really cares about, and thus it should declare that as the Schema for its three sequence arguments rather than a NucSeq, Polynucloetide, SBOL, etc. Note that this circularity and strandedness info is not captured in SBOL, so this is a distinct Schema. And it throws out much of the other info (annotations, notes, etc.) that are included in NucSeq and Polynucleotide.

So, philosophically, the Schemas chosen as arguments for a Function should try to reuse existing Schemas (for convenience and avoiding duplication of code) but the Schema should best capture the information required of the Function, and that is the principle concern. Converters can take care of the interoperativity.

If Functions are written this way, then the automatically-generated GUI should come out the way that will make sense to the user: they just need to supply the minimal information required as defined by these schemas.

Clone this wiki locally