mfrasca
commented
9 years ago bottom info box, slightly turned inside out. it is now a notebook, each page relative to a plugin element. currently two pages: Notes, Tags. Notes is not implemented in a plugin, but is now reduced to behaving like a Tag. Tags is implemented in a plugin and its information is registered in the View at startup.
it works, it's pretty according to me, there are a few small itches that should be fixed, but I prefer looking at them as marginal issues.
This depends on issue #132 and uses the same terminology SP, pV, vP.
Tags are attached to just any object of any class. it is possible to use a tag to find back all objects associated to that tag, but, as of now, it is not possible to show what tags are associated to an object. this because the callbacks activated are relative to the row object, and the row object is not a tag. also think of
Note(actually implemented asAccessionNote,PlantNote,GenusNote,FamilyNote,SpeciesNote). if it was to be implemented as a plugin and be stored in a single table, it would fall in the same category asTag: objects associated to any other object, and displayed in their own partial plugin view.considering the above, we can—in perspective—remove the various Note classes and have only one, and generalize to tags the way notes are currently displayed.
for the time being, let's start with Tags (Notes have the additional difficulty that they are entered while editing the object they refer to, and one note is associated to one object).
so the user selects an object (a row), SP does all that is described in comments to #132 , in order to fill in pV. SP also activates one by one a different type of plugins, of which Tag if the first case, and Note could be a next one, which are displayed in a different pV_2 which stays visible the whole time.
so for Tags: a class method receives the active row, knows of pV_2, fills it in with all the Tags relative to the object. full stop, so simple as that.