Thread: [Xsltforms-support] Change instance via JavaScript?
Brought to you by:
alain-couthures
From: <st...@sa...> - 2011-11-01 13:18:06
|
Hello, I have an XForm in one page which I would like to update from either a second page hosted by an iframe within the first, or from a popup opened by the page. I need to change an instance value in the parent form. I can activate an xforms:trigger from an external page, but have not been able to see how to set the value with which to update the instance. So, I thought maybe updating the instance directly and then rebuild/refresh would work, but with that approach I can get as far as updating the nodeValue and then the rebuild/refresh does not update the display. What I would like to do is the kind of thing exemplified by some sample code (snarfed from the net) which is at: http://oracc.museum.upenn.edu/p2/changeme.xml Any ideas? Thanks, Steve |
From: Alain C. <ala...@ag...> - 2011-11-06 22:46:48
|
Hello Steve, > I have an XForm in one page which I would like to update from > either a second page hosted by an iframe within the first, > or from a popup opened by the page. > > I need to change an instance value in the parent form. I can > activate an xforms:trigger from an external page, but have not > been able to see how to set the value with which to update the > instance. > > So, I thought maybe updating the instance directly and then > rebuild/refresh would work, but with that approach I can get > as far as updating the nodeValue and then the rebuild/refresh > does not update the display. > > What I would like to do is the kind of thing exemplified by > some sample code (snarfed from the net) which is at: > > http://oracc.museum.upenn.edu/p2/changeme.xml > > Any ideas? Modifying an instance with Javascript instructions is always problematic because of dependencies to be set for refresh. It could also be very specific of a version of en implementation... Maybe the best way would be to just define an extension for submission: instead of "http:" or "file:", "javascript:" could be used to retrieve a string from a Javascript instruction. You could then externally activate a submit action for it. What do you think? Thanks! -Alain |
From: C. M. Sperberg-M. <cm...@bl...> - 2011-11-09 01:56:06
|
On Nov 6, 2011, at 3:41 PM, Alain Couthures wrote: >> ... > Modifying an instance with Javascript instructions is always problematic > because of dependencies to be set for refresh. It could also be very > specific of a version of en implementation... > > Maybe the best way would be to just define an extension for submission: > instead of "http:" or "file:", "javascript:" could be used to retrieve a > string from a Javascript instruction. > > You could then externally activate a submit action for it. > > What do you think? Well, I don't know about the original poster, but I think you've just explained to me how to handle a problem I was having without a trip to the server. Thank you! However, when I try to put this idea into practice, I encounter a simple practical difficulty. I want to use Javascript to manipulate a string in the document, so I write a function called, say, manipulate_string, which takes a string as argument and returns a string as its result. I can write a submission element that specifies a call to this function as the resource, and I can even specify the argument (which I have placed in an instance document for the purpose), thus: <xf:submission id="hackstring" method="get" ref="instance('stringhack')/s" replace="text" targetref="instance('stringhack')/s" > <xf:resource value="concat('javascript:manipulate_string("', instance('stringhack')/s, '")')" /> </xf:submission> But before submission, XForms appends "?s=" and the value of the XPath expression in the 'ref' attribute, which has the effect that the Javascript call is not recognized so my function never executes. Is there a way around this problem? -- **************************************************************** * 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...> - 2011-11-09 02:32:06
|
I should mention that I do realize that a simple string-to-string function can be defined as an XPath extension as shown in the page on extensions at http://en.wikibooks.org/wiki/XSLTForms/XSLTForms_only_Extensions#User-Defined_Functions -- I'm just trying to get a grip on the method of using a submission to a Javascript URI as a technique for calling Javascript from an XForms (specifically XSLTForms) context. On Nov 8, 2011, at 6:55 PM, C. M. Sperberg-McQueen wrote: > > On Nov 6, 2011, at 3:41 PM, Alain Couthures wrote: >>> ... >> Modifying an instance with Javascript instructions is always problematic >> because of dependencies to be set for refresh. It could also be very >> specific of a version of en implementation... >> >> Maybe the best way would be to just define an extension for submission: >> instead of "http:" or "file:", "javascript:" could be used to retrieve a >> string from a Javascript instruction. >> >> You could then externally activate a submit action for it. >> >> What do you think? > > > Well, I don't know about the original poster, but I think you've just > explained to me how to handle a problem I was having without a > trip to the server. Thank you! > > However, when I try to put this idea into practice, I encounter > a simple practical difficulty. I want to use Javascript to manipulate a > string in the document, so I write a function called, say, > manipulate_string, which takes a string as argument and returns > a string as its result. > > I can write a submission element that specifies a call to this > function as the resource, and I can even specify the argument > (which I have placed in an instance document for the purpose), > thus: > > <xf:submission id="hackstring" > method="get" > ref="instance('stringhack')/s" > replace="text" > targetref="instance('stringhack')/s" > > > <xf:resource > value="concat('javascript:manipulate_string("', instance('stringhack')/s, '")')" > /> > </xf:submission> > > But before submission, XForms appends "?s=" and the value of the > XPath expression in the 'ref' attribute, which has the effect that > the Javascript call is not recognized so my function never executes. > > Is there a way around this problem? > > -- > **************************************************************** > * C. M. Sperberg-McQueen, Black Mesa Technologies LLC > * http://www.blackmesatech.com > * http://cmsmcq.com/mib > * http://balisage.net > **************************************************************** > > > > -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net **************************************************************** |
From: Alain C. <ala...@ag...> - 2011-11-11 07:05:21
|
Hello, Javascript URIs are not already supported in XSLTForms for submissions. I was just asking if it could be interesting because it shouldn't be difficult to implement and it would be quite elegant. What do you think? Thanks! -Alain Le 09/11/2011 03:31, C. M. Sperberg-McQueen a écrit : > I should mention that I do realize that a simple string-to-string > function can be defined as an XPath extension as shown in the > page on extensions at > http://en.wikibooks.org/wiki/XSLTForms/XSLTForms_only_Extensions#User-Defined_Functions > -- I'm just trying to get a grip on the method of using a submission to > a Javascript URI as a technique for calling Javascript from an XForms > (specifically XSLTForms) context. > > On Nov 8, 2011, at 6:55 PM, C. M. Sperberg-McQueen wrote: > >> On Nov 6, 2011, at 3:41 PM, Alain Couthures wrote: >>>> ... >>> Modifying an instance with Javascript instructions is always problematic >>> because of dependencies to be set for refresh. It could also be very >>> specific of a version of en implementation... >>> >>> Maybe the best way would be to just define an extension for submission: >>> instead of "http:" or "file:", "javascript:" could be used to retrieve a >>> string from a Javascript instruction. >>> >>> You could then externally activate a submit action for it. >>> >>> What do you think? >> >> Well, I don't know about the original poster, but I think you've just >> explained to me how to handle a problem I was having without a >> trip to the server. Thank you! >> >> However, when I try to put this idea into practice, I encounter >> a simple practical difficulty. I want to use Javascript to manipulate a >> string in the document, so I write a function called, say, >> manipulate_string, which takes a string as argument and returns >> a string as its result. >> >> I can write a submission element that specifies a call to this >> function as the resource, and I can even specify the argument >> (which I have placed in an instance document for the purpose), >> thus: >> >> <xf:submission id="hackstring" >> method="get" >> ref="instance('stringhack')/s" >> replace="text" >> targetref="instance('stringhack')/s" >> > >> <xf:resource >> value="concat('javascript:manipulate_string("', instance('stringhack')/s, '")')" >> /> >> </xf:submission> >> >> But before submission, XForms appends "?s=" and the value of the >> XPath expression in the 'ref' attribute, which has the effect that >> the Javascript call is not recognized so my function never executes. >> >> Is there a way around this problem? >> >> -- >> **************************************************************** >> * C. M. Sperberg-McQueen, Black Mesa Technologies LLC >> * http://www.blackmesatech.com >> * http://cmsmcq.com/mib >> * http://balisage.net >> **************************************************************** >> >> >> >> |
From: <st...@sa...> - 2011-11-11 12:34:05
|
I am very inexperienced in XForms so I wonder if other XForms processors provide a javascript: submission facility as well? If it would be a defined way of doing this kind of thing only in XSLTForms I think it would still be interesting because although I have solved my immediate problem, I can't help thinking it is a bit of a hack. What I do now, in several different places in the UI, is this: Define both the target element and a dummy element in my instance: <xforms:instance id="pager"> <pager-session xmlns=""> ... <list>(none)</list> ... <dummy>dummy</dummy> </pager-session> </xforms:instance> Define a clickable button in my main form, and wrap it in a dialog which is never shown: <xforms:dialog id="listChangerDialog"> <xforms:trigger id="listChanger" name="listChanger"> <xforms:action ev:event="DOMActivate"> <xforms:setvalue ref="instance('pager')/list" value="instance('pager')/dummy"/> <xforms:send submission="post-pager"/> </xforms:action> </xforms:trigger> </xforms:dialog> As you can see, I set the actual 'list' element value from a 'dummy' element. Now, the Advanced Search popup is its own XForm. It runs the search and leaves the results in a tmpdir which it needs to pass back to the main window, the pager which allows the user to page back and forward in the results. So, in the popup XForm the instance is returned with a url: <url>javascript:oasNotify('pnveWbPgHo')</url> Which is loaded after the search completes: <xforms:submission action="/cgi-bin/oas" method="post" id="post-search" mediatype="application/xml" replace="instance"> <xforms:action ev:event="xforms-submit-done"> <xforms:load> <xforms:resource value="instance('search')/result/url"/> </xforms:load> </xforms:action> </xforms:submission> The JS function oasNotify is: function oasNotify(list) { var model = window.opener.window.document.getElementById("pagerModel"); var dummies = model.getInstanceDocument("pager").getElementsByTagName("dummy"); dummies[0].firstChild.nodeValue = list; window.opener.window.document.getElementById("listChanger").click(); } That is, it gets the pager instance from the main window (opener) and sets the dummy value in it, then clicks the hidden trigger. That trigger (back to the top of this example) sets pager/list from pager/dummy--and that is where I started this discussion: the sticking point was that if you set pager/list directly, the refresh isn't called so the instance submitted doesn't have the updated list value. By using an explicit xforms:setvalue to set it indirectly from pager/dummy, the refresh is triggered and the submitted list value is the new one. I have no illusions about whether this will work with other XForms processors--I'll just be happy if it doesn't break suddenly on XSLTForms (which I love, incidentally). If I understand your suggestion, the new code would basically cut out the copy from pager/dummy to pager/list because XSLTForms would understand that a *submission* with javascript URL might require a refresh, where it doesn't currently understand that a *load* with a javascript URL might require one. I guess it would still be necessary to have the hidden trigger to send the post-pager submission (although I can imagine it all being wrapped in one JS routine; I just don't know how to do that offhand). If you need to see the context, you can launch the beta UI at: http://oracc.museum.upenn.edu/etcsri/launch/p2 Click on 'Advanced Search' and search for, say, 'lugal' (Sumerian for "king"). That Advanced Search, btw Alain, includes the xforms:repeat inside an HTML table stuff you helped me with when I first started playing with this new UI last March--many thanks for that help, this help, and XSLTForms! Steve Quoting Alain Couthures <ala...@ag...>: > Hello, > > Javascript URIs are not already supported in XSLTForms for submissions. > > I was just asking if it could be interesting because it shouldn't be > difficult to implement and it would be quite elegant. > > What do you think? > |
From: Alain C. <ala...@ag...> - 2011-11-14 21:20:37
|
Hello, The "javascript:" support in submission has been added in rev. 515 in the SF SVN repository. Here is a test case: <html xmlns:xforms="http://www.w3.org/2002/xforms"xmlns:txs="http://www.agencexml.com/txs"xmlns="http://www.w3.org/1999/xhtml"xmlns:ev="http://www.w3.org/2001/xml-events"xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <head> <title>Javascript Submission</title> <xforms:model> <xforms:instance> <data xmlns=""> <value>Initial value</value> </data> </xforms:instance> <xforms:submission method="get"serialization="none"replace="instance"targetref="value"resource="javascript:'<value xmlns="">Javascript value at '+(new Date())+'</value>'"/> </xforms:model> </head> <body> <xforms:output value="value"/> <xforms:submit> <xforms:label>Load from Javascript</xforms:label> </xforms:submit> </body> </html> As you can see, the resource is returning the serialization of the new instance. Thank you for your feedbacks! -Alain Le 11/11/2011 13:33, st...@sa... a écrit : > I am very inexperienced in XForms so I wonder if other XForms > processors provide a javascript: submission facility as well? > > If it would be a defined way of doing this kind of thing only in > XSLTForms I think it would still be interesting because although I > have solved my immediate problem, I can't help thinking it is a > bit of a hack. > > What I do now, in several different places in the UI, is this: > > Define both the target element and a dummy element in my > instance: > > <xforms:instance id="pager"> > <pager-session xmlns=""> > ... > <list>(none)</list> > ... > <dummy>dummy</dummy> > </pager-session> > </xforms:instance> > > Define a clickable button in my main form, and wrap it in a > dialog which is never shown: > > <xforms:dialog id="listChangerDialog"> > <xforms:trigger id="listChanger" name="listChanger"> > <xforms:action ev:event="DOMActivate"> > <xforms:setvalue ref="instance('pager')/list" > value="instance('pager')/dummy"/> > <xforms:send submission="post-pager"/> > </xforms:action> > </xforms:trigger> > </xforms:dialog> > > As you can see, I set the actual 'list' element value from a > 'dummy' element. > > Now, the Advanced Search popup is its own XForm. It runs the > search and leaves the results in a tmpdir which it needs to > pass back to the main window, the pager which allows the > user to page back and forward in the results. So, in the > popup XForm the instance is returned with a url: > > <url>javascript:oasNotify('pnveWbPgHo')</url> > > Which is loaded after the search completes: > > <xforms:submission action="/cgi-bin/oas" method="post" > id="post-search" > mediatype="application/xml" > replace="instance"> > <xforms:action ev:event="xforms-submit-done"> > <xforms:load> > <xforms:resource > value="instance('search')/result/url"/> > </xforms:load> > </xforms:action> > </xforms:submission> > > The JS function oasNotify is: > > function oasNotify(list) { > var model = window.opener.window.document.getElementById("pagerModel"); > var dummies = > model.getInstanceDocument("pager").getElementsByTagName("dummy"); > dummies[0].firstChild.nodeValue = list; > window.opener.window.document.getElementById("listChanger").click(); > } > > That is, it gets the pager instance from the main window (opener) > and sets the dummy value in it, then clicks the hidden trigger. > > That trigger (back to the top of this example) sets pager/list from > pager/dummy--and that is where I started this discussion: the sticking > point was that if you set pager/list directly, the refresh isn't > called so the instance submitted doesn't have the updated list > value. By using an explicit xforms:setvalue to set it indirectly > from pager/dummy, the refresh is triggered and the submitted list > value is the new one. > > I have no illusions about whether this will work with other > XForms processors--I'll just be happy if it doesn't break > suddenly on XSLTForms (which I love, incidentally). > > If I understand your suggestion, the new code would basically > cut out the copy from pager/dummy to pager/list because XSLTForms > would understand that a *submission* with javascript URL might > require a refresh, where it doesn't currently understand that > a *load* with a javascript URL might require one. I guess > it would still be necessary to have the hidden trigger to > send the post-pager submission (although I can imagine it > all being wrapped in one JS routine; I just don't know how to > do that offhand). > > If you need to see the context, you can launch the beta UI at: > > http://oracc.museum.upenn.edu/etcsri/launch/p2 > > Click on 'Advanced Search' and search for, say, 'lugal' > (Sumerian for "king"). > > That Advanced Search, btw Alain, includes the xforms:repeat inside > an HTML table stuff you helped me with when I first started playing > with this new UI last March--many thanks for that help, this help, > and XSLTForms! > > Steve > > Quoting Alain Couthures <ala...@ag...>: > >> Hello, >> >> Javascript URIs are not already supported in XSLTForms for submissions. >> >> I was just asking if it could be interesting because it shouldn't be >> difficult to implement and it would be quite elegant. >> >> What do you think? >> > > > |
From: <st...@sa...> - 2011-11-18 04:55:34
|
This is very neat, Alain! It took me a little trial and error to figure out how to use the JS submission only for the side-effects (am I missing something simpler?) but here is an enhanced example which combines your own with a submission that sets the class: <?xml-stylesheet href="/xsltforms517/xsltforms.xsl" type="text/xsl"?> <html xmlns:xforms="http://www.w3.org/2002/xforms" xmlns:txs="http://www.agencexml.com/txs" xmlns="http://www.w3.org/1999/xhtml" xmlns:ev="http://www.w3.org/2001/xml-events" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <head> <title>Javascript Submission</title> <xforms:model> <xforms:instance> <data xmlns=""> <value>Initial value</value> </data> </xforms:instance> <xforms:submission id="class" method="get" serialization="none" replace="none" resource="javascript:setClass()"/> <xforms:submission id="value" method="get" serialization="none" replace="instance" targetref="value" resource="javascript:'<value xmlns="">Javascript value at '+(new Date())+'</value>'"/> </xforms:model> <style type="text/css"> .red { color: red; } .blue { color: blue; } </style> <script type="text/javascript"> function setClass() { var p = window.document.getElementById('par'); p.setAttribute("class", "blue"); } </script> </head> <body> <p id="par" class="red"><xforms:output value="value"/></p> <xforms:submit submission="value"> <xforms:label>Load from Javascript</xforms:label></xforms:submit> <xforms:submit submission="class"> <xforms:label>Change class</xforms:label></xforms:submit> </body> </html> It is for now online at: http://oracc.museum.upenn.edu/jsxf.xml I've used this to implement switching using the entire window for a single pane rather than splitting it between two panes. To see it in action hit: http://oracc.museum.upenn.edu/etcsri/launch/p2 Click on 'Erridupizir 1' in the right pane, and then on 'Hide Outline Pane'. Thanks for this! Steve Quoting Alain Couthures <ala...@ag...>: > Hello, > > The "javascript:" support in submission has been added in rev. 515 > in the SF SVN repository. > > Here is a test case: > > <html > xmlns:xforms="http://www.w3.org/2002/xforms"xmlns:txs="http://www.agencexml.com/txs"xmlns="http://www.w3.org/1999/xhtml"xmlns:ev="http://www.w3.org/2001/xml-events"xmlns:xsd="http://www.w3.org/2001/XMLSchema"> > <head> > <title>Javascript Submission</title> > <xforms:model> > <xforms:instance> > <data xmlns=""> > <value>Initial value</value> > </data> > > </xforms:instance> > <xforms:submission > method="get"serialization="none"replace="instance"targetref="value"resource="javascript:'<value xmlns="">Javascript value at '+(new > Date())+'</value>'"/> > </xforms:model> > </head> > <body> > <xforms:output value="value"/> > <xforms:submit> > <xforms:label>Load from Javascript</xforms:label> > > </xforms:submit> > </body> > </html> > > > As you can see, the resource is returning the serialization of the > new instance. > > Thank you for your feedbacks! > > -Alain > > Le 11/11/2011 13:33, st...@sa... a écrit : >> I am very inexperienced in XForms so I wonder if other XForms >> processors provide a javascript: submission facility as well? >> >> If it would be a defined way of doing this kind of thing only in >> XSLTForms I think it would still be interesting because although I >> have solved my immediate problem, I can't help thinking it is a >> bit of a hack. >> >> What I do now, in several different places in the UI, is this: >> >> Define both the target element and a dummy element in my >> instance: >> >> <xforms:instance id="pager"> >> <pager-session xmlns=""> >> ... >> <list>(none)</list> >> ... >> <dummy>dummy</dummy> >> </pager-session> >> </xforms:instance> >> >> Define a clickable button in my main form, and wrap it in a >> dialog which is never shown: >> >> <xforms:dialog id="listChangerDialog"> >> <xforms:trigger id="listChanger" name="listChanger"> >> <xforms:action ev:event="DOMActivate"> >> <xforms:setvalue ref="instance('pager')/list" >> value="instance('pager')/dummy"/> >> <xforms:send submission="post-pager"/> >> </xforms:action> >> </xforms:trigger> >> </xforms:dialog> >> >> As you can see, I set the actual 'list' element value from a >> 'dummy' element. >> >> Now, the Advanced Search popup is its own XForm. It runs the >> search and leaves the results in a tmpdir which it needs to >> pass back to the main window, the pager which allows the >> user to page back and forward in the results. So, in the >> popup XForm the instance is returned with a url: >> >> <url>javascript:oasNotify('pnveWbPgHo')</url> >> >> Which is loaded after the search completes: >> >> <xforms:submission action="/cgi-bin/oas" method="post" >> id="post-search" >> mediatype="application/xml" >> replace="instance"> >> <xforms:action ev:event="xforms-submit-done"> >> <xforms:load> >> <xforms:resource >> value="instance('search')/result/url"/> >> </xforms:load> >> </xforms:action> >> </xforms:submission> >> >> The JS function oasNotify is: >> >> function oasNotify(list) { >> var model = window.opener.window.document.getElementById("pagerModel"); >> var dummies = >> model.getInstanceDocument("pager").getElementsByTagName("dummy"); >> dummies[0].firstChild.nodeValue = list; >> window.opener.window.document.getElementById("listChanger").click(); >> } >> >> That is, it gets the pager instance from the main window (opener) >> and sets the dummy value in it, then clicks the hidden trigger. >> >> That trigger (back to the top of this example) sets pager/list from >> pager/dummy--and that is where I started this discussion: the sticking >> point was that if you set pager/list directly, the refresh isn't >> called so the instance submitted doesn't have the updated list >> value. By using an explicit xforms:setvalue to set it indirectly >> from pager/dummy, the refresh is triggered and the submitted list >> value is the new one. >> >> I have no illusions about whether this will work with other >> XForms processors--I'll just be happy if it doesn't break >> suddenly on XSLTForms (which I love, incidentally). >> >> If I understand your suggestion, the new code would basically >> cut out the copy from pager/dummy to pager/list because XSLTForms >> would understand that a *submission* with javascript URL might >> require a refresh, where it doesn't currently understand that >> a *load* with a javascript URL might require one. I guess >> it would still be necessary to have the hidden trigger to >> send the post-pager submission (although I can imagine it >> all being wrapped in one JS routine; I just don't know how to >> do that offhand). >> >> If you need to see the context, you can launch the beta UI at: >> >> http://oracc.museum.upenn.edu/etcsri/launch/p2 >> >> Click on 'Advanced Search' and search for, say, 'lugal' >> (Sumerian for "king"). >> >> That Advanced Search, btw Alain, includes the xforms:repeat inside >> an HTML table stuff you helped me with when I first started playing >> with this new UI last March--many thanks for that help, this help, >> and XSLTForms! >> >> Steve >> >> Quoting Alain Couthures <ala...@ag...>: >> >>> Hello, >>> >>> Javascript URIs are not already supported in XSLTForms for submissions. >>> >>> I was just asking if it could be interesting because it shouldn't be >>> difficult to implement and it would be quite elegant. >>> >>> What do you think? >>> >> >> >> > > |