dhis2-devs team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

2010/12/16 Bob Jolliffe <bobjolliffe@xxxxxxxxx>

> 2010/12/16 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.
> >
>
> OK.  its ugly but we can have a form element like:
>
> <form id="23" name="My beautiful form">
> <![CDATA[.... the html form ... ]]>
> </form>
>
> (Just guessing at the attributes)  And the form converter will parse
> and replace the ids from inside the cdata section using java code - it
> has to copy the whole thing so I guess it can replace ids as it copies
> efficiently enough.
>
> Cheers
> Bob
>

Yes.