dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

2010/5/11 Ola Hodne Titlestad <olatitle@xxxxxxxxx>:
> I would like to see the section (or whatever we end up calling it) as the
> main mechanism for breaking up the data entry form into multiple tables, and
> not the catcombos.
> It is not given that the form layout is simply one or more tables generated
> off the catcombos, e.g. the default catcombo would in many cases need
> multiple sections, and other catcombos as well.
>
> The catcombo is more of a model thing that describes dimensions for one or
> more data elements, but it is not given that data elements that share a
> catcombo should all be in the same table in a form.
>
>  As I mentioned in the original email then we need a constraint on sections
> to only include data elements from one catcombo, which should be doable.
>

OK.  But then maybe we are being too restrictive.  Forms naturally
have subforms which in themselves might have a heterogenous mix of
dataelements.  From what I hear you say I'm not sure if mixing the
idea of sections/subforms with tables really hits the spot.

It seems to me ...

1.  We need a form object
2.  We need a subform (or section) object
3.  We need a table object (which is restricted to dataelements of one catcombo)

The form object uses a dataset as its model. I'm not sure if the
others merit being reflected in the datamodel at all.  In terms of the
resulting datavalues the model is quite agnostic as to which section
of the form they might have come from.

Taking some inspiration from the XForms 1.1 spec, they define a Group mechanism:
"A group element is a container form control that allows a form author
to aggregate other form controls into a single, aggregate user
interface component."  Groups can also be nested."

Given that we are likely implementing html forms then there is the
fieldset as a grouping mechanism - and fieldsets can also be nested.
So we can have two classes of fieldset (one for subforms and one for
multimensional tables):

<form>
<fieldset id="section1" class="formsection">
   <input name="de1"  .../>
   <input name="de1"  .../>
</fieldset>
<fieldset id="section2" class="formsection">
   <input name="de3"  .../>
   <input name="de4"  .../>
   <fieldset id="table1" class="multidimension" >
      <table ... />
   </fieldset>
</fieldset>
etc

Then use our fancy css wizardry to render the section fieldsets the
way we would like them to be.

Anyway .. my point is that you want to be able to break the form up
into sections.  And within those sections you might have, amongst
other things, multidimensional data element tables. So the form xml
should be able to represent that.   You could do that by having a very
simple form xml which looked like:

<form id="myform" title="ART Summary Form">
   <section id="sect1" title="Registration" ><de>234</de><de>235</de></section>
   <section id="sect2" title="Treatment" >
             <de>234</de>
             <de>235</de>
             <table id=".." title=".."  catcombo="345">
                   <de>236</de>
                   <de>237</de>
                   <de>238</de>
                   <de>239</de>
            </table>
    </section>
</form>

Then maybe use xslt to generate the htmlform with (fieldsets, divs or
what have you) off this form model.  Naturally a constraint would be
that the de's within a table should have catcombo of 345.

Cheers
Bob


> Ola
> ---------
>
> 2010/5/11 Lars Helge Øverland <larshelge@xxxxxxxxx>
>>
>>
>> 2010/5/11 Bob Jolliffe <bobjolliffe@xxxxxxxxx>
>>>
>>> Hi Lars
>>>
>>> Sorry i jumped a bit quick on the blueprint.  But I was just asking
>>> Abyot about that.
>>>
>>> Do I take it that this requirement will be met in the improved-forms
>>> blueprint?  I've looked at it and its not entirely clear.  I guess the
>>> dataset-section is a structural thing related to the model, whereas
>>> the improved-forms blueprint describes view oriented things related to
>>> layout.  And I am in favour of keeping these things separate.
>>>
>>> But does this mean that the section idea as we currently have it will
>>> be deprecated?  Thats important to know.
>>>
>>> Regards
>>> Bob
>>>
>>
>> No prob. The Section is actually also related to layout, the only purpose
>> is to break long lists in data entry forms into smaller parts.
>> But now we are grouping dataelements in the form into categorycombos.
>> Grouping further into sections will make things a bit too complex I think.
>> We can consider it later but I think its a good idea to have one blueprint
>> for all this in any case.
>>
>>
>>
>>>
>>> 2010/5/11 Lars Helge Øverland <larshelge@xxxxxxxxx>:
>>> > Superseded by this:
>>> > https://blueprints.launchpad.net/dhis2/+spec/improved-forms
>>> >
>>> >
>>> > On Tue, May 11, 2010 at 10:16 AM, Bob Jolliffe <bobjolliffe@xxxxxxxxx>
>>> > wrote:
>>> >>
>>> >> Just registered the blueprint.
>>> >>
>>> >> On 11 May 2010 05:27, Kim Anh Vo <catakim@xxxxxxxxx> wrote:
>>> >> > so, is it included somewhere? a blueprint yet? Any plan for it?
>>> >> > Agree with the suggestion!
>>> >> >
>>> >> > --
>>> >> > Default data entry forms: tables should be created based on sections
>>> >> > and
>>> >> > not catcombos
>>> >> > https://bugs.launchpad.net/bugs/509554
>>> >> > You received this bug notification because you are a member of DHIS
>>> >> > 2
>>> >> > coordinators, which is the registrant for DHIS.
>>> >> >
>>> >> > Status in DHIS 2 - District Health Information Software: New
>>> >> >
>>> >> > Bug description:
>>> >> > When using multidimensional data elements and datasets with multiple
>>> >> > catcombos, data set sections can be used to group data elements by
>>> >> > catcombo
>>> >> > and to provide titles for each generated table.
>>> >> >
>>> >> > Sometimes it also makes sense to split a long list of data elements
>>> >> > with
>>> >> > the same catcombo into sections (smaller tables) based on their
>>> >> > meaning.
>>> >> >
>>> >> > When using sections and default forms then the generated tables
>>> >> > should
>>> >> > be generated off the sections and not the catcombos. Right now you
>>> >> > will get
>>> >> > one big table per catcombo eben though you might have defined
>>> >> > several
>>> >> > sections, which seems strange.
>>> >> >
>>> >> > Not sure we have restriction formally defined yet, but I would like
>>> >> > to
>>> >> > see a restriction on data set sections to only have 1 catcombo. Then
>>> >> > it
>>> >> > would be easy enough to create one table per section when generating
>>> >> > the
>>> >> > default form.
>>> >> >
>>> >> >
>>> >> >
>>> >>
>>> >> _______________________________________________
>>> >> 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
>>
>
>