Here is the approach I proposed on the ticket below (generalized for
OpenMRS rather than specific to reporting). To answer your specific
questions:
_Are tags simple Strings or objects (with uuid? with id?)?_
They are Objects (specifically OpenmrsMetadata), but can look like / act
like Strings in practice (eg. in a UI). The main reason for making them
metadata is so that they can sync between instances and so that we could
potentially add a translation layer on top of them (eg. metadata
localization). We could also add additional metadata around them like
"these tags are appropriate for Locations. these are appropriate for
Reports")
_Can users (with permissions) simply create new tags are is tag creation
separate from assignment?_
Tag creation would be separate from assignment in this model.
Permissions for tag creation and tag assignment would be distinct.
_
Do we need to support localization of tags? If so, who is translating
them?_
Yes. The same person will translate them as would translate any other
piece of OpenmrsMetadata object (which is currently not possible, but
would ultimately be done by an end-user in the UI).
_Do we add tags as a property of OpenMRSObject?_
We could do, but I would not imagine so. This can always be added later
on if desired. For now, I am proposing a TagService which would allow
you to get the tags for an Object on demand.
*Design below:*
Tag extends OpenmrsMetadata {
Integer id;
String uuid;
String name;
...
}
tag (
id int(11) primary key,
uuid char(38) not null,
name varchar(100) not null,
...
)
openmrs_object_tag (
openmrs_object_uuid char(38) not null,
tag_id int(11) references tag.id
unique key definition_tag_unique_key (definition_uuid, tag_id)
)
TagService {
List<Tag> getTagsForType(Class<? extends OpenmrsObject> type);
List<Tag> getTags(OpenmrsObject object);
// Standard crud methods
Tag getTag(Integer id);
Tag getTagByUuid(String uuid);
List<Tag> getAllTags();
Tag saveTag(Tag tag);
void purgeTag(Tag tag);
}
Mike
On 04/12/2012 01:31 PM, Burke Mamlin wrote:
+1000 for having at least some fundamental agreements on our approach
to tagging (e.g., wiki page <https://wiki.openmrs.org/x/cgM3AQ> and
TRUNK-2284 <https://tickets.openmrs.org/browse/TRUNK-2284>), so that
we don't end up with dealer's choice on what tags mean across OpenMRS.
There are many potential places for tagging through OpenMRS and modules.
Can we discuss this on a design call or on this list? As long as we
align on these things, we can change our minds later and have a clear
path to refactor.
* Are tags simple Strings or objects (with uuid? with id?)?
* Can users (with permissions) simply create new tags are is tag
creation separate from assignment?
* Do we need to support localization of tags? If so, who is
translating them?
* Do we add tags as a property of OpenMRSObject?
Cheers,
-Burke
On Thu, Apr 12, 2012 at 10:14 AM, Roger Friedman (Commented) (JIRA)
<[email protected] <mailto:[email protected]>> wrote:
Roger Friedman
<https://tickets.openmrs.org/secure/ViewProfile.jspa?name=r.friedman>
commented on New Feature REPORT-49
<https://tickets.openmrs.org/browse/REPORT-49>
*Add a mechanism for tagging / categorizing reports and other
reporting elements* <https://tickets.openmrs.org/browse/REPORT-49>
I agree that more translation mechanisms need to be available for
metadata. I was somewhat involved in the GSOC project. It tries to
handle translation within the existing data structures, but the
result is that text fields can no longer be sorted, I think
problems like this are why it hasn't been introduced even though
it worked to specs.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
administrators
<https://tickets.openmrs.org/secure/ContactAdministrators%21default.jspa>.
For more information on JIRA, see:
http://www.atlassian.com/software/jira
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
_________________________________________
To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
[email protected] with "SIGNOFF openmrs-devel-l" in the body (not
the subject) of your e-mail.
[mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
