dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

2010/6/2 Lars Helge Øverland <larshelge@xxxxxxxxx>:
>
>
> 2010/6/2 Ola Hodne Titlestad <olatitle@xxxxxxxxx>
>>
>> 2010/6/1 Lars Helge Øverland <larshelge@xxxxxxxxx>
>>>
>>> Hi,
>>> we are doing some observations on the Indian production servers and we
>>> see that loading the data entry screens are quite slow.
>>> One cause to this is that we are loading each and every data element in
>>> the custom data entry forms individually. I was trying to improve this by
>>> doing a query and loading all data elements in the data set (corresponding
>>> to the CDE).
>>
>> Just to be 100% sure on this. CDE in this case means Custom Data Entry
>> right? I've seen it used for Calculated Data Elements as well, which is
>> confusing.
>>
> Okay sorry I was referring to custom data entryscreen.
>
>>
>>
>>>
>>> Then I suddenly learned that when designing CDEs one is not restricted to
>>> the data elements in the data set the CDE is based on only, and that the
>>> CDEs in the Sierra Leone database from last year contains data elements from
>>> outside its data set.
>>>
>> I think you are limited to data elements in one data set when designing,
>> but is not controlled an kept consistent over time, e.g. when data elements
>> move to another data set.
>>
>>>
>>> I find this quite weird and I think we should stop allowing this, in
>>> order to get a quite significant and needed performance improvements. This
>>> change will be compatible with the change of the data entry stuff we are
>>> working on. But I don't know the consequences, ie. how many CDEs do we have
>>> around which will be affected by this? Comments?
>>
>> Totally agree that a data entry form should be limited to the data
>> elements in the corresponding data set, that is the point of the model.
>> After all to open a new custom form you have to pick one dataset first, so
>> it is from the UI quite obvious that a forms belongs to one dataset. The
>> data element pop-up in the FcK editor only lists the data elements from the
>> current dataset right? I am quite sure of that. What might have happened is
>> that some data elements that where originally in Dataset A and used in Form
>> A was later moved to data set B without being moved from Form A. It should
>> of course not be allowed to remove a data element from a dataset if it is
>> already used in the corresponding custom form. Or at least then it should be
>> removed from the form (but that might be too confusing), so better to ask
>> the user to remove it from the form first and then try again.
>>
>> There are definitely not any data forms in Sierra Leone for 2010 that has
>> data elements from more than one data set (and that data set is the one that
>> has the custom form), so I see no problem of being a bit more strict in
>> reinforcing this rule.
>>
>
> Okay. Thanks for the info. We will change this for 2.0.5 then. Users with
> custom data entry screens containing data elements not from the belonging
> data sets are hereby warned...
>

I think that's an important restriction if we are ever to consider
generating xforms from our datasets.  The calculated data element
value would most likely be bound to an xforms:output control rather
than an xforms:input control but the value itself would have to be
part of the model which would presumably be generated off a dataset.

I'll do an example of this using xsltforms later but I've got some
stuff to finish first.

Cheers
Bob

>>
>> Ola
>> --------
>>
>>
>>
>>>
>>> Lars
>>> _______________________________________________
>>> 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
>>>
>>
>
>
> _______________________________________________
> 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
>
>