2010/12/16 Bob Jolliffe <[email protected]> > 2010/12/16 Lars Helge Øverland <[email protected]>: > > > > > > On Wed, Dec 15, 2010 at 5:18 PM, Bob Jolliffe <[email protected]> > wrote: > >> > >> 2010/12/15 Lars Helge Øverland <[email protected]>: > >> > 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.
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
