Re: [OpenMRS] #2273: Core should allow formentry modules to store view and resource metadata for a form

classic Classic list List threaded Threaded
9 messages Options
Burke Mamlin Burke Mamlin
Reply | Threaded
Open this post in threaded view
|

Re: [OpenMRS] #2273: Core should allow formentry modules to store view and resource metadata for a form

(Moving discussion of handling form resources back to the dev list.)

Jeremy,

  • Not sold on the "ownedByModule" attribute; if a type is module-specific, then the name should reflect it.

  • How about a `formattributetype.handler` (class name) to handle getting/setting/rendering instead of a datatype?   Or do we make datatype a class name, supporting `java.lang.String`, java.lang.Integer`, etc. -- with default handler(s) -- out of the box?

  • What are the return values for the API methods?  I don't see the purpose/need for the getFormAttributes(Form, List<FormAttributeType>, List<String> moduleIds) method.

  • Assume uuid and other audit attributes (created_by, date_created, etc.) are left out for readability

-Burke


On May 19, 2010, at 11:21 AM, OpenMRS wrote:

#2273: Core should allow formentry modules to store view and resource metadata for
a form
-----------------------------------+----------------------------------------
    Reporter:  djazayeri          |          Owner:  jkeiper        
        Type:  task               |         Status:  assigned       
    Priority:  major              |      Milestone:  OpenMRS Someday
   Component:  OpenMRS Code Base  |     Resolution:                 
    Keywords:                     |   Intro_ticket:  0              
Review_status:                     |  
-----------------------------------+----------------------------------------
Comment (by djazayeri):

So something like this:

{{{
FormAttributeType
    id
    name
    ownedByModule // optional
    datatype

FormAttribute
    id
    form
    formAttributeType
    value (blob)

FormService
    getFormAttributes(Form, FormAttributeType)
    getFormAttributes(Form, List<FormAttributeType>, List<String>
moduleIds)
}}}

--
Ticket URL: <http://dev.openmrs.org/ticket/2273#comment:13>
OpenMRS <http://dev.openmrs.org>
Collaborating toward an open-source electronic medical record system.


[hidden email] from OpenMRS Developers' mailing list
Ben Wolfe (openmrs) Ben Wolfe (openmrs)
Reply | Threaded
Open this post in threaded view
|

Re: [OpenMRS] #2273: Core should allow formentry modules to store view and resource metadata for a form

For reference, person_attribute_type.format is a value like
"java.lang.String".  This allows the person_attribute.value to be turned
into an object automatically.

Ben

On 05/19/2010 12:16 PM, Burke Mamlin wrote:

> (Moving discussion of handling form resources back to the dev list.)
>
> Jeremy,
>
>     * Not sold on the "ownedByModule" attribute; if a type is
>       module-specific, then the name should reflect it.
>
>     * How about a `formattributetype.handler` (class name) to handle
>       getting/setting/rendering instead of a datatype? Or do we make
>       datatype a class name, supporting `java.lang.String`,
>       java.lang.Integer`, etc. -- with default handler(s) -- out of the box?
>
>     * What are the return values for the API methods? I don't see the
>       purpose/need for the getFormAttributes(Form,
>       List<FormAttributeType>, List<String> moduleIds) method.
>
>     * Assume uuid and other audit attributes (created_by, date_created,
>       etc.) are left out for readability
>
>
> -Burke
>
>
> On May 19, 2010, at 11:21 AM, OpenMRS wrote:
>
>> #2273: Core should allow formentry modules to store view and resource
>> metadata for
>> a form
>> -----------------------------------+----------------------------------------
>> Reporter: djazayeri | Owner: jkeiper
>> Type: task | Status: assigned
>> Priority: major | Milestone: OpenMRS Someday
>> Component: OpenMRS Code Base | Resolution:
>> Keywords: | Intro_ticket: 0
>> Review_status: |
>> -----------------------------------+----------------------------------------
>> Comment (by djazayeri):
>>
>> So something like this:
>>
>> {{{
>> FormAttributeType
>> id
>> name
>> ownedByModule // optional
>> datatype
>>
>> FormAttribute
>> id
>> form
>> formAttributeType
>> value (blob)
>>
>> FormService
>> getFormAttributes(Form, FormAttributeType)
>> getFormAttributes(Form, List<FormAttributeType>, List<String>
>> moduleIds)
>> }}}
>>
>> --
>> Ticket URL: <http://dev.openmrs.org/ticket/2273#comment:13>
>> OpenMRS <http://dev.openmrs.org>
>> Collaborating toward an open-source electronic medical record system.
>
> ------------------------------------------------------------------------
> Click here to unsubscribe
> <mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from
> OpenMRS Developers' mailing list

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
Burke Mamlin Burke Mamlin
Reply | Threaded
Open this post in threaded view
|

Re: [OpenMRS] #2273: Core should allow formentry modules to store view and resource metadata for a form

On May 19, 2010, at 12:56 PM, Ben Wolfe wrote:

> For reference, person_attribute_type.format is a value like "java.lang.String".  This allows the person_attribute.value to be turned into an object automatically.

Cule.  That's what I was picturing for form_attribute_type.datatype.  We could have one or more handler(s) in core that knew how to get/set/render basic datatypes and then modules could add new handlers as needed.  These handlers (at least for basic types) could eventually be shared across person_attribute_type, form_attribute_type, and global_property management screens.

