dhis2-devs team mailing list archive

[Knut Staring <knutst@xxxxxxxxx>]

---------- Forwarded message ----------
From: Friedman, Roger (CDC/CGH/DGHA) (CTR) <rdf4@xxxxxxx>
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@xxxxxxxxxxxxxxxxxx


 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@xxxxxxxxxxx]
*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.)
****

** **

****

****Darius Jazayeri<https://tickets.openmrs.org/secure/ViewProfile.jspa?name=djazayeri>commented
on [image:
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 **
**

** **



-- 
Knut Staring
Informatics, U. of Oslo
http://hisp.uio.no
+4791880522