dhis2-devs team mailing list archive

[Knut Staring <knutst@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...
>
>
We have indeed erred on the side of too much flexibility earlier, which
costs a lot (e.g. the hyperflexible periods and period aggregation, the use
of source etc), and introducing unneeded generality goes against agile
principles.

Still, I do agree with Ola on the need for alternative input mechanisms, a
bit like the Openhealth functional prototype was able to generate different
input grids based on the cube structure and user preferences (e.g. one
facility or all facilities in a province). But let us not try to be too
ambitious here, though it is hard to find the right balance.

Knut

PS Here is a horror story of too much generality:
http://www.simple-talk.com/opinion/opinion-pieces/bad-carma/



> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Cheers,
Knut Staring