-Burke

>
> Ben
>
> On 05/19/2010 12:16 PM, Burke Mamlin wrote:
>> (Moving discussion of handling form resources back to the dev list.)
>>
>> Jeremy,
>>
>>    * Not sold on the "ownedByModule" attribute; if a type is
>>      module-specific, then the name should reflect it.
>>
>>    * How about a `formattributetype.handler` (class name) to handle
>>      getting/setting/rendering instead of a datatype? Or do we make
>>      datatype a class name, supporting `java.lang.String`,
>>      java.lang.Integer`, etc. -- with default handler(s) -- out of the box?
>>
>>    * What are the return values for the API methods? I don't see the
>>      purpose/need for the getFormAttributes(Form,
>>      List<FormAttributeType>, List<String> moduleIds) method.
>>
>>    * Assume uuid and other audit attributes (created_by, date_created,
>>      etc.) are left out for readability
>>
>>
>> -Burke
>>
>>
>> On May 19, 2010, at 11:21 AM, OpenMRS wrote:
>>
>>> #2273: Core should allow formentry modules to store view and resource
>>> metadata for
>>> a form
>>> -----------------------------------+----------------------------------------
>>> Reporter: djazayeri | Owner: jkeiper
>>> Type: task | Status: assigned
>>> Priority: major | Milestone: OpenMRS Someday
>>> Component: OpenMRS Code Base | Resolution:
>>> Keywords: | Intro_ticket: 0
>>> Review_status: |
>>> -----------------------------------+----------------------------------------
>>> Comment (by djazayeri):
>>>
>>> So something like this:
>>>
>>> {{{
>>> FormAttributeType
>>> id
>>> name
>>> ownedByModule // optional
>>> datatype
>>>
>>> FormAttribute
>>> id
>>> form
>>> formAttributeType
>>> value (blob)
>>>
>>> FormService
>>> getFormAttributes(Form, FormAttributeType)
>>> getFormAttributes(Form, List<FormAttributeType>, List<String>
>>> moduleIds)
>>> }}}
>>>
>>> --
>>> Ticket URL: <http://dev.openmrs.org/ticket/2273#comment:13>
>>> OpenMRS <http://dev.openmrs.org>
>>> Collaborating toward an open-source electronic medical record system.
>>
>> ------------------------------------------------------------------------
>> Click here to unsubscribe
>> <mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from
>> OpenMRS Developers' mailing list
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
Ben Wolfe (openmrs) Ben Wolfe (openmrs)
Reply | Threaded
Open this post in threaded view
|

Re: [OpenMRS] #2273: Core should allow formentry modules to store view and resource metadata for a form

Those things right now are called "field gen" and they act exactly as
you're "envisioning".

I think Mike has rewritten fieldgen for htmlformentry and called it
"html widgets" (module).  I haven't looked at that to see if thats a
better more sustainable implementation.

Ben

On 05/19/2010 01:01 PM, Burke Mamlin wrote:

> On May 19, 2010, at 12:56 PM, Ben Wolfe wrote:
>
>> For reference, person_attribute_type.format is a value like "java.lang.String".  This allows the person_attribute.value to be turned into an object automatically.
>
> Cule.  That's what I was picturing for form_attribute_type.datatype.  We could have one or more handler(s) in core that knew how to get/set/render basic datatypes and then modules could add new handlers as needed.  These handlers (at least for basic types) could eventually be shared across person_attribute_type, form_attribute_type, and global_property management screens.
>
> -Burke
>
>>
>> Ben
>>
>> On 05/19/2010 12:16 PM, Burke Mamlin wrote:
>>> (Moving discussion of handling form resources back to the dev list.)
>>>
>>> Jeremy,
>>>
>>>     * Not sold on the "ownedByModule" attribute; if a type is
>>>       module-specific, then the name should reflect it.
>>>
>>>     * How about a `formattributetype.handler` (class name) to handle
>>>       getting/setting/rendering instead of a datatype? Or do we make
>>>       datatype a class name, supporting `java.lang.String`,
>>>       java.lang.Integer`, etc. -- with default handler(s) -- out of the box?
>>>
>>>     * What are the return values for the API methods? I don't see the
>>>       purpose/need for the getFormAttributes(Form,
>>>       List<FormAttributeType>, List<String>  moduleIds) method.
>>>
>>>     * Assume uuid and other audit attributes (created_by, date_created,
>>>       etc.) are left out for readability
>>>
>>>
>>> -Burke
>>>
>>>
>>> On May 19, 2010, at 11:21 AM, OpenMRS wrote:
>>>
>>>> #2273: Core should allow formentry modules to store view and resource
>>>> metadata for
>>>> a form
>>>> -----------------------------------+----------------------------------------
>>>> Reporter: djazayeri | Owner: jkeiper
>>>> Type: task | Status: assigned
>>>> Priority: major | Milestone: OpenMRS Someday
>>>> Component: OpenMRS Code Base | Resolution:
>>>> Keywords: | Intro_ticket: 0
>>>> Review_status: |
>>>> -----------------------------------+----------------------------------------
>>>> Comment (by djazayeri):
>>>>
>>>> So something like this:
>>>>
>>>> {{{
>>>> FormAttributeType
>>>> id
>>>> name
>>>> ownedByModule // optional
>>>> datatype
>>>>
>>>> FormAttribute
>>>> id
>>>> form
>>>> formAttributeType
>>>> value (blob)
>>>>
>>>> FormService
>>>> getFormAttributes(Form, FormAttributeType)
>>>> getFormAttributes(Form, List<FormAttributeType>, List<String>
>>>> moduleIds)
>>>> }}}
>>>>
>>>> --
>>>> Ticket URL:<http://dev.openmrs.org/ticket/2273#comment:13>
>>>> OpenMRS<http://dev.openmrs.org>
>>>> Collaborating toward an open-source electronic medical record system.
>>>
>>> ------------------------------------------------------------------------
>>> Click here to unsubscribe
>>> <mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l>  from
>>> OpenMRS Developers' mailing list
>>
>> _________________________________________
>>
>> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
Jeremy Keiper-3 Jeremy Keiper-3
Reply | Threaded
Open this post in threaded view
|

