Hi @wyclif I have been exploring various openmrs modules, trying to understand the work flow. I completely agree that there is a need for a generic tagging mechanism. It will help in categorising and managing various domain objects. This is what i understand we need to achieve:-
- Creating a tagging api with a tag object, its service class containing methods such as getAllMembers(), getCout(), getType() etc., and DAO method with hibernate to run queries on database.
- Liquibase changesets to introduce a new table to store tagging data.
- The module include the uiframework and the uilibrary. Working on fragments such as a admin tag page with search, filter(api modified for filters) and categorising display.(something like that of the chart search module).
- Separate fragments for adding tags, editing tags, deleting tags, managing tags
- Creating similar fragments to add and manage tags for legacy-ui (extra credit)
Will we be having a void/unvoid/purge workflow for tags(accordingly display will need to be modified)
Will we be hardcoding the domain objects or do we plan to make that aspect generic as well. Wherein we can have an option in the preferences fragment where you can add domain objects. So if we plan to add more domain objects in the future we can easily modify the tag api to work for them
The api with the db handling, db changes and basic UI framework will be the basic requirements. After that I wanted to know the priorities of the different features of this module. Like implementing Lucene, creating fragments for the legacy UI module, integrating it with the refapp by making ui changes and modifying the rest services. I’m working on the UI mock ups and will have them up soon.
Regarding the UI, how about bootstrapping it. There have already been talks regarding moving to bootstrap. twitter-boostrap-for-refapp
You mentioned about “Ability to disable tagging application” and " let the developer decide the orientation of the list of tags". How about creating a separate preferences page in the admin section where a developer can modify views, engage/disengage filters and set other settings.
Will there be a need of a history to view all old tags which have been set or deleted ??
I have some mock ups ready. they are planned according to the ref-app.
Also for the Data Model we could include 2 tables:-
object_type[doubt: it can be int or varchar. we can assign different no. for different domain objects like encounters, obs, visits, patients etc]
reference:- Generic Tagging Mechanism, Lucene Seach