Thread: [Xsltforms-support] can one automatically load a sub-form?
Brought to you by:
alain-couthures
From: C. M. Sperberg-M. <cm...@bl...> - 2016-06-18 19:22:22
|
Apologies for an ignorant question; my knowledge and understanding of the event model underlying XForms is incomplete (in the places where it exists at all). This level of ignorance is compatible with a lot of usage of XForms, as long as everything you want to happen is triggered by a button press and you can catch it with ev:event = "DOMActivate", but I find myself wanting something different for the form I'm working on right now. Subforms can be loaded on a DOMActivate event; this is reasonably straightforward. Can they be loaded on other events? in particular, can they be loaded automatically when an element matches a group in the form? Or when the main form itself is loaded? Consider two use cases: A. A user has done a search in a database and is paging through the results. The back end has sent us $rows-in-page items in the results, along with a $total-hit-count number telling us how many hits the user's query actually produced, and a $start-row number telling us where in the results this extract starts. For the first page of results, $start-row will be 1, and $rows-in-page can be adjusted by the user. Both at the top of the results display and at the bottom, I want two buttons: a Previous or Back button (iff $start-row > 1) and a Next or Forward button (iff $start-row + $rows-in-page < $total-hit-count). The logic, the markup structure, and the CSS styling of the two buttons is just complicated enough that the handling of the buttons takes up 42 lines in the example I just examined, and they get tweaked repeatedly. Keeping two occurrences of a 42-line block in synch is boring and error-prone, and having a full screen or more devoted to such secondary concerns makes the form hard to read. At the moment, I handle both of these problems by maintaining the re-used block as an external entity, which gets inserted into the main form when I run xmllint, rxp, an identity transform, or any other XML normalizer to create form.xhtml out of form.xml and its external entities. But it might be nicer to handle the repeated code by means of a sub-form. To make that work, I would need to have something at the locations where the sub-form needs to be loaded which causes the loading and which is triggered by an event generated automatically when the search results are returned. Is there a suitable event in the XForms model? Can anyone point to an example of its use? B. In a form I'm writing now, the documents being edited by the user consist of a series of top-level children of the document element, in a relatively fixed order, each top-level child having a characteristic intermal substructure. Some of the top-level elements have mixed content (for which I am using a subform); others have element-only content, but sometimes have children (or in some cases, distant descendants) which have mixed content. I would like the user to be presented, on loading a document, with read-only displays of each top-level element, and buttons offering to edit (a) the top-level mixed-content elements, and (b) the second-level elements, some of which have mixed content and others of which have other specialized needs which will be handled with other specialized sub-forms. Right now, the main structure of the form has the structure <xf:repeat nodeset="*"> <xf:group ref=".[ ... element has mixed content ...]"> ... read/edit switch; read case shows the data; edit case loads mixed-content subform ... </xf:group> <xf:group ref=".[ ... element has element-only content ... ]> <xf:repeat nodeset="*"> <xf:group ref=".[ ... element has mixed content ...]"> ... read/edit switch; read case shows the data; edit case loads mixed-content subform ... </xf:group> <xf:group ref=".[ ... element has other specialized content ...]"> ... read/edit switch; read case shows the data; edit case loads suitable subform ... </xf:group> ... </xf:repeat> </xf:group> </xf:repeat> Actually, in the current version of the form its worse than this: the read/edit switch for mixed-content elements occurs three times, not just twice. If I could (a) represent the read/edit switch for mixed content as a subform, and (b) cause that subform to load automatically at the two different locations where it's needed, then I would have less repetition in my code, fewer opportunities for unintentional inconsistency, and smaller modules which are (probably) easier to understand. If I can find a way to make this work (and especially if I can find a way to make it work recursively), then it might be possible to write XForms for documents with less repetition and in a way that feels more like the template-driven style of XSLT. (Where I come from, that would be a very good thing.) Any comments welcome. Michael Sperberg-McQueen -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net **************************************************************** |
From: Alain C. <ala...@ag...> - 2016-06-18 19:58:18
|
Michael, Subforms are loaded with the load action so any event can trigger it. If not, this would be an issue and I would be happy to have a test case if this happens. Ids are to be considered with subforms: if no static id is used in the subform, generated ids include the generated subform id. But, yet, the load action has to copy the subform content according to an id (within a repeat, every static id is actually replaced by a generated one). Adding AVT support in the load action for the targetid attribute might do the trick... There is also the xf:include/@src control, which is an extension, just to include an external file at the XSLT step. What do you think? Alain Le 18/06/2016 à 21:22, C. M. Sperberg-McQueen a écrit : > Apologies for an ignorant question; my knowledge and understanding > of the event model underlying XForms is incomplete (in the places > where it exists at all). This level of ignorance is compatible with a lot > of usage of XForms, as long as everything you want to happen is > triggered by a button press and you can catch it with ev:event > = "DOMActivate", but I find myself wanting something different for > the form I'm working on right now. > > Subforms can be loaded on a DOMActivate event; this is reasonably > straightforward. > > Can they be loaded on other events? in particular, can they be loaded > automatically when an element matches a group in the form? Or > when the main form itself is loaded? > > Consider two use cases: > > A. A user has done a search in a database and is paging through the > results. The back end has sent us $rows-in-page items in the results, > along with a $total-hit-count number telling us how many hits the > user's query actually produced, and a $start-row number telling us > where in the results this extract starts. For the first page of results, $start-row > will be 1, and $rows-in-page can be adjusted by the user. > > Both at the top of the results display and at the bottom, I want > two buttons: a Previous or Back button (iff $start-row > 1) > and a Next or Forward button (iff $start-row + $rows-in-page > < $total-hit-count). > > The logic, the markup structure, and the CSS styling of the two > buttons is just complicated enough that the handling of the buttons > takes up 42 lines in the example I just examined, and they get > tweaked repeatedly. > > Keeping two occurrences of a 42-line block in synch is boring and > error-prone, and having a full screen or more devoted to such > secondary concerns makes the form hard to read. At the moment, I > handle both of these problems by maintaining the re-used block as > an external entity, which gets inserted into the main form when I > run xmllint, rxp, an identity transform, or any other XML normalizer > to create form.xhtml out of form.xml and its external entities. > > But it might be nicer to handle the repeated code by means of a > sub-form. To make that work, I would need to have something > at the locations where the sub-form needs to be loaded which > causes the loading and which is triggered by an event generated > automatically when the search results are returned. > > Is there a suitable event in the XForms model? Can anyone point to > an example of its use? > > > B. In a form I'm writing now, the documents being edited by the user > consist of a series of top-level children of the document element, > in a relatively fixed order, each top-level child having a characteristic > intermal substructure. Some of the top-level elements have mixed > content (for which I am using a subform); others have element-only > content, but sometimes have children (or in some cases, distant > descendants) which have mixed content. > > I would like the user to be presented, on loading a document, with > read-only displays of each top-level element, and buttons offering > to edit (a) the top-level mixed-content elements, and (b) the > second-level elements, some of which have mixed content and > others of which have other specialized needs which will be handled > with other specialized sub-forms. > > Right now, the main structure of the form has the structure > > <xf:repeat nodeset="*"> > > <xf:group ref=".[ ... element has mixed content ...]"> > ... read/edit switch; read case shows the data; edit case loads > mixed-content subform ... > </xf:group> > > <xf:group ref=".[ ... element has element-only content ... ]> > <xf:repeat nodeset="*"> > > <xf:group ref=".[ ... element has mixed content ...]"> > ... read/edit switch; read case shows the data; edit > case loads mixed-content subform ... > </xf:group> > > <xf:group ref=".[ ... element has other specialized content ...]"> > ... read/edit switch; read case shows the data; edit > case loads suitable subform ... > </xf:group> > > ... > > </xf:repeat> > </xf:group> > </xf:repeat> > > Actually, in the current version of the form its worse than this: the > read/edit switch for mixed-content elements occurs three times, not just > twice. > > If I could (a) represent the read/edit switch for mixed content as a subform, > and (b) cause that subform to load automatically at the two different locations > where it's needed, then I would have less repetition in my code, fewer > opportunities for unintentional inconsistency, and smaller modules > which are (probably) easier to understand. > > If I can find a way to make this work (and especially if I can find a way > to make it work recursively), then it might be possible to write XForms > for documents with less repetition and in a way that feels more like > the template-driven style of XSLT. (Where I come from, that would be > a very good thing.) > > Any comments welcome. > > Michael Sperberg-McQueen > > |
From: C. M. Sperberg-M. <cm...@bl...> - 2016-06-18 21:03:42
|
On Jun 18, 2016, at 1:44 PM, Alain Couthures wrote: > Michael, > > Subforms are loaded with the load action so any event can trigger it. If not, this would be an issue and I would be happy to have a test case if this happens. Thank you very much for this reply. I keep hoping to find a simple, clear description of how the event system works that will be less effort to read than the DOM2 events spec and the XML Events spec. But my hopes keep being disappointed. So I will need to read the specs, I guess. > Ids are to be considered with subforms: if no static id is used in the subform, generated ids include the generated subform id. But, yet, the load action has to copy the subform content according to an id (within a repeat, every static id is actually replaced by a generated one). Adding AVT support in the load action for the targetid attribute might do the trick... I will keep that in mind. I have been fortunate enough so far to be able to use subforms and repeats without ever fully understanding the black magic performed on IDs by XSLTForms in handling repeats and subforms. > > There is also the xf:include/@src control, which is an extension, just to include an external file at the XSLT step. That may be the simplest step forward for the two use cases I mentioned. > > What do you think? I think I am in your debt, is what I think. Thank you very much. Michael -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net **************************************************************** |
From: C. M. Sperberg-M. <cm...@bl...> - 2016-07-02 16:43:04
|
On Jun 18, 2016, at 1:44 PM, Alain Couthures wrote: > Michael, > > Subforms are loaded with the load action so any event can trigger it. If > not, this would be an issue and I would be happy to have a test case if > this happens. > ... > > There is also the xf:include/@src control, which is an extension, just > to include an external file at the XSLT step. I have found xf:include very useful, and I find myself wanting to use it frequently. But I have run into one difficulty. I have the impression that xf:include works in the main form, and in XML documents included by means of xf:include, but not in subforms. The example at [1] illustrates what I mean: when books.xml is loaded as a main form, it includes (via xf:include) a paragraph saying how many books it is displaying; when the same form is loaded as a subform, this information does not appear. [1] http://blackmesatech.com/2016/06/subformstest/include-test.xhtml Is this a bug or a design feature? Michael -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net **************************************************************** |
From: Alain C. <ala...@ag...> - 2016-07-03 09:54:00
|
There are some funny security reasons in Google Chrome for not allowing the document() function in XSLT only when executed from Javascript. This test case works with Firefox and Internet Explorer (there is an issue with Edge...) and does not work with Opera (WebKit too...). Issues in XSLT support are the main reasons for me to write XSLTForms 2 without the necessity for XSLT! --Alain Le 02/07/2016 à 18:42, C. M. Sperberg-McQueen a écrit : > On Jun 18, 2016, at 1:44 PM, Alain Couthures wrote: > >> Michael, >> >> Subforms are loaded with the load action so any event can trigger it. If >> not, this would be an issue and I would be happy to have a test case if >> this happens. >> ... >> >> There is also the xf:include/@src control, which is an extension, just >> to include an external file at the XSLT step. > I have found xf:include very useful, and I find myself wanting to use > it frequently. But I have run into one difficulty. > > I have the impression that xf:include works in the main form, > and in XML documents included by means of xf:include, but not in > subforms. The example at [1] illustrates what I mean: when books.xml > is loaded as a main form, it includes (via xf:include) a paragraph > saying how many books it is displaying; when the same form is > loaded as a subform, this information does not appear. > > [1] http://blackmesatech.com/2016/06/subformstest/include-test.xhtml > > Is this a bug or a design feature? > > Michael > |
From: C. M. Sperberg-M. <cm...@bl...> - 2016-07-04 14:10:25
|
On Jul 3, 2016, at 3:53 AM, Alain Couthures wrote: > There are some funny security reasons in Google Chrome for not allowing the document() function in XSLT only when executed from Javascript. > > This test case works with Firefox and Internet Explorer (there is an issue with Edge...) and does not work with Opera (WebKit too...). > > Issues in XSLT support are the main reasons for me to write XSLTForms 2 without the necessity for XSLT! Thank you for the clarification; this is an interoperability issue in the browsers' XSLT support that I hadn't encountered before. I look forward to XSLTForms 2, but hope that transform() will be retained even if XSLT is not used for the main form itself. --Michael > > --Alain > > Le 02/07/2016 à 18:42, C. M. Sperberg-McQueen a écrit : >> On Jun 18, 2016, at 1:44 PM, Alain Couthures wrote: >> >>> Michael, >>> >>> Subforms are loaded with the load action so any event can trigger it. If >>> not, this would be an issue and I would be happy to have a test case if >>> this happens. >>> ... >>> >>> There is also the xf:include/@src control, which is an extension, just >>> to include an external file at the XSLT step. >> I have found xf:include very useful, and I find myself wanting to use >> it frequently. But I have run into one difficulty. >> >> I have the impression that xf:include works in the main form, >> and in XML documents included by means of xf:include, but not in >> subforms. The example at [1] illustrates what I mean: when books.xml >> is loaded as a main form, it includes (via xf:include) a paragraph >> saying how many books it is displaying; when the same form is >> loaded as a subform, this information does not appear. >> >> [1] http://blackmesatech.com/2016/06/subformstest/include-test.xhtml >> >> Is this a bug or a design feature? >> >> Michael >> > -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net **************************************************************** |