Re: [OpenMRS] #2273: Core should allow formentry modules to store view and resource metadata for a form

So ... the ticket should incorporate creating a more-generic version of PersonAttribute for use with both Person and Form and possibly integrating logic from HTMLWidgets?  Should we hack the UI into place for now since it will most likely be redone in 2.0?

Jeremy Keiper
OpenMRS Core Developer
AMPATH / IU-Kenya Support


On Wed, May 19, 2010 at 1:05 PM, Ben Wolfe <[hidden email]> wrote:
Those things right now are called "field gen" and they act exactly as you're "envisioning".

I think Mike has rewritten fieldgen for htmlformentry and called it "html widgets" (module).  I haven't looked at that to see if thats a better more sustainable implementation.

Ben


On 05/19/2010 01:01 PM, Burke Mamlin wrote:
On May 19, 2010, at 12:56 PM, Ben Wolfe wrote:

For reference, person_attribute_type.format is a value like "java.lang.String".  This allows the person_attribute.value to be turned into an object automatically.

Cule.  That's what I was picturing for form_attribute_type.datatype.  We could have one or more handler(s) in core that knew how to get/set/render basic datatypes and then modules could add new handlers as needed.  These handlers (at least for basic types) could eventually be shared across person_attribute_type, form_attribute_type, and global_property management screens.

-Burke


Ben

On 05/19/2010 12:16 PM, Burke Mamlin wrote:
(Moving discussion of handling form resources back to the dev list.)

