dhis2-devs team mailing list archive

[Jason Pickering <jason.p.pickering@xxxxxxxxx>]

This has got me thinking once again what a category/combo/option
actually is and how the current implementation makes too many
assumptions, like that categories should add up to a total.

 I would suggest we continue thinking about it in background  document
I created a while back..

https://docs.google.com/document/d/1swOxM-E-bYRBXhnalvAtuMb8FGYocxOCVvJS36B25C4/edit?hl=en


On Tue, Dec 7, 2010 at 1:02 PM, Knut Staring <knutst@xxxxxxxxx> wrote:
> On Tue, Dec 7, 2010 at 2:55 AM, Thuy Nguyen <thuy.hispvietnam@xxxxxxxxx> wrote:
>> Dear Johan,
>> Thank you for your suggestions. Please scroll down to see my mail
>>
>>
>>
>> On Tue, Dec 7, 2010 at 1:59 AM, <johansa@xxxxxxxxxx> wrote:
>>>
>>> Dear Thuy,
>>>
>>> I'm not very familiar with the requirements in Sri Lanka, but I have a few
>>> general comments. First, the categories and combinations should be used
>>> when we want to aggregate them into a data element that is a natural total
>>> of these categories. For stock, this is usually not the case, as we do not
>>> want to add start balance, received, issued, and monthly requirement (in
>>> this case).
>>
>> About the total meaning of categories and categories options. I got the
>> lesson from my mistake in Vietnam. So I didn't want to repeat again by
>> explanation people here. But again because of the instant benefit of
>> category data elements such as the defaul entry form will generate
>> automatically with good form which DHIS provided. And the shorting of
>> creating data elements,... So the person who do this project decided to use
>> categories for this report as well as other reports for equipments like
>> beds, tables,... I knew it is wrong for the meaning of categories which
>> developers in DHIS wish to use. But I don't know serious reason for defense
>> on this. That's why I consult you to know what will happen in the future
>> when data base become huge if we use category options like this for data
>> elements? Is it affecting to retrieving information later?
>
> Hi Thuy,
>
> I personally think one has to weight these things against each other.
> I understand very well the desire to have nice autogenerated forms,
> and I don't really see the big problem with using categories this way
> AS LONG AS one bears in mind that the total will not work. I think the
> major downside to doing it like this is that Pivot tables will not
> work well on these dataelements, since the whole point of pivot tables
> is to easily sum up - and if some of the sums are meaningless, that
> restricts the usefulness of the pivot tables.
>
> It would be nice if it were possible to easily generate good looking
> forms without violating the semantics of the aggregation model, though
> I suppose that would require a decoupling of the form section
> generating machinery from the data element model. One would then be
> able to assign categorycombos to a section, but also group data
> elements in sections external to the disaggregation model.
>
> Knut
>
> _______________________________________________
> 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
>



-- 
Jason P. Pickering
email: jason.p.pickering@xxxxxxxxx
tel:+260968395190