Always request all study vocabs #342
Conversation
src/main/java/org/veupathdb/service/eda/ds/core/AbstractPlugin.java
Outdated
Show resolved
Hide resolved
src/main/java/org/veupathdb/service/eda/ds/core/AbstractPlugin.java
Outdated
Show resolved
Hide resolved
|
now tested w boxplots, cleaned up some, ready for final review |
There was a problem hiding this comment.
Can't say I understand a lot of the interaction between the collection metadata and the R function calls. It occurs to me that we have an awful lot of R API stuff in here that could maybe be factored into some sort of RPlotClient class, instantiated with the default subset or something? Would be nice to limit the stuff in AbstractPlugin to just providing an API to get the required data and deliver the generated results back to the web client.
| ); | ||
| new StreamSpec(DEFAULT_SINGLE_STREAM_NAME, outputEntityId) | ||
| .addVars(plotVariableSpecs) | ||
| // TODO can we make this automagical? |
There was a problem hiding this comment.
Not clear to me what you want to be automagical? We probably can with some inheritance if you want to generalize some things. Just hit me up on slack if you want to discuss. Looks like there might be a lot of repetition/cut-and-paste in some of these plugins which we would like to avoid.
There was a problem hiding this comment.
there is a lot of repetition, and i hate it, and every time i think about improving the situation it seems to turn into a can of worms.. i start thinking things like 'well in an ideal world id actually be doing some entirely other thing' and things spiral out of control. so if you have ideas, id be open to hearing them
me neither 😸 happy to move stuff out of AbstractPlugin. i was also thinking some of that probably is better off in edacommon |
this, together w VEuPathDB/veupathUtils#32, should fix the issue w the histo seen in VEuPathDB/veupathUtils#31
depends on VEuPathDB/EdaCommon#49
depends on VEuPathDB/plot.data#237
needs testing yet