GSoC 2017-Generic Tagging Mechanism

Hi everyone, I found this project quite interesting and hence starting this thread to discuss more on it!

In the project objective it states: “Implement a reusable fragment for the UI framework that can be included on a create/edit page of any domain object to allow a user to manage its tags, it would also be nice if the fragment can let the developer decide the orientation of the list of tags i.e vertical vs horizontal.” I didn’t really understand this. Does this allow the user to manage the tags already made, add or delete the tags and change the value of the tags? Also, orientation of all the tags that are made totally?

I’ve done coursework in Java and MySQL and projects in the same, however I have not used them together. Are there any specific topics in Java (or SQL) that I should focus on improving(I’ve also not used lucene before)?

Thanks a lot! :slight_smile:

1 Like

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:-

  1. 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.
  2. Liquibase changesets to introduce a new table to store tagging data.
  3. 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).
  4. Separate fragments for adding tags, editing tags, deleting tags, managing tags
  5. Creating similar fragments to add and manage tags for legacy-ui (extra credit)

Questions:-

  1. Will we be having a void/unvoid/purge workflow for tags(accordingly display will need to be modified)

  2. 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

  3. 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.

  4. Regarding the UI, how about bootstrapping it. There have already been talks regarding moving to bootstrap. :slight_smile: twitter-boostrap-for-refapp

  5. 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.

  6. 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:- tag tag_id(INT(10)) description(VARCHAR(255)) creator(VARCHAR(255)) date_created(VARCHAR(255)) deleted(timestamp(19)) deleted_by(user_id)

tag_map tag_id object_type[doubt: it can be int or varchar. we can assign different no. for different domain objects like encounters, obs, visits, patients etc] object_id

reference:- Generic Tagging Mechanism, Lucene Seach

3 Likes