Closed mfrasca closed 6 years ago
after all, I do not think we can achieve a decent behaviour with just enhanced Tags.
I to think we could add a db.withEvents
base class, next to db.withNotes
, and an Event
base class from which to derive our concrete classes. In this optics, we would search for Event
objects, without specifying what kind of event. But as you can see, I'm thinking of a database schema enhancement, outside of 3.1.
I also do think that the user interface to adding notes to Tag
objects is quite interesting, and that it could also be applied to Location
and Contact
, or maybe just the latter.
thinking of the NoSQL project, maybe we can do something less radical and equally flexible?
I am considering adding a new
Event
class, which would be totally Notes-based. I'm not so sure how this would actually be so much different from aTag
, maybe in that anEvent
would be navigated in both directions, while Tags can only be followed from Tag to Object. I'm still thinking about it. Some events would be applicable to individual Plants, some relative to the whole Accessions, maybe even to Locations, but the whole idea is that a single event would apply to multiple database objects, just like we already haveTags
.Maybe adding navigation from Object to Tag could be enough?
If we add a new
Event
base class, and the three derived classes AccessionEvent, PlantEvent, LocationEvent, we are already able to store such things in the database, we can already write queries for them, we only need a flexible user interface.If we don't add anything to the database, we could simply enhance the Tag editor.
The user interface could be a very simple scrollable window, with a sort of a input grid: field-name (Label), field-type (Entry), field-value (Combo), remove-this-row (Button); each element could be removed if the user wishes to, and new rows could be added. it would default to as many rows as the different note categories for the class. and this would be it.
The current Tag editor is extremely simple, and still does not provide space for editing notes (#321). we could do it as above sketched, and see where we land.