Jeremy,

   * Not sold on the "ownedByModule" attribute; if a type is
     module-specific, then the name should reflect it.

   * How about a `formattributetype.handler` (class name) to handle
     getting/setting/rendering instead of a datatype? Or do we make
     datatype a class name, supporting `java.lang.String`,
     java.lang.Integer`, etc. -- with default handler(s) -- out of the box?

   * What are the return values for the API methods? I don't see the
     purpose/need for the getFormAttributes(Form,
     List<FormAttributeType>, List<String>  moduleIds) method.

   * Assume uuid and other audit attributes (created_by, date_created,
     etc.) are left out for readability


-Burke


On May 19, 2010, at 11:21 AM, OpenMRS wrote:

#2273: Core should allow formentry modules to store view and resource
metadata for
a form
-----------------------------------+----------------------------------------
Reporter: djazayeri | Owner: jkeiper
Type: task | Status: assigned
Priority: major | Milestone: OpenMRS Someday
Component: OpenMRS Code Base | Resolution:
Keywords: | Intro_ticket: 0
Review_status: |
-----------------------------------+----------------------------------------
Comment (by djazayeri):

So something like this:

{{{
FormAttributeType
id
name
ownedByModule // optional
datatype

FormAttribute
id
form
formAttributeType
value (blob)

FormService
getFormAttributes(Form, FormAttributeType)
getFormAttributes(Form, List<FormAttributeType>, List<String>
moduleIds)
}}}

--
Ticket URL:<http://dev.openmrs.org/ticket/2273#comment:13>
OpenMRS<http://dev.openmrs.org>
Collaborating toward an open-source electronic medical record system.

------------------------------------------------------------------------
Click here to unsubscribe
<mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l>  from
OpenMRS Developers' mailing list

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]


[hidden email] from OpenMRS Developers' mailing list
Friedman, Roger (CDC/CGH/DGHA) (CTR) Friedman, Roger (CDC/CGH/DGHA) (CTR)
Reply | Threaded
Open this post in threaded view
|

Re: [OpenMRS] #2273: Core should allow formentry modules to store view and resource metadata for a form

Whoa, scope is not just creeping, it is freely flowing.
Original idea was to store xsn, xslt, etc. in this table and those would be the types, the types would be well known by the owner.
Now it is becoming some sort of multi-use strongly-typed EAV table which tightly couples forms to person_attributes and global_properties.
Why?  Why now?


-----Original Message-----
From: [hidden email] on behalf of Jeremy Keiper
Sent: Tue 6/1/2010 1:46 PM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] [OpenMRS] #2273: Core should allow formentry modules to store view and resource metadata for a form
 
So ... the ticket should incorporate creating a more-generic version of
PersonAttribute for use with both Person and Form and possibly integrating
logic from HTMLWidgets?  Should we hack the UI into place for now since it
will most likely be redone in 2.0?

Jeremy Keiper
OpenMRS Core Developer
AMPATH / IU-Kenya Support


On Wed, May 19, 2010 at 1:05 PM, Ben Wolfe <[hidden email]> wrote:

> Those things right now are called "field gen" and they act exactly as
> you're "envisioning".
>
> I think Mike has rewritten fieldgen for htmlformentry and called it "html
> widgets" (module).  I haven't looked at that to see if thats a better more
> sustainable implementation.
>
> Ben
>
>
> On 05/19/2010 01:01 PM, Burke Mamlin wrote:
>
>> On May 19, 2010, at 12:56 PM, Ben Wolfe wrote:
>>
>>  For reference, person_attribute_type.format is a value like
>>> "java.lang.String".  This allows the person_attribute.value to be turned
>>> into an object automatically.
>>>
>>
>> Cule.  That's what I was picturing for form_attribute_type.datatype.  We
>> could have one or more handler(s) in core that knew how to get/set/render
>> basic datatypes and then modules could add new handlers as needed.  These
>> handlers (at least for basic types) could eventually be shared across
>> person_attribute_type, form_attribute_type, and global_property management
>> screens.
>>
>> -Burke
>>
>>
>>> Ben
>>>
>>> On 05/19/2010 12:16 PM, Burke Mamlin wrote:
>>>
>>>> (Moving discussion of handling form resources back to the dev list.)
>>>>
>>>> Jeremy,
>>>>
>>>>    * Not sold on the "ownedByModule" attribute; if a type is
>>>>      module-specific, then the name should reflect it.
>>>>
>>>>    * How about a `formattributetype.handler` (class name) to handle
>>>>      getting/setting/rendering instead of a datatype? Or do we make
>>>>      datatype a class name, supporting `java.lang.String`,
>>>>      java.lang.Integer`, etc. -- with default handler(s) -- out of the
>>>> box?
>>>>
>>>>    * What are the return values for the API methods? I don't see the
>>>>      purpose/need for the getFormAttributes(Form,
>>>>      List<FormAttributeType>, List<String>  moduleIds) method.
>>>>
>>>>    * Assume uuid and other audit attributes (created_by, date_created,
>>>>      etc.) are left out for readability
>>>>
>>>>
>>>> -Burke
>>>>
>>>>
>>>> On May 19, 2010, at 11:21 AM, OpenMRS wrote:
>>>>
>>>>  #2273: Core should allow formentry modules to store view and resource
>>>>> metadata for
>>>>> a form
>>>>>
>>>>> -----------------------------------+----------------------------------------
>>>>> Reporter: djazayeri | Owner: jkeiper
>>>>> Type: task | Status: assigned
>>>>> Priority: major | Milestone: OpenMRS Someday
>>>>> Component: OpenMRS Code Base | Resolution:
>>>>> Keywords: | Intro_ticket: 0
>>>>> Review_status: |
>>>>>
>>>>> -----------------------------------+----------------------------------------
>>>>> Comment (by djazayeri):
>>>>>
>>>>> So something like this:
>>>>>
>>>>> {{{
>>>>> FormAttributeType
>>>>> id
>>>>> name
>>>>> ownedByModule // optional
>>>>> datatype
>>>>>
>>>>> FormAttribute
>>>>> id
>>>>> form
>>>>> formAttributeType
>>>>> value (blob)
>>>>>
>>>>> FormService
>>>>> getFormAttributes(Form, FormAttributeType)
>>>>> getFormAttributes(Form, List<FormAttributeType>, List<String>
>>>>> moduleIds)
>>>>> }}}
>>>>>
>>>>> --
>>>>> Ticket URL:<http://dev.openmrs.org/ticket/2273#comment:13>
>>>>> OpenMRS<http://dev.openmrs.org>
>>>>> Collaborating toward an open-source electronic medical record system.
>>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>> Click here to unsubscribe
>>>> <mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l>
>>>>  from
>>>> OpenMRS Developers' mailing list
>>>>
>>>
>>> _________________________________________
>>>
>>> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
>>> [hidden email] with "SIGNOFF openmrs-devel-l" in the  body
>>> (not the subject) of your e-mail.
>>>
>>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>>
>>
>> _________________________________________
>>
>> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
>> [hidden email] with "SIGNOFF openmrs-devel-l" in the  body
>> (not the subject) of your e-mail.
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
> [hidden email] with "SIGNOFF openmrs-devel-l" in the  body
> (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]


_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
Jeremy Keiper-3 Jeremy Keiper-3
Reply | Threaded
Open this post in threaded view
|

Re: [OpenMRS] #2273: Core should allow formentry modules to store view and resource metadata for a form

If scope is creeping, it's because we haven't stricken a line between ideals and practical implementation.

I don't see a problem with storing the data type, in order to facilitate conversion.  I'm happy to hack together an exact copy of PersonAttribute/PersonAttributeType for Forms and leave refactoring for someone else to do.

We don't really need UI changes (yet) because these form attributes should only be set through the API for now.

Jeremy Keiper
OpenMRS Core Developer
AMPATH / IU-Kenya Support


On Tue, Jun 1, 2010 at 2:00 PM, Friedman, Roger (CDC/OID/NCHHSTP) (CTR) <[hidden email]> wrote:
Whoa, scope is not just creeping, it is freely flowing.
Original idea was to store xsn, xslt, etc. in this table and those would be the types, the types would be well known by the owner.
Now it is becoming some sort of multi-use strongly-typed EAV table which tightly couples forms to person_attributes and global_properties.
Why?  Why now?


