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.
Cheers
Bob
···
2010/12/15 Lars Helge Øverland <larshelge@gmail.com>:
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.
<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
···
2010/12/16 Lars Helge Øverland <larshelge@gmail.com>:
On Wed, Dec 15, 2010 at 5:18 PM, Bob Jolliffe <bobjolliffe@gmail.com> wrote:
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.