Add Screens/Plates/Wells
ppouchin opened this issue · 3 comments
To solve GReD-Clermont/omero_macro-extensions#13, wrapping screens, plates and wells would be mandatory.
@romainGuiet The "hcs" branch now has screens, plates, wells, plateacquisitions and wellsamples.
However, the last 2 are a little bit "bugged": Plate Acquisitions can be tagged, but nothing happens because the "attachAnnotation" from the Java gateway method does not work with these objects (so nothing happens), while Well Samples work with this method, but retrieving annotations does not.
Moreover, I'm thinking about deprecating Client::getProject(Long id) (and similar for datasets or images) in favor of Client::getProjects(Long... ids) which would help reduce the number of methods, but could be bothersome.
Otherwise I should add Client::getWell(Long id) (and similar for other HCS data), but it will increase the number of methods.
Alternatively, my problem being that "Client" is a big class, I was thinking of making an abstract "GatewayWrapper" class implementing the connection logic, and focusing the "Client" class on browsing data (while inheriting from the GatewayWrapper)...
Hi @ppouchin , Thank you so much for your swift answers, all the new implementations, it's much appreciated!
However, the last 2 are a little bit "bugged": Plate Acquisitions can be tagged, but nothing happens because the "attachAnnotation" from the Java gateway method does not work with these objects (so nothing happens), while Well Samples work with this method, but retrieving annotations does not.
An informative "error message" might be enough for now?
Moreover, I'm thinking about deprecating Client::getProject(Long id) (and similar for datasets or images) in favor of Client::getProjects(Long... ids) which would help reduce the number of methods, but could be bothersome.
Otherwise I should add Client::getWell(Long id) (and similar for other HCS data), but it will increase the number of methods.
It would make sense indeed
Alternatively, my problem being that "Client" is a big class, I was thinking of making an abstract "GatewayWrapper" class implementing the connection logic, and focusing the "Client" class on browsing data (while inheriting from the GatewayWrapper)...
I ping @lacan who is currently working on a QuPath-Omero connection, so maybe we could have "convergence" of classes 🤔