Hi All,

On our last few design calls we've been working through the generic
AttributeType mechanism that we're introducing in 1.9. (see
ticket<https://tickets.openmrs.org/browse/TRUNK-2588>
)

I wanted to summarize the current state of things. Some of this is in trunk,
but some is refactoring I'm doing. I'm especially interested in thoughts
about how these classes should be linked together with parameterized types,
since I'm not convinced I've gotten that right:

interface CustomDatatypeHandler<T>

   - Capable of converting T to/from a String that can be persisted in the
   varchar column of a database. E.g. a date would be stored as yyyy-mm-dd and
   an image might be stored as a uri pointing to a PACS system. Also capable of
   validating T, e.g. so we can use a plain java.util.Date to represent
   "date-in-past" but limit its possible values.
   - Defines a String "datatypeHandled", e.g. "date",
   "regex-validated-string")
   - T fromPersistedString(String)
   - String toPersistedString(T)
   - void validate(T)
   - String render(String persistedValue, String view)
   - can be configured with setHandlerConfiguration(String)


interface CustomDatatyped

   - holds the *definition* of a custom datatype (which is handled by a
   handler of the above interface). For example VisitAttributeType and
   GlobalProperty (we're able to do typed GPs trivially now)
   - required: String getDatatype()
   - optional: String getPreferredHandlerClassname()
      - if specified, will be handled by this specific
      CustomDatatypeHandler, otherwise it will be handled by the
default handler
      for this thing's datatype
   - optional: String getHandlerConfig()


interface AttributeType<OwningType extends Customizable> extends
CustomDatatyped, OpenmrsMetadata

   - for user-defined extensions to core domain objects, which would be
   handled by adding custom database columns in a less generic system. E.g.
   VisitAttributeType implements AttributeType<Visit>
   - datatype/handler specified via CustomDatatyped superinterface
   - Integer getMinOccurs()
   - Integer getMaxOccurs()


class VisitAttributeType, class LocationAttributeType, class
ProviderAttributeType

   - trivial implementations of AttributeType (via BaseAttributeType)


interface Customizable<AttrClass extends Attribute>

   - Implemented by domain classes that may be customized by the user via
   custom attributes. E.g. Visit implements Customizable<VisitAttribute>,
   Location implements Customizable<LocationAttribute>
   - Has convenience methods for dealing with a collection of attributes, of
   different types:
   - Collection<AttrClass> getAttributes()  //includes voided
   - Collection<AttrClass> getActiveAttributes()  //non-voided
   - void addAttribute(AttrClass)
   - void setAttribute(AttrClass)  //voids other attributes of the given
   type


interface CustomValue

   - holds a *value* managed by a CustomDatatypeHandler. E.g.
   VisitAttribute, GlobalProperty. Any implementation of this has a
   corresponding CustomDatatyped implementation. "persistedValue" is a String
   suitable for persisting in a db varchar column; "objectValue" is what you'd
   want to work with in the API.
   - String getPersistedValue()
   - void setPersistedValue()
   - Object getObjectValue()  // don't remember why this isn't <T>
   - void setObjectValue(Object)


interface Attribute<OwningType extends Customizable> implements CustomValue,
OpenmrsData

   - value corresponding to an AttributeType (which defines its datatype,
   whether it's required, whether it can repeat, etc), e.g. VisitAttribute
   corresponds to VisitAttributeType
   - OwningType getOwner()
   - void setOwner(OwningType)
   - AttributeType<OwningType> getAttributeType()


class VisitAttribute, class LocationAttribute, class ProviderAttribute

   - trivial implementation of Attribute (via BaseAttribute)


class GlobalProperty implements CustomDatatyped, CustomValue

   - this is interesting in that it both defines a custom datatype
*and*stores its value


Thoughts welcome...

-Darius

_________________________________________

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]

Reply via email to