search

phylotastic / phylotastic-portal

Web tool (ruby on rails) providing access to phylotastic services for acquiring species trees.
https://github.com/phylotastic/phylotastic/wiki
1 stars 3 forks source link

hide unimplemented features #74

Closed arlin closed 8 years ago

arlin commented 8 years ago

Hide anything that is not fully implemented and ready for testing. The list of things to hide includes:

ducvan0212 commented 8 years ago
arlin commented 8 years ago

The portal that I am viewing has 3 options:

screen shot 2016-04-21 at 6 20 27 pm

which of these are implemented? Do you have other ones that are not running on the server?

arlin commented 8 years ago

If you are just about to finish "from your own list", then please keep it.

ducvan0212 commented 8 years ago

@arlin These 2 cases are implemented screen shot 2016-04-21 at 4 37 20 pm screen shot 2016-04-21 at 4 37 11 pm

The option "Found in ..." was already hiden as it is not implemented so for now, you can only find a subset of species that has genome sequence in NCBI.

arlin commented 8 years ago

OK, but in trees/*/edit we still need to hide (1) choice of source (we only use OT), (2) the checkboxes for branch lengths and images (as images are automatic),

ducvan0212 commented 8 years ago

I will do that after the database is reset.

On Thu, Apr 28, 2016 at 10:19 AM, Arlin Stoltzfus notifications@github.com wrote:

OK, but in trees/*/edit we still need to hide (1) choice of source (we only use OT), (2) the checkboxes for branch lengths and images (as images are automatic),

— You are receiving this because you were assigned. Reply to this email directly or view it on GitHub https://github.com/phylotastic/phylotastic-portal/issues/74#issuecomment-215482565

arlin commented 8 years ago

This is not yet done. We are still seeing unimplemented options in the trees/*/edit view.

ducvan0212 commented 8 years ago

87 @abusalehmdtayeen wants to test more before he resets his service. I have to wait for him

arlin commented 8 years ago

I don't see how this depends on #87. The goal of hiding unimplemented features is that we want to create a version of the portal for testing and improvement. We want a version of the portal where every feature works at least 90 % of the time.

ducvan0212 commented 8 years ago

Prof. @arlin, I can remove records in database right now for you but this is NOT a test version because the database for now is not reset. I expected a database reset from last week so you can have a clean database for testing (and a clean database means no more errors from previous development) but Abu wants more time to test and reset his service. If I do my database reset first then old records in current Abu's service will be imported to new database => dirty again.

ducvan0212 commented 8 years ago

I will remove records in current database so you can see the portal as you expect.

arlin commented 8 years ago

@ducvan0212, I think you are mixing up two issues. One of them is hiding interface features that are not implemented. The other is resetting the database when we change the list requirements for an ISO-compliant date. Please explain to me how it is impossible for you to change what the interface looks like without resetting the database. If you have to reset the database every time you re-launch the portal, that is a design flaw.

ducvan0212 commented 8 years ago

(1) choice of source (we only use OT) => Phylo source is taken from database and then rendered in interface. Anyway, I removed all the trees associated with Phylomatic and TreeBase.

(2) the checkboxes for branch lengths and images (as images are automatic) => This will be hidden because it is just in interface.

The problem is tiny. Doing this take just a few seconds. The point is I expected I would do these modifications right after the database reset which was planned from last week.

arlin commented 8 years ago

Please explain #1 further. Are you suggesting that the choices are not hard-coded in the interface, but are taken from a database that is external to the portal?

ducvan0212 commented 8 years ago

The source of phylo tree is OpenTree, Phylomatic and TreeBase. There are 3 records in table PhyloSource in database respectively to each source. When you open tree creating interface, these records are fetched from database and rendered in selection box. When you click 'create tree', a new tree is created with association to id of one of these three records.

I removed the recored for Phylomatic and TreeBASE and all the trees associated with these records so you can see only OpenTree in selection box of tree creating view.

ducvan0212 commented 8 years ago

These sources can be hard-coded in interface only. I agree but if I code this way, I have to do extra work that is verification that the user input is in the range of OpenTree, Phylomatic and TreeBase or not.

ducvan0212 commented 8 years ago

For example, you can send a request to ask the portal generate a tree from OpenTree but if I inspect elements in the browser and change tree source field in tree creating form to "abcdef" then that will cause errors when there is no verification in server side.

Moreover, if you want to manage the source of tree in a web interface (assume you are an admin and you can access administration pages), I can display phylo source by extracting record from table in database, allow you delete or edit these source and update them to database. If I save phylo source by a string field in Tree table, I dont think implementation management phylo source will be a trivial task as it should be.

ducvan0212 commented 8 years ago

Sorry for my bad English, Professor. I tried my best to describe my design choice. If you are still confused about anything, I will answer as soon as possible and make any changes if it is sound.