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:[email protected]]
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.)
[https://tickets.openmrs.org/s/en_US5j8bpc/649/92/_/images/omrs-comm-badge-200x50.png]
[https://tickets.openmrs.org/secure/useravatar?avatarId=10298]Darius
Jazayeri<https://tickets.openmrs.org/secure/ViewProfile.jspa?name=djazayeri>
commented on [New Feature]
TRUNK-2588<https://tickets.openmrs.org/browse/TRUNK-2588>
Generic mechanism for doing Attributes and Attribute Types on many classes.
(Review code, and Refactor.)<https://tickets.openmrs.org/browse/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<https://tickets.openmrs.org/browse/TRUNK-2688>)
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!default.jspa>.
For more information on JIRA, see: http://www.atlassian.com/software/jira
