From: Joern T. <joe...@gm...> - 2013-11-07 09:58:00
|
As for the aforementioned reasons generating xforms from schema is only possible in simple cases. You need something extra to streamline what and in which order (another problem not mentioned before) you want to present fields and of which type these are. In a current project we have not taken the approach to annotate the schema but to have a separate 'profile' that can be used to reorder, completely hide and specify a control type for a given field. In a first step a document of xforms bindings will be created that reflects the schema 1:1. Then in a separate step the profile is matched against this list to create the concrete form. The profile itself is generated also from the bindings document to have a template to edit. Of course the reordering etc. is a manual process but changes done to that profile may be merged back later on if the schema changes. Joern On Mon, Nov 4, 2013 at 4:03 PM, Adam Retter <ad...@ex...> wrote: > > On 4 Nov 2013 08:30, "Ihe Onwuka" <ihe...@gm...> wrote: > > > > I self taught myself XSLT and XML Schema by building an HTML application > using HTML behaviours that auto-generated a web form from an XML schema > (cripes this is going back 10 years). I had plans to port it to XForms but > never got round to it but I feel there are some general principles that > allow me to offer perspective. > > > > If you are writing a transformation to generate a form from a schema > your forms are going to tend to look the same - perhaps the way to go is to > use the auto-generated form as baseline code for your form. In my case the > intended use for the form was to create an interface for a testing tool - > i.e is was not targeted at end-users entering production data - so I could > make some compromises on the user interface that may not be acceptable for > a production targeted form. For example dealing with Schema generated error > messages in a form is a pain. > > > > The impedance mismatch between schemas and XForms is quite wide which > would give rise to several representational issues. It can work if you > constrain the types of schema you are willing to accept as input and are > happy restricting the variety of forms artefacts to those that can > faithfully and scalably represent schematic concepts, but what you end up > with may not be sufficiently general purpose to be satisfactory. > > > > Now having said all that I have not looked at RestXQ but these were the > issues I was contending with when I was building my tool and this was when > both technologies were at version 1. I cannot imagine any particular > toolset will make those issues go away. > > > > Sure those issues still remain. When we used to generate forms from schema > (~2004) we used to annotate our schemas using appInfo elements to fill out > the missing detail before the transformation. > > > On Mon, Oct 28, 2013 at 9:45 PM, Dr Josef Karthauser < > jo...@ka...> wrote: > >> > >> Have the best practices for XRX applications changed since 2008? I've > been looking for example documentation, but not found anything since the > early days. All the examples are in xquery 1.0, and don't utilise the REST > interface that existDB provides. > >> > >> Are there any best practices, or have approaches diverged since then? > >> > >> Also, I saw in a few places mention of applications that could generate > xforms from xml schemas (as a step towards automated generation of XRX > apps), but I've not found any concrete examples. Are the hidden somewhere? > >> > >> I'd appreciate any views on this; I know that there are experts lurking > on this list :). > >> > >> Thanks, > >> joe > >> > ------------------------------------------------------------------------------ > >> Android is increasing in popularity, but the open development platform > that > >> developers love is also attractive to malware creators. Download this > white > >> paper to learn more about secure code signing practices that can help > keep > >> Android apps secure. > >> > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > >> _______________________________________________ > >> Exist-open mailing list > >> Exi...@li... > >> https://lists.sourceforge.net/lists/listinfo/exist-open > > > > > > > > > ------------------------------------------------------------------------------ > > Android is increasing in popularity, but the open development platform > that > > developers love is also attractive to malware creators. Download this > white > > paper to learn more about secure code signing practices that can help > keep > > Android apps secure. > > > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > > _______________________________________________ > > Exist-open mailing list > > Exi...@li... > > https://lists.sourceforge.net/lists/listinfo/exist-open > > > > > ------------------------------------------------------------------------------ > Android is increasing in popularity, but the open development platform that > developers love is also attractive to malware creators. Download this white > paper to learn more about secure code signing practices that can help keep > Android apps secure. > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > _______________________________________________ > Exist-open mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-open > > |