dhis2-devs team mailing list archive

[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