dhis2-devs team mailing list archive

[Ola Hodne Titlestad <olatitle@xxxxxxxxx>]

2009/10/27 Lars Helge Øverland <larshelge@xxxxxxxxx>

>
>
> 2009/10/27 Ola Hodne Titlestad <olatitle@xxxxxxxxx>
>
> 2009/10/27 Lars Helge Øverland <larshelge@xxxxxxxxx>
>>
>>
>>>
>>> On Mon, Oct 26, 2009 at 2:48 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx>wrote:
>>>
>>>> It seems to me we are missing a level of grouping.  We need to group
>>>> dataelements which have similar dimensionality (presumably using a DataSet)
>>>> and we also need to group the dataelements which might appear on a form.
>>>> The two are not necessarily the same.
>>>>
>>>
>>>> Do we need a FormData abstraction which perhaps contains a set of
>>>> DataSets?  I suspect this is tyhe right way to go.
>>>>
>>>
>>> Makes sense. Actually the DataSet holds information about PeriodType,
>>> assigned OrganisationUnits and locking which should be equal for all the
>>> sub-elements. So we need a sub-element which has a DimensionSet and a set of
>>> DataElements. Maybe Form and FormSection.
>>>
>>
>> Not sure exactly how it will affect your design suggestions, but I would
>> like to see the forms to be as flexible as possible, mainly concerned with
>> presentation and not so much with the underlying data. E.g it would be great
>> if we could start to support multiple orgunits and/or periods in our data
>> entry forms. No need to restrict a form instance to use only one orgunit and
>> one period. Data values saved in a form will have those restrictions of
>> course, but being able to compose forms that combine different sources and
>> periods makes a lot of sense, e.g. when registering one or a few data
>> elements (e.g. population data) for many orgunits, or when a community
>> health worker needs to manage facility, household and patient/client data at
>> the same time.
>>
>>
> OK but this increases complexity exponentially...
>

I see that. Still, I think we should consider how can we try to make our
model (and cross cutting functions that goes with data registration e.g.
min/max, validation) support various ways of registering data in electronic
forms. I am not saying that we need to put all this functionality into one
data entry module, but through the model open up for other ways of doing
data entry that are not necessarily defined within the boundaries of 1
orgunit, 1 period, multiple data elements, and 1 dimension set.

Ola
----------