Darius Jazayeri commented on TRUNK-2588
Current status summarized at https://groups.google.com/a/openmrs.org/group/dev/browse_thread/thread/d8591bdd35c318ec
I’m going to put this ticket on hold and work on merging the provider branch back into trunk, before committing this refactoring. (See TRUNK-2688)
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
···
---------- Forwarded message ----------
From: Friedman, Roger (CDC/CGH/DGHA) (CTR) rdf4@cdc.gov
Date: Sun, Sep 25, 2011 at 4:15 PM
Subject: [OPENMRS-DEV] Generic mechanism for doing Attributes and Attribute Types on many classes. (Review code, and Refactor.)
To: openmrs-devel-l@listserv.iupui.edu
Darius –
Can’t reply on the Google group – not enough permissions even to request to join.
I think it would be better to define a custom datatype object that included persistence, allowing multiple handler objects for rendering and validating and specifying widgets (if necessary). That would assure that all handlers of the same datatype use the same “flattening” mechanism (did you see my wiki comments the other day?) It would get fromPersistedString and toPersistedString from CustomDatatypeHandler, the CustomDatatyped interface and the CustomValue interface. (There’s got to be better names than “PersistedValue” and “ObjectValue”, maybe “ValueText” and “Value”. Use the same word in the handler method. Three things to distinguish – the custom datatype object, the custom datatype persisted string, and the custom datatype short string representation.) You could have one version of the x-ray object that persisted images to OS files and another version that persisted images via PAX API calls and another that uses REST.
I am having a little trouble figuring out where the get/set methods for datatype attributes belong and the relationship between the Hibernate DAO objects for the 3 use cases (object attribute, complex obs, global property) and the case 2 tables from my wiki comments (tables containing datatype attributes). For example, if the datatype object gets a call to return its persistence string to one of the 3 use cases (object attribute, complex obs, global property) for storing, it should also trigger the persistence methods for case 2 tables and external object stores. I would be interested in hearing from Burke whether he thinks associated attributes would be kept as separate obs in an obs group leaving the complex object as nothing but the blob part, or whether he thinks associated attributes would be part of the complex object.
I gave some thought to separating the persistence of the object from the definition of the datatype into a separate persistence object. In other words, the relationship handler-datatype-persister recapitulates the 3-tier design pattern. That way the persister could handle the change between OS files and PAX API calls and REST. But I don’t think that can be addressed until the associated attributes question is answered.
Could you add some narrative about how each of the 3 use cases (object attribute, complex obs, global property) persist their datatype, handler and handler config and how these items make their way into the object tree of CustomDatatypes? I am a little hazy about whether handler config operates at the value or datatype level. For example, if you had a custom datatype with a tree structure, could handler config be used to persist the appearance of the tree (which branches expanded, collapsed) the last time the value was selected for a particular complex obs?
Could you put this on a wiki page? If I get some time this coming week, I’d like to do a UML diagram or in Gliffy. I know you don’t see much value in them, but I would find it helpful.
Could you write up the XML to get the datatypes instantiated at runtime? Is there a way we can include a reference to the handler’s widgets at the same place to tie these things together?
Finally, I’d like some commitment that PersonAttribute APIs will be carried forward when PersonAttribute is converted to the new paradigm and default handlers for currently implemented types would have the same behavior as currently. I’d prefer a commitment that the data structure would remain the same as well, even if it means carrying deprecated information. Either that or scan all the modules for their use of PersonAttribute.
I wish I had more time to work on this today, but I don’t.
Saludos, Roger
From: Darius Jazayeri (Commented) (JIRA) [mailto:jira-trunk@openmrs.org]
Sent: Saturday, September 24, 2011 4:12 PM
To: Friedman, Roger (CDC/CGH/DGHA) (CTR)
Subject: [OPENMRS-JIRA] (TRUNK-2588) Generic mechanism for doing Attributes and Attribute Types on many classes. (Review code, and Refactor.)
–
Knut Staring
Informatics, U. of Oslo
+4791880522