-----Original Message-----
From: [hidden email] on behalf of Jeremy Keiper
Sent: Tue 6/1/2010 1:46 PM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] [OpenMRS] #2273: Core should allow formentry modules to store view and resource metadata for a form

So ... the ticket should incorporate creating a more-generic version of
PersonAttribute for use with both Person and Form and possibly integrating
logic from HTMLWidgets?  Should we hack the UI into place for now since it
will most likely be redone in 2.0?

Jeremy Keiper
OpenMRS Core Developer
AMPATH / IU-Kenya Support


On Wed, May 19, 2010 at 1:05 PM, Ben Wolfe <[hidden email]> wrote:

> Those things right now are called "field gen" and they act exactly as
> you're "envisioning".
>
> I think Mike has rewritten fieldgen for htmlformentry and called it "html
> widgets" (module).  I haven't looked at that to see if thats a better more
> sustainable implementation.
>
> Ben
>
>
> On 05/19/2010 01:01 PM, Burke Mamlin wrote:
>
>> On May 19, 2010, at 12:56 PM, Ben Wolfe wrote:
>>
>>  For reference, person_attribute_type.format is a value like
>>> "java.lang.String".  This allows the person_attribute.value to be turned
>>> into an object automatically.
>>>
>>
>> Cule.  That's what I was picturing for form_attribute_type.datatype.  We
>> could have one or more handler(s) in core that knew how to get/set/render
>> basic datatypes and then modules could add new handlers as needed.  These
>> handlers (at least for basic types) could eventually be shared across
>> person_attribute_type, form_attribute_type, and global_property management
>> screens.
>>
>> -Burke
>>
>>
>>> Ben
>>>
>>> On 05/19/2010 12:16 PM, Burke Mamlin wrote:
>>>
>>>> (Moving discussion of handling form resources back to the dev list.)
>>>>
>>>> Jeremy,
>>>>
>>>>    * Not sold on the "ownedByModule" attribute; if a type is
>>>>      module-specific, then the name should reflect it.
>>>>
>>>>    * How about a `formattributetype.handler` (class name) to handle
>>>>      getting/setting/rendering instead of a datatype? Or do we make
>>>>      datatype a class name, supporting `java.lang.String`,
>>>>      java.lang.Integer`, etc. -- with default handler(s) -- out of the
>>>> box?
>>>>
>>>>    * What are the return values for the API methods? I don't see the
>>>>      purpose/need for the getFormAttributes(Form,
>>>>      List<FormAttributeType>, List<String>  moduleIds) method.
>>>>
>>>>    * Assume uuid and other audit attributes (created_by, date_created,
>>>>      etc.) are left out for readability
>>>>
>>>>
>>>> -Burke
>>>>
>>>>
>>>> On May 19, 2010, at 11:21 AM, OpenMRS wrote:
>>>>
>>>>  #2273: Core should allow formentry modules to store view and resource
>>>>> metadata for
>>>>> a form
>>>>>
>>>>> -----------------------------------+----------------------------------------
>>>>> Reporter: djazayeri | Owner: jkeiper
>>>>> Type: task | Status: assigned
>>>>> Priority: major | Milestone: OpenMRS Someday
>>>>> Component: OpenMRS Code Base | Resolution:
>>>>> Keywords: | Intro_ticket: 0
>>>>> Review_status: |
>>>>>
>>>>> -----------------------------------+----------------------------------------
>>>>> Comment (by djazayeri):
>>>>>
>>>>> So something like this:
>>>>>
>>>>> {{{
>>>>> FormAttributeType
>>>>> id
>>>>> name
>>>>> ownedByModule // optional
>>>>> datatype
>>>>>
>>>>> FormAttribute
>>>>> id
>>>>> form
>>>>> formAttributeType
>>>>> value (blob)
>>>>>
>>>>> FormService
>>>>> getFormAttributes(Form, FormAttributeType)
>>>>> getFormAttributes(Form, List<FormAttributeType>, List<String>
>>>>> moduleIds)
>>>>> }}}
>>>>>
>>>>> --
>>>>> Ticket URL:<http://dev.openmrs.org/ticket/2273#comment:13>
>>>>> OpenMRS<http://dev.openmrs.org>
>>>>> Collaborating toward an open-source electronic medical record system.
>>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>> Click here to unsubscribe
>>>> <mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l>
>>>>  from
>>>> OpenMRS Developers' mailing list
>>>>
>>>
>>> _________________________________________
>>>
>>> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
>>> [hidden email] with "SIGNOFF openmrs-devel-l" in the  body
>>> (not the subject) of your e-mail.
>>>
>>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>>
>>
>> _________________________________________
>>
>> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
>> [hidden email] with "SIGNOFF openmrs-devel-l" in the  body
>> (not the subject) of your e-mail.
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
> [hidden email] with "SIGNOFF openmrs-devel-l" in the  body
> (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]


_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]


[hidden email] from OpenMRS Developers' mailing list
Friedman, Roger (CDC/CGH/DGHA) (CTR) Friedman, Roger (CDC/CGH/DGHA) (CTR)
Reply | Threaded
Open this post in threaded view
|

Re: [OpenMRS] #2273: Core should allow formentry modules to store view and resource metadata for a form

I don't see how this is responsive.  Although there was some batting around of names for this new table, and it became form_attributes, that's not because it went with %attribute%.  Check the title: resource metadata for a form.  The purpose was to have this table in lieu of multiple <form_entry_method>_<metadata_file> tables.  This was already marginally utile.  Adding non-formentry elements to me seems less utile, not more.

-----Original Message-----
From: [hidden email] on behalf of Jeremy Keiper
Sent: Tue 6/1/2010 3:49 PM
To: [hidden email]
Subject: Re: [OPENMRS-DEV] [OpenMRS] #2273: Core should allow formentry modules to store view and resource metadata for a form
 
If scope is creeping, it's because we haven't stricken a line between ideals
and practical implementation.

I don't see a problem with storing the data type, in order to facilitate
conversion.  I'm happy to hack together an exact copy of
PersonAttribute/PersonAttributeType for Forms and leave refactoring for
someone else to do.

We don't really need UI changes (yet) because these form attributes should
only be set through the API for now.

Jeremy Keiper
OpenMRS Core Developer
AMPATH / IU-Kenya Support


On Tue, Jun 1, 2010 at 2:00 PM, Friedman, Roger (CDC/OID/NCHHSTP) (CTR) <
[hidden email]> wrote:

> Whoa, scope is not just creeping, it is freely flowing.
> Original idea was to store xsn, xslt, etc. in this table and those would be
> the types, the types would be well known by the owner.
> Now it is becoming some sort of multi-use strongly-typed EAV table which
> tightly couples forms to person_attributes and global_properties.
> Why?  Why now?
>
>
> -----Original Message-----
> From: [hidden email] on behalf of Jeremy Keiper
> Sent: Tue 6/1/2010 1:46 PM
> To: [hidden email]
> Subject: Re: [OPENMRS-DEV] [OpenMRS] #2273: Core should allow formentry
> modules to store view and resource metadata for a form
>
> So ... the ticket should incorporate creating a more-generic version of
> PersonAttribute for use with both Person and Form and possibly integrating
> logic from HTMLWidgets?  Should we hack the UI into place for now since it
> will most likely be redone in 2.0?
>
> Jeremy Keiper
> OpenMRS Core Developer
> AMPATH / IU-Kenya Support
>
>
> On Wed, May 19, 2010 at 1:05 PM, Ben Wolfe <[hidden email]> wrote:
>
> > Those things right now are called "field gen" and they act exactly as
> > you're "envisioning".
> >
> > I think Mike has rewritten fieldgen for htmlformentry and called it "html
> > widgets" (module).  I haven't looked at that to see if thats a better
> more
> > sustainable implementation.
> >
> > Ben
> >
> >
> > On 05/19/2010 01:01 PM, Burke Mamlin wrote:
> >
> >> On May 19, 2010, at 12:56 PM, Ben Wolfe wrote:
> >>
> >>  For reference, person_attribute_type.format is a value like
> >>> "java.lang.String".  This allows the person_attribute.value to be
> turned
> >>> into an object automatically.
> >>>
> >>
> >> Cule.  That's what I was picturing for form_attribute_type.datatype.  We
> >> could have one or more handler(s) in core that knew how to
> get/set/render
> >> basic datatypes and then modules could add new handlers as needed.
>  These
> >> handlers (at least for basic types) could eventually be shared across
> >> person_attribute_type, form_attribute_type, and global_property
> management
> >> screens.
> >>
> >> -Burke
> >>
> >>
> >>> Ben
> >>>
> >>> On 05/19/2010 12:16 PM, Burke Mamlin wrote:
> >>>
> >>>> (Moving discussion of handling form resources back to the dev list.)
> >>>>
> >>>> Jeremy,
> >>>>
> >>>>    * Not sold on the "ownedByModule" attribute; if a type is
> >>>>      module-specific, then the name should reflect it.
> >>>>
> >>>>    * How about a `formattributetype.handler` (class name) to handle
> >>>>      getting/setting/rendering instead of a datatype? Or do we make
> >>>>      datatype a class name, supporting `java.lang.String`,
> >>>>      java.lang.Integer`, etc. -- with default handler(s) -- out of the
> >>>> box?
> >>>>
> >>>>    * What are the return values for the API methods? I don't see the
> >>>>      purpose/need for the getFormAttributes(Form,
> >>>>      List<FormAttributeType>, List<String>  moduleIds) method.
> >>>>
> >>>>    * Assume uuid and other audit attributes (created_by, date_created,
> >>>>      etc.) are left out for readability
> >>>>
> >>>>
> >>>> -Burke
> >>>>
> >>>>
> >>>> On May 19, 2010, at 11:21 AM, OpenMRS wrote:
> >>>>
> >>>>  #2273: Core should allow formentry modules to store view and resource
> >>>>> metadata for
> >>>>> a form
> >>>>>
> >>>>>
> -----------------------------------+----------------------------------------
> >>>>> Reporter: djazayeri | Owner: jkeiper
> >>>>> Type: task | Status: assigned
> >>>>> Priority: major | Milestone: OpenMRS Someday
> >>>>> Component: OpenMRS Code Base | Resolution:
> >>>>> Keywords: | Intro_ticket: 0
> >>>>> Review_status: |
> >>>>>
> >>>>>
> -----------------------------------+----------------------------------------
> >>>>> Comment (by djazayeri):
> >>>>>
> >>>>> So something like this:
> >>>>>
> >>>>> {{{
> >>>>> FormAttributeType
> >>>>> id
> >>>>> name
> >>>>> ownedByModule // optional
> >>>>> datatype
> >>>>>
> >>>>> FormAttribute
> >>>>> id
> >>>>> form
> >>>>> formAttributeType
> >>>>> value (blob)
> >>>>>
> >>>>> FormService
> >>>>> getFormAttributes(Form, FormAttributeType)
> >>>>> getFormAttributes(Form, List<FormAttributeType>, List<String>
> >>>>> moduleIds)
> >>>>> }}}
> >>>>>
> >>>>> --
> >>>>> Ticket URL:<http://dev.openmrs.org/ticket/2273#comment:13>
> >>>>> OpenMRS<http://dev.openmrs.org>
> >>>>> Collaborating toward an open-source electronic medical record system.
> >>>>>
> >>>>
> >>>>
> ------------------------------------------------------------------------
> >>>> Click here to unsubscribe
> >>>> <mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l>
> >>>>  from
> >>>> OpenMRS Developers' mailing list
> >>>>
> >>>
> >>> _________________________________________
> >>>
> >>> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
> >>> [hidden email] with "SIGNOFF openmrs-devel-l" in the
>  body
> >>> (not the subject) of your e-mail.
> >>>
> >>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
> >>>
> >>
> >> _________________________________________
> >>
> >> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
> >> [hidden email] with "SIGNOFF openmrs-devel-l" in the  body
> >> (not the subject) of your e-mail.
> >>
> >> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
> >>
> >
> > _________________________________________
> >
> > To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
> > [hidden email] with "SIGNOFF openmrs-devel-l" in the  body
> > (not the subject) of your e-mail.
> >
> > [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
> >
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
> [hidden email] with "SIGNOFF openmrs-devel-l" in the  body
> (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
> [hidden email] with "SIGNOFF openmrs-devel-l" in the  body
> (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]


_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
Ben Wolfe (openmrs) Ben Wolfe (openmrs)
Reply | Threaded
Open this post in threaded view
|

Re: [OpenMRS] #2273: Core should allow formentry modules to store view and resource metadata for a form

Yes, the point of this table is to be used by the xslt, xsn, and
html_form objects.  This means we have limited format/types right now:
each of these are either text blobs or binary objects.

However, Tammy has said they use form_attributes in their installation
in order to add more information around a form.  Because there is a
future use case there, we should plan now for that.

(Double) however, we don't really need to go as far as
person_attribute/person_attribute_type has gone.  There is not a need
right now for a complicated full blown UI that will let you put in any
type of attribute, so that can be skipped.

Ben

On 06/01/2010 05:25 PM, Friedman, Roger (CDC/OID/NCHHSTP) (CTR) wrote:

> I don't see how this is responsive.  Although there was some batting around of names for this new table, and it became form_attributes, that's not because it went with %attribute%.  Check the title: resource metadata for a form.  The purpose was to have this table in lieu of multiple<form_entry_method>_<metadata_file>  tables.  This was already marginally utile.  Adding non-formentry elements to me seems less utile, not more.
>
> -----Original Message-----
> From: [hidden email] on behalf of Jeremy Keiper
> Sent: Tue 6/1/2010 3:49 PM
> To: [hidden email]
> Subject: Re: [OPENMRS-DEV] [OpenMRS] #2273: Core should allow formentry modules to store view and resource metadata for a form
>
> If scope is creeping, it's because we haven't stricken a line between ideals
> and practical implementation.
>
> I don't see a problem with storing the data type, in order to facilitate
> conversion.  I'm happy to hack together an exact copy of
> PersonAttribute/PersonAttributeType for Forms and leave refactoring for
> someone else to do.
>
> We don't really need UI changes (yet) because these form attributes should
> only be set through the API for now.
>
> Jeremy Keiper
> OpenMRS Core Developer
> AMPATH / IU-Kenya Support
>
>
> On Tue, Jun 1, 2010 at 2:00 PM, Friedman, Roger (CDC/OID/NCHHSTP) (CTR)<
> [hidden email]>  wrote:
>
>> Whoa, scope is not just creeping, it is freely flowing.
>> Original idea was to store xsn, xslt, etc. in this table and those would be
>> the types, the types would be well known by the owner.
>> Now it is becoming some sort of multi-use strongly-typed EAV table which
>> tightly couples forms to person_attributes and global_properties.
>> Why?  Why now?
>>
>>
>> -----Original Message-----
>> From: [hidden email] on behalf of Jeremy Keiper
>> Sent: Tue 6/1/2010 1:46 PM
>> To: [hidden email]
>> Subject: Re: [OPENMRS-DEV] [OpenMRS] #2273: Core should allow formentry
>> modules to store view and resource metadata for a form
>>
>> So ... the ticket should incorporate creating a more-generic version of
>> PersonAttribute for use with both Person and Form and possibly integrating
>> logic from HTMLWidgets?  Should we hack the UI into place for now since it
>> will most likely be redone in 2.0?
>>
>> Jeremy Keiper
>> OpenMRS Core Developer
>> AMPATH / IU-Kenya Support
>>
>>
>> On Wed, May 19, 2010 at 1:05 PM, Ben Wolfe<[hidden email]>  wrote:
>>
>>> Those things right now are called "field gen" and they act exactly as
>>> you're "envisioning".
>>>
>>> I think Mike has rewritten fieldgen for htmlformentry and called it "html
>>> widgets" (module).  I haven't looked at that to see if thats a better
>> more
>>> sustainable implementation.
>>>
>>> Ben
>>>
>>>
>>> On 05/19/2010 01:01 PM, Burke Mamlin wrote:
>>>
>>>> On May 19, 2010, at 12:56 PM, Ben Wolfe wrote:
>>>>
>>>>   For reference, person_attribute_type.format is a value like
>>>>> "java.lang.String".  This allows the person_attribute.value to be
>> turned
>>>>> into an object automatically.
>>>>>
>>>>
>>>> Cule.  That's what I was picturing for form_attribute_type.datatype.  We
>>>> could have one or more handler(s) in core that knew how to
>> get/set/render
>>>> basic datatypes and then modules could add new handlers as needed.
>>   These
>>>> handlers (at least for basic types) could eventually be shared across
>>>> person_attribute_type, form_attribute_type, and global_property
>> management
>>>> screens.
>>>>
>>>> -Burke
>>>>
>>>>
>>>>> Ben
>>>>>
>>>>> On 05/19/2010 12:16 PM, Burke Mamlin wrote:
>>>>>
>>>>>> (Moving discussion of handling form resources back to the dev list.)
>>>>>>
>>>>>> Jeremy,
>>>>>>
>>>>>>     * Not sold on the "ownedByModule" attribute; if a type is
>>>>>>       module-specific, then the name should reflect it.
>>>>>>
>>>>>>     * How about a `formattributetype.handler` (class name) to handle
>>>>>>       getting/setting/rendering instead of a datatype? Or do we make
>>>>>>       datatype a class name, supporting `java.lang.String`,
>>>>>>       java.lang.Integer`, etc. -- with default handler(s) -- out of the
>>>>>> box?
>>>>>>
>>>>>>     * What are the return values for the API methods? I don't see the
>>>>>>       purpose/need for the getFormAttributes(Form,
>>>>>>       List<FormAttributeType>, List<String>   moduleIds) method.
>>>>>>
>>>>>>     * Assume uuid and other audit attributes (created_by, date_created,
>>>>>>       etc.) are left out for readability
>>>>>>
>>>>>>
>>>>>> -Burke
>>>>>>
>>>>>>
>>>>>> On May 19, 2010, at 11:21 AM, OpenMRS wrote:
>>>>>>
>>>>>>   #2273: Core should allow formentry modules to store view and resource
>>>>>>> metadata for
>>>>>>> a form
>>>>>>>
>>>>>>>
>> -----------------------------------+----------------------------------------
>>>>>>> Reporter: djazayeri | Owner: jkeiper
>>>>>>> Type: task | Status: assigned
>>>>>>> Priority: major | Milestone: OpenMRS Someday
>>>>>>> Component: OpenMRS Code Base | Resolution:
>>>>>>> Keywords: | Intro_ticket: 0
>>>>>>> Review_status: |
>>>>>>>
>>>>>>>
>> -----------------------------------+----------------------------------------
>>>>>>> Comment (by djazayeri):
>>>>>>>
>>>>>>> So something like this:
>>>>>>>
>>>>>>> {{{
>>>>>>> FormAttributeType
>>>>>>> id
>>>>>>> name
>>>>>>> ownedByModule // optional
>>>>>>> datatype
>>>>>>>
>>>>>>> FormAttribute
>>>>>>> id
>>>>>>> form
>>>>>>> formAttributeType
>>>>>>> value (blob)
>>>>>>>
>>>>>>> FormService
>>>>>>> getFormAttributes(Form, FormAttributeType)
>>>>>>> getFormAttributes(Form, List<FormAttributeType>, List<String>
>>>>>>> moduleIds)
>>>>>>> }}}
>>>>>>>
>>>>>>> --
>>>>>>> Ticket URL:<http://dev.openmrs.org/ticket/2273#comment:13>
>>>>>>> OpenMRS<http://dev.openmrs.org>
>>>>>>> Collaborating toward an open-source electronic medical record system.
>>>>>>>
>>>>>>
>>>>>>
>> ------------------------------------------------------------------------
>>>>>> Click here to unsubscribe
>>>>>> <mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l>
>>>>>>   from
>>>>>> OpenMRS Developers' mailing list
>>>>>>
>>>>>
>>>>> _________________________________________
>>>>>
>>>>> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
>>>>> [hidden email] with "SIGNOFF openmrs-devel-l" in the
>>   body
>>>>> (not the subject) of your e-mail.
>>>>>
>>>>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>>>>
>>>>
>>>> _________________________________________
>>>>
>>>> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
>>>> [hidden email] with "SIGNOFF openmrs-devel-l" in the  body
>>>> (not the subject) of your e-mail.
>>>>
>>>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>>>
>>>
>>> _________________________________________
>>>
>>> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
>>> [hidden email] with "SIGNOFF openmrs-devel-l" in the  body
>>> (not the subject) of your e-mail.
>>>
>>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>>
>>
>> _________________________________________
>>
>> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
>> [hidden email] with "SIGNOFF openmrs-devel-l" in the  body
>> (not the subject) of your e-mail.
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>
>>
>> _________________________________________
>>
>> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
>> [hidden email] with "SIGNOFF openmrs-devel-l" in the  body
>> (not the subject) of your e-mail.
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>>
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
>
>
> _________________________________________
>
> To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.
>
> [mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]