I've been making so many changes and bug fixes to the schema2xforms.xsl that I think it should become a separate file in the project. I'll write an extensive blog article about all functionality so it might get some nice additional exposure.
But… I want to add one additional feature before I check it in. Being able to create a swithc/case from an xsd.
The most simple case is having a complex element that is the start of the switch and each complex element that it contains is a case. But….
Parsing this, it is needed to build the triggers outside the switch so you have to parse every element twice, or use some other clever trick. Since you guys created the core of this, maybe you know some way to do this. I did not get to grips with the whole tunneling thing in xslt yet.
Tia
Ronald
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm glad you found schema2xforms useful and it would be very interesting to see your changes. Regarding your question about being able to make switch/case from xsd - if you are adding new tags or adding new semantics for xsd tags, then you should make a new file and inherit from schema2xforms by importing it. See xtee2xforms.xsl for an example.
But there is also xsd:choice element, that could be basis of generating a switch/case construct. In this case the semantics of switch/case are somewhat similar to xsd:choice, so it could be included in schema2xforms.xsl. Currently there is rather complex logic with radio buttons and relevant expressions for xsd:choice, but this could be replaced with switch/case, if you prefer.
If you want to parse elements twice, just use different modes. For example:
<xsl:apply-templates mode="pass1"/>
<xsl:apply-templates mode="pass2"/>
Tunneling is quite natural construct, once you have played with parameters enough. Normally if you call template with parameters and from this template call another template, then parameters you gave to first template are not automatically passed to second template. This forces you to write code into every template, so that they accept some parameters and give the same parameters as arguments to every template they call, even if they don't use those parameters by itself. Tunneling allows you to reduce this code, similar to putting parameters in "session" in web programming paradigm.
I have found Saxon documentation very good in explaining the XSLT nuances. For example tunneling is explained in here:
What you describe about tunneling is what I understood it to be. Don't now why I had a problem with it, seems to be ok now.
Regarding parsing nodes twice had much more to do with the fact that I had to parse *other* nodes in addition to the one I was parsing at that time (filling the trigger part if you encounter the first element that needs to become a 'case'). Funny that I forgot that you do not have to work in the context of the current node, you can call templates with '/' as the context and just search for all elements that are annotated to become a case.
My current solution (which works for now but has to be adapted in the not so distant future) is to have all complex elements that need to become a switch/case construct to be annotated with an additional attribute and (unfortunately) an additional namespace. This attribute, currently called switch, takes a value that is used to group all these elements. The first one takes an appendig -begin and the last one an -end. Currently they have to be in order in the XSD to be normally parsed by the templates so all refs etc are still ok.
Our business department wants to have the option to just specify which individual elements go in which tab and do not want them to be surrounded by an additional complex element. Not sure how this is going to be specified and how the parsing will go then, so still some work to do.
btw, there is a bug in the schema2xforms if you have multiple repeats under the root element. ref is not created ok then… I fixed this in my version of schema2xforms so that will be in after the weekend.
Cheers,
Ronald
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, it is taking a little longer since I have more changes, including changes/fixes//additions in betterFORM itself. Most important change I have now is that I want to get rid of the current way of adding to repeat nodesets and start using the XForms 1.1 context/origin construct. So stay tuned!!!
Other additions I have made (including ones to betterFORM):
- adding class/style to elements
- adding the option to specify an element is 'output'
- add constructs for custom appearances ('dialog', input like output fields)
- make it possible to add xforms markup verbatim (e.g. setvalue, action etc…)
So be a little more patient and stay tuned, still working on it…
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Guys,
I've been making so many changes and bug fixes to the schema2xforms.xsl that I think it should become a separate file in the project. I'll write an extensive blog article about all functionality so it might get some nice additional exposure.
But… I want to add one additional feature before I check it in. Being able to create a swithc/case from an xsd.
The most simple case is having a complex element that is the start of the switch and each complex element that it contains is a case. But….
Parsing this, it is needed to build the triggers outside the switch so you have to parse every element twice, or use some other clever trick. Since you guys created the core of this, maybe you know some way to do this. I did not get to grips with the whole tunneling thing in xslt yet.
Tia
Ronald
Hi Ronald!
I'm glad you found schema2xforms useful and it would be very interesting to see your changes. Regarding your question about being able to make switch/case from xsd - if you are adding new tags or adding new semantics for xsd tags, then you should make a new file and inherit from schema2xforms by importing it. See xtee2xforms.xsl for an example.
But there is also xsd:choice element, that could be basis of generating a switch/case construct. In this case the semantics of switch/case are somewhat similar to xsd:choice, so it could be included in schema2xforms.xsl. Currently there is rather complex logic with radio buttons and relevant expressions for xsd:choice, but this could be replaced with switch/case, if you prefer.
If you want to parse elements twice, just use different modes. For example:
<xsl:apply-templates mode="pass1"/>
<xsl:apply-templates mode="pass2"/>
Tunneling is quite natural construct, once you have played with parameters enough. Normally if you call template with parameters and from this template call another template, then parameters you gave to first template are not automatically passed to second template. This forces you to write code into every template, so that they accept some parameters and give the same parameters as arguments to every template they call, even if they don't use those parameters by itself. Tunneling allows you to reduce this code, similar to putting parameters in "session" in web programming paradigm.
I have found Saxon documentation very good in explaining the XSLT nuances. For example tunneling is explained in here:
http://www.saxonica.com/documentation/xsl-elements/with-param.html
I hope to see you patches soon!
Regards,
Tambet
Thanks,
What you describe about tunneling is what I understood it to be. Don't now why I had a problem with it, seems to be ok now.
Regarding parsing nodes twice had much more to do with the fact that I had to parse *other* nodes in addition to the one I was parsing at that time (filling the trigger part if you encounter the first element that needs to become a 'case'). Funny that I forgot that you do not have to work in the context of the current node, you can call templates with '/' as the context and just search for all elements that are annotated to become a case.
My current solution (which works for now but has to be adapted in the not so distant future) is to have all complex elements that need to become a switch/case construct to be annotated with an additional attribute and (unfortunately) an additional namespace. This attribute, currently called switch, takes a value that is used to group all these elements. The first one takes an appendig -begin and the last one an -end. Currently they have to be in order in the XSD to be normally parsed by the templates so all refs etc are still ok.
Our business department wants to have the option to just specify which individual elements go in which tab and do not want them to be surrounded by an additional complex element. Not sure how this is going to be specified and how the parsing will go then, so still some work to do.
btw, there is a bug in the schema2xforms if you have multiple repeats under the root element. ref is not created ok then… I fixed this in my version of schema2xforms so that will be in after the weekend.
Cheers,
Ronald
I would be very happy to have your fixes. Let me know, if it's ready.
btw, I just added mailing list wsdl2xforms-hackers@lists.sourceforge.net. You might want to join.
Sorry, it is taking a little longer since I have more changes, including changes/fixes//additions in betterFORM itself. Most important change I have now is that I want to get rid of the current way of adding to repeat nodesets and start using the XForms 1.1 context/origin construct. So stay tuned!!!
Other additions I have made (including ones to betterFORM):
- adding class/style to elements
- adding the option to specify an element is 'output'
- add constructs for custom appearances ('dialog', input like output fields)
- make it possible to add xforms markup verbatim (e.g. setvalue, action etc…)
So be a little more patient and stay tuned, still working on it…
Hi Ronald,
if you want to share some preliminarily results, you can also create a Subversion branch at https://wsdl2xforms.svn.sourceforge.net/svnroot/wsdl2xforms/wsdl2xforms/branches/.
Greetings from Berlin,
Falko
Good idea. Why didn't I think of that myself. Will do this on monday when I have access to the code again.
Will be without the xforms 1.1 things for now, but most of the rest is in place