dhis2-devs team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

On Wed, Dec 15, 2010 at 5:18 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:

> 2010/12/15 Lars Helge Øverland <larshelge@xxxxxxxxx>:
> > Blueprint changed by Lars Helge Øverland:
> >
> >    Assignee: Lars Helge Øverland => Thu Tran
> >
> > --
> > Import/Export of data entry forms
> >
> https://blueprints.launchpad.net/dhis2/+spec/import-export-dataentry-forms
>
> Looking at Blueprint (and Ola's quest for inspiration), it seems that
> import/export of forms would currently have to follow the way we
> import and export metadata more generally.
>
> That is, because our current world view is that the name is the
> authoritative identifier, the form would have to be exported together
> with the existing metadata for dataelements, categories etc.  So we
> require an additional dxf converter for form objects.  Then we would
> export:
> <dxf><categoryoptions, categories, dataelements etc
> /><forms><form1,2,3 .../><forms></dxf>
>
> So the question reduces to whether we have an xml representation of
> the forms.  A quick and ugly scenario is store the form html code in
> CDATA section.  Though it would be slightly cleaner if the form
> descriptions are valid xml (eg xhtml).
>
> On import we could then make use of the objectmapper to map ids to the
> ids in the native database.
>
> This would hopefully be a temporary situation.  Once we have the
> integer identifiers more stabilized the form would only need to
> identify which metadata set it is using rather than having to do
> mapping.i
>
> Cheers
> Bob
>
>

Yes. Been thinking about this too and for now we must settle with the quick
and ugly one. The custom form generator doesn't produce valid XHTML at the
moment and there are lots of forms in the field.

We should soon improve the markup produced by the custom form generator
because it is verbose and consumes unnecessary band-with. Making it produce
XHTML could also be a goal.