Refactoring and update Changes

[manuelgloeckler]

Refactorings:

• Rethink Modell - View - Controller connections
• Look over the classes and DELETE all unnecessary thinks that are already commented out, or getter/setters that are not needed. Chages:
• should windows style be chagned?
• Sample have to get Names -> add in NewSampleView new Textfield and save this.
• loading a sample with only one/two files
• Observable/Arrays?
• include Filter in the GUI

[canerbagci]

NAMING

• [ ] package names are always lowercase. including the first letter of the word
• [ ] always camelCase for variable and class names. e.g. listoffilters -> listOfFilters; or even better filterList; filtername -> filterName etc...
• [ ] Naming of Controller/Presenter/View seems a bit mixed up now. We actually have no Controller. You can name classes which bind to the FXML, as View. The classes that implement the logic are Presenters.
• [ ] Use subpackages. For example filter, gff, fasta entries etc. are all under model package. They can have their own subpackages.

DESIGN

• [ ] Model. Create a Model class that holds Observables of everything you need in the View (actually that's what Project is in your case - so you can also use the class Project for that purpose).

  • Project:listOfSamples -> ObservableList (why not just "samples"?)
  • add: filterList, filteredSamples, ...

• [ ] Everything you access in the Presenter (to be displayed in the View) needs to be an Observable. So;

  • Sample:reads -> ObservableList
  • FilteredSample:sample-> ObjectProperty, filter -> ObjectProperty

• [ ] Stick with either Passive or Classic View. Don't mix up two to be consistent. Passive View only displays stuff and has no logic at all. All logic is controlled by the Presenter. Classic View can have logic that only concerns the View part. There's only one logic at the moment, so an example based on that:

  • creating a new sample: View gets Sample model object and passes it to the controller. Even in the classic case, view should only pass the file paths, and the logic of creating a sample object should be handled by the controller. onSucceeded and onFailed events can also be listened in the Controller in this case, and Controller tells View what happened.
  • listoffilter (see above naming and model) is part of the model. View shouldn't hold any Model objects.

• [ ] For any pair of objects that you display in the View and has a corresponding Model part; Presenter needs to know connection between the two. e.g. in a Map of ViewObject to ModelObject. For example we have a Filter class in the Model and display filters in the View. The user has the ability to change filters at any time. When such a change occurs, the Presenter has to know which model object to change. So a Map<FilterView, Filter> in the Presenter will make your life easier.

• [ ] This is how I think it should work. Feel free to modify if it doesn't make sense:

  • whenever the new filter button is clicked a new FilterBuilder object created (can be part of the presenter), that has the methods you have in there currently and a Predicate field.
  • when the user is done adding the new filter/changing an existing one, view goes through all of the fields in the dialog that has a valid value, and calls the corresponding methods is the filterBuilder; which "and"s the predicates they create to the main predicate (the field above). The main predicate is empty in the beginning (return true).
  • This Predicate field is actually already our Filter object. None of the methods and fields are necessary in the Filter class. BUT, since we need to save the filters as well, there should be a String representation of the Predicate saved in the Filter class. So the Filter class can now become a very dumb class with two fields: ObjectProperty<Predicate> and a StringProperty that will be saved in the project file.

FILTER GIT

• please don't push project settings. It's different for everyone. That's why everytime you pull you get conflicts. .idea folder should not even be here. please delete it. nobody cares where you left your cursor last time you closed the project. :)

I will add more as you change. First implement some logic and I'll see how it goes. Email/respond to the issue or drop by our office if anything is unclear.

[canerbagci]

To make it more clear; I think if you implement main Model/View/Presenter classes and restrict the interaction between layers to these 3 main classes, you'll make it much easier. Right now the organization is just too messy. It's fine to have multiple Presenter classes, and you must have multiple Model and View classes anyway. But please try to organize them in "more abstract" classes.

e.g.

class Presenter -> gets initialized in Main/View. the constructor initializes FilterPresenter, MainTabPresenter, SamplePresenter etc. It know about the View and Model classes. Communicates with the View class, binds to objects in Model.

class View -> You already have this...

class Model (Project) -> It can be the Project class. Holds everything a project has (samples, filters etc). Presenter only binds to objects/properties of objects in this class. So, the presenter only knows about this class.

[canerbagci]

For GUI elements, instead of setting length, width, x, y coordinates etc (basically any property); please use bindings. For example (@manumanu12345), when you create rectangles in your chart, instead of doing newSequence.setHeight(BAR_WIDTH); do newSequence.heightProperty().bind(BAR_WIDTH_PROPERTY). For this to work, you need to change the BAR_WIDTH to IntegerProperty. This will make the height of rectangles to change whenever the value of BAR_WIDTH changes; without you having to do anything additional. Properties are observables and when you bind them, JavaFX observers them by default.