# Using CodedConceptDatatype

**URL:** <https://talk.openmrs.org/t/using-codedconceptdatatype/9987>\
**Category:** Development\
**Tags:** coreapps\
**Created:** [February 9, 2017, 2:12pm UTC](https://talk.openmrs.org/t/using-codedconceptdatatype/9987 "2017-02-09T14:12:06Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![cioan](https://talk.openmrs.org/user_avatar/talk.openmrs.org/cioan/32/8061_2.png) [@cioan](https://talk.openmrs.org/u/cioan)\
**Post date:** [February 9, 2017, 2:12pm UTC](https://talk.openmrs.org/t/using-codedconceptdatatype/9987/1 "2017-02-09T14:12:06Z")

</div>

We need to create a Provider Attribute type that uses a concept to display a list of possible answers. e.g. Education Level. I have noticed there is a new customdatatype.CodedConceptDatatype added to the coreapps and I was wondering if I could use it when creating and rendering a Provider Attribute? Please see below an example on how we used this new custom data type. Please let us know if there is a better, more general way of doing this. Thanks.

> <https://github.com/openmrs/openmrs-module-coreapps/blob/master/omod/src/main/webapp/pages/providermanagement/editProvider.gsp#L328>

---

<div class="post-metadata">

**Author:** ![darius](https://talk.openmrs.org/user_avatar/talk.openmrs.org/darius/32/8082_2.png) [@darius](https://talk.openmrs.org/u/darius)\
**Post date:** [February 9, 2017, 10:09pm UTC](https://talk.openmrs.org/t/using-codedconceptdatatype/9987/2 "2017-02-09T22:09:23Z")

</div>

> [@cioan](#):
>
> Please let us know if there is a better, more general way of doing this.

The short answer is that what you’re doing here is not the general preferred way, but we don’t actually have any modern examples that _do_ the preferred way.

The original idea, from the time of OpenMRS 1.9 is that:

- Attributes must have a CustomDatatype, and they may optionally further specify a CustomDatatypeHandler
- `CustomDatatype` does the UI-independent side of things, i.e. how to read/write the value from the database or external storage, and how to format it for simplistic display.
- `CustomDatatypeHandler` is the generic idea of a UI-specific handler, but the UI technology in question would need to be more specific about this.
- openmrs-core also defined some pretty-generic subinterfaces (HtmlDisplayableCustomDatatypeHandler and DownloadableDatatypeHandler), but these were moved to the legacyui module (probably a mistake)
- Specific UI applications should define abstract base classes or interfaces to represent the types of widgets that they know how to render, and a dev would extend these to implement the kind of UI widget that would work within that application. For example the old openmrs-web (now moved to legacyui) had FieldGenDatatypeHandler and WebDatatypeHandler, and [this part](https://github.com/openmrs/openmrs-module-legacyui/blob/1.2.3/omod/src/main/webapp/tags/singleCustomValue.tag) of the UI layer was specifically coded to support those.

So, the correct way to do what you’re doing here would be:

1. In uicommons (or uiframework) introduce an abstract class or interface FragmentIncludeCustomDatatypeHandler

2. In uicommons introduce a fragment like “valueForSingleCustomField” which is equivalent to the singleCustomValue.tag file I linked above

3. In uicommons:

4. then in your module you just do something like

Whether you actually want to do all this the right way depends on how much investment you want to be making in uiframework-backed UIs.

---

<div class="post-metadata">

**Author:** ![mogoodrich](https://talk.openmrs.org/user_avatar/talk.openmrs.org/mogoodrich/32/3324_2.png) [@mogoodrich](https://talk.openmrs.org/u/mogoodrich)\
**Post date:** [February 10, 2017, 2:21pm UTC](https://talk.openmrs.org/t/using-codedconceptdatatype/9987/3 "2017-02-10T14:21:36Z")

</div>

So to make sure I understand @darius, using the “CodedConceptDatatype” makes sense, and isa general way of doing this from a data/API level, the question is whether we want to go through the further effort of creating interfaces in the UI Framework to support editing/displaying that data type, versus using the quick else-if branch that @cioan created to just handle the edit/display in the location we need it?

Take care, Mark

---

<div class="post-metadata">

**Author:** ![cioan](https://talk.openmrs.org/user_avatar/talk.openmrs.org/cioan/32/8061_2.png) [@cioan](https://talk.openmrs.org/u/cioan)\
**Post date:** [February 10, 2017, 2:25pm UTC](https://talk.openmrs.org/t/using-codedconceptdatatype/9987/4 "2017-02-10T14:25:10Z")

</div>

Thanks @darius for explaining how all those components were supposed to work.

---

<div class="post-metadata">

**Author:** ![darius](https://talk.openmrs.org/user_avatar/talk.openmrs.org/darius/32/8082_2.png) [@darius](https://talk.openmrs.org/u/darius)\
**Post date:** [February 10, 2017, 2:44pm UTC](https://talk.openmrs.org/t/using-codedconceptdatatype/9987/5 "2017-02-10T14:44:38Z")

</div>

Yes Mark, exactly that.

-Darius (by phone)

---

<div class="post-metadata">

**Author:** ![mogoodrich](https://talk.openmrs.org/user_avatar/talk.openmrs.org/mogoodrich/32/3324_2.png) [@mogoodrich](https://talk.openmrs.org/u/mogoodrich)\
**Post date:** [February 10, 2017, 2:56pm UTC](https://talk.openmrs.org/t/using-codedconceptdatatype/9987/6 "2017-02-10T14:56:58Z")

</div>

Cool, great. @cioan I’d say if you feel ambitious go ahead and implement what Darius suggests, but it’s not worth it if it seems like a lot of work… definitely something we can put off/never do.

Mark