Two questions related to running XForms 1.1 test suite automaticly (xf:message, How do you know when an AJAX call has returned)
Locked
 
|
Erik, Alessandro,
While working on a test harness for the XForms 1.1 test suite (http://github.com/nvdbleek/com.orbeon.testsuite.w3c ) I hit the following two problems which I'm a bit stuck on. 1. xf:message uses javascript alert() The XForms 1.1 uses an xf:message in a lot of tests to display a message to the user. In orbeon the message is shown to the user using the javascript alert function. The alert box blocks all javascript execution (javascript is single threaded if you don't use workers). And therefore selenium can't test for alert boxes when they are shown before selenium can execute the code to replace the alert method (they replace it with a function so they can check if there was an alert and what the message was, but for all messages shown before xforms-ready finishes this fails, and this feature is heavily used by the tests). To work around this issue I wanted to replace the code that handles the xf:message in xforms.js with if (ORBEON.util.Dom.getAttribute(messageElement, "level") == "modal") { if (ORBEON.xforms.Globals.alertDialog == null) { YUI alert dialog used by alert action ORBEON.xforms.Globals.alertDialog = new YAHOO.widget.SimpleDialog("alert_dlg1", { width : "200px", effect : { effect : YAHOO.widget.ContainerEffect.FADE, duration : 0.15 }, fixedcenter : true, modal : true, visible : false, close : true, constraintoviewport : true, buttons : [ { text : "close", handler : function() { this.hide(); }, isDefault : true } ], draggable : false, effect : [ { effect : YAHOO.widget.ContainerEffect.FADE, duration : 0.1 } ] }); ORBEON.xforms.Globals.alertDialog.form = ORBEON.xforms.Globals.requestForm; ORBEON.xforms.Globals.alertDialog.setHeader("Alert"); ORBEON.xforms.Globals.alertDialog.render(document.body); } ORBEON.xforms.Globals.alertDialog.cfg.setProperty("text",message); ORBEON.xforms.Globals.alertDialog.show(); } But this messes up the form object. I saw that Orbeon patched the dialog for a similar reason I guess... What is you're opinion in changing the xf:message to a YUI dialog? It will also introduce a behavior change if implemented like this. Namely when you use alert and have actions (possibly other xf:message actions) after the xf:message those will be handled (likely) before the user confirms the message. If you make the action list global and handle the next action when the dialog is confirmed, you can still have the old behavior. But this requires quite some changes (and the handleResponseDom method should also check if there is currently no message shown when it is first called, if so it should add his actions to the global action list). What do you think of this? Another approach is to leave alone the current implementation, and only change the xf:message handler when it is running tests. It could just append the message to a global list of non-confirmed messages, and the test can remove the item when it expects a message (and check at the end if the list is empty -> if no messages should be shown in the test it should assert this). This has the main advantage that the change is simple and only affects the current code when we are testing (we could do this by a special attribute on the xf:message element or a configuration option). The main disadvantage is that you aren't testing the code that the user will use when he is running the form in real-life mode. I'm interested in what your opinion is about this 'issue' and how I or we can solve my problem. 2. How do you know when an AJAX call has returned (selection option, typing text,...) I found 'ORBEON.xforms.Globals.requestInProgress || ORBEON.xforms.Globals.eventQueue.length > 0' but in some cases the boolean isn't true yet and the event isn't yet in eventQueue. Is there a reliable way to know if all the updates for the operation (typing text, selectin an option) is done? -- Regards, Nick Van den Bleeken -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help OW2 mailing lists service home page: http://www.ow2.org/wws |
Re: Two questions related to running XForms 1.1 test suite automaticly (xf:message, How do you know when an AJAX call has returned)
|
|
Nick,
(It seems my GTD system doesn't work very well.) 1. We think it would be great to use a lightweight dialog for xf:message. As far as the order is concerned: I don't think we need to worry too much about this, because anyway the server doesn't keep message, load, and scripts in the proper order. So we can worry about that later I think. We should probably keep the old native alert code and switch between native/lightweight with a property. 2. There is a JS ORBEON.util.Test.executeCausingAjaxRequest() used for tests. You should be able to use that. See for example in currency-unittest.js. -Erik On Sat, Jan 23, 2010 at 9:59 AM, Nick Van den Bleeken <[hidden email]> wrote: > Erik, Alessandro, > > While working on a test harness for the XForms 1.1 test suite > (http://github.com/nvdbleek/com.orbeon.testsuite.w3c ) I hit the > following two problems which I'm a bit stuck on. > > 1. xf:message uses javascript alert() > > The XForms 1.1 uses an xf:message in a lot of tests to display a > message to the user. In orbeon the message is shown to the user using > the javascript alert function. The alert box blocks all javascript > execution (javascript is single threaded if you don't use workers). > And therefore selenium can't test for alert boxes when they are shown > before selenium can execute the code to replace the alert method (they > replace it with a function so they can check if there was an alert and > what the message was, but for all messages shown before xforms-ready > finishes this fails, and this feature is heavily used by the tests). > > To work around this issue I wanted to replace the code that handles > the xf:message in xforms.js with > > if (ORBEON.util.Dom.getAttribute(messageElement, "level") == "modal") { > if (ORBEON.xforms.Globals.alertDialog == null) { > YUI alert dialog used by alert action > ORBEON.xforms.Globals.alertDialog = new > YAHOO.widget.SimpleDialog("alert_dlg1", { > width : "200px", > effect : { > effect : YAHOO.widget.ContainerEffect.FADE, > duration : 0.15 > }, > fixedcenter : true, > modal : true, > visible : false, > close : true, > constraintoviewport : true, > buttons : [ { > text : "close", > handler : function() { > this.hide(); > }, > isDefault : true > } ], > draggable : false, > effect : [ { > effect : YAHOO.widget.ContainerEffect.FADE, > duration : 0.1 > } ] > }); > > ORBEON.xforms.Globals.alertDialog.form = ORBEON.xforms.Globals.requestForm; > ORBEON.xforms.Globals.alertDialog.setHeader("Alert"); > ORBEON.xforms.Globals.alertDialog.render(document.body); > } > ORBEON.xforms.Globals.alertDialog.cfg.setProperty("text",message); > ORBEON.xforms.Globals.alertDialog.show(); > } > > But this messes up the form object. I saw that Orbeon patched the > dialog for a similar reason I guess... > > What is you're opinion in changing the xf:message to a YUI dialog? It > will also introduce a behavior change if implemented like this. Namely > when you use alert and have actions (possibly other xf:message > actions) after the xf:message those will be handled (likely) before > the user confirms the message. If you make the action list global and > handle the next action when the dialog is confirmed, you can still > have the old behavior. But this requires quite some changes (and the > handleResponseDom method should also check if there is currently no > message shown when it is first called, if so it should add his actions > to the global action list). What do you think of this? > > Another approach is to leave alone the current implementation, and > only change the xf:message handler when it is running tests. It could > just append the message to a global list of non-confirmed messages, > and the test can remove the item when it expects a message (and check > at the end if the list is empty -> if no messages should be shown in > the test it should assert this). This has the main advantage that the > change is simple and only affects the current code when we are testing > (we could do this by a special attribute on the xf:message element or > a configuration option). The main disadvantage is that you aren't > testing the code that the user will use when he is running the form in > real-life mode. > > I'm interested in what your opinion is about this 'issue' and how I or > we can solve my problem. > > > > 2. How do you know when an AJAX call has returned (selection option, > typing text,...) > > I found 'ORBEON.xforms.Globals.requestInProgress || > ORBEON.xforms.Globals.eventQueue.length > 0' but in some cases the > boolean isn't true yet and the event isn't yet in eventQueue. Is there > a reliable way to know if all the updates for the operation (typing > text, selectin an option) is done? > -- > Regards, > > Nick Van den Bleeken > > > -- > You receive this message as a subscriber of the [hidden email] mailing list. > To unsubscribe: mailto:[hidden email] > For general help: mailto:[hidden email]?subject=help > OW2 mailing lists service home page: http://www.ow2.org/wws > > -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help OW2 mailing lists service home page: http://www.ow2.org/wws |
|
|
Hi Erik,
I implemented xf:message using a YUI Panel. Could you have a look at it ( http://github.com/nvdbleek/orbeon-forms/commit/4e88fd8d73da014b3758ef972135f4e81fb3002c ), any comments for improvements are welcome. And if it is good enough to be merged to the Orbeon please tree go ahead ;) I tested it with message sandbox sample, and a form that sends multiple messages. Regards, Nick On Fri, Feb 5, 2010 at 02:10, Erik Bruchez-3 [via Orbeon Forms (ops-users)] <[hidden email]> wrote: > Nick, > > (It seems my GTD system doesn't work very well.) > > 1. We think it would be great to use a lightweight dialog for xf:message. > > As far as the order is concerned: I don't think we need to worry too > much about this, because anyway the server doesn't keep message, load, > and scripts in the proper order. So we can worry about that later I > think. > > We should probably keep the old native alert code and switch between > native/lightweight with a property. > > 2. There is a JS ORBEON.util.Test.executeCausingAjaxRequest() used for > tests. You should be able to use that. See for example in > currency-unittest.js. > > -Erik > > On Sat, Jan 23, 2010 at 9:59 AM, Nick Van den Bleeken <[hidden email]> > wrote: >> Erik, Alessandro, >> >> While working on a test harness for the XForms 1.1 test suite >> (http://github.com/nvdbleek/com.orbeon.testsuite.w3c ) I hit the >> following two problems which I'm a bit stuck on. >> >> 1. xf:message uses javascript alert() >> >> The XForms 1.1 uses an xf:message in a lot of tests to display a >> message to the user. In orbeon the message is shown to the user using >> the javascript alert function. The alert box blocks all javascript >> execution (javascript is single threaded if you don't use workers). >> And therefore selenium can't test for alert boxes when they are shown >> before selenium can execute the code to replace the alert method (they >> replace it with a function so they can check if there was an alert and >> what the message was, but for all messages shown before xforms-ready >> finishes this fails, and this feature is heavily used by the tests). >> >> To work around this issue I wanted to replace the code that handles >> the xf:message in xforms.js with >> >> if (ORBEON.util.Dom.getAttribute(messageElement, "level") == "modal") { >> if (ORBEON.xforms.Globals.alertDialog == null) { >> YUI alert dialog used by alert action >> ORBEON.xforms.Globals.alertDialog = new >> YAHOO.widget.SimpleDialog("alert_dlg1", { >> width : "200px", >> effect : { >> effect : YAHOO.widget.ContainerEffect.FADE, >> duration : 0.15 >> }, >> fixedcenter : true, >> modal : true, >> visible : false, >> close : true, >> constraintoviewport : true, >> buttons : [ { >> text : "close", >> handler : function() { >> this.hide(); >> }, >> isDefault : true >> } ], >> draggable : false, >> effect : [ { >> effect : YAHOO.widget.ContainerEffect.FADE, >> duration : 0.1 >> } ] >> }); >> >> ORBEON.xforms.Globals.alertDialog.form = >> ORBEON.xforms.Globals.requestForm; >> ORBEON.xforms.Globals.alertDialog.setHeader("Alert"); >> ORBEON.xforms.Globals.alertDialog.render(document.body); >> } >> ORBEON.xforms.Globals.alertDialog.cfg.setProperty("text",message); >> ORBEON.xforms.Globals.alertDialog.show(); >> } >> >> But this messes up the form object. I saw that Orbeon patched the >> dialog for a similar reason I guess... >> >> What is you're opinion in changing the xf:message to a YUI dialog? It >> will also introduce a behavior change if implemented like this. Namely >> when you use alert and have actions (possibly other xf:message >> actions) after the xf:message those will be handled (likely) before >> the user confirms the message. If you make the action list global and >> handle the next action when the dialog is confirmed, you can still >> have the old behavior. But this requires quite some changes (and the >> handleResponseDom method should also check if there is currently no >> message shown when it is first called, if so it should add his actions >> to the global action list). What do you think of this? >> >> Another approach is to leave alone the current implementation, and >> only change the xf:message handler when it is running tests. It could >> just append the message to a global list of non-confirmed messages, >> and the test can remove the item when it expects a message (and check >> at the end if the list is empty -> if no messages should be shown in >> the test it should assert this). This has the main advantage that the >> change is simple and only affects the current code when we are testing >> (we could do this by a special attribute on the xf:message element or >> a configuration option). The main disadvantage is that you aren't >> testing the code that the user will use when he is running the form in >> real-life mode. >> >> I'm interested in what your opinion is about this 'issue' and how I or >> we can solve my problem. >> >> >> >> 2. How do you know when an AJAX call has returned (selection option, >> typing text,...) >> >> I found 'ORBEON.xforms.Globals.requestInProgress || >> ORBEON.xforms.Globals.eventQueue.length > 0' but in some cases the >> boolean isn't true yet and the event isn't yet in eventQueue. Is there >> a reliable way to know if all the updates for the operation (typing >> text, selectin an option) is done? >> -- >> Regards, >> >> Nick Van den Bleeken >> >> >> -- >> You receive this message as a subscriber of the [hidden email] mailing >> list. >> To unsubscribe: mailto:[hidden email] >> For general help: mailto:[hidden email]?subject=help >> OW2 mailing lists service home page: http://www.ow2.org/wws >> >> > > -- > You receive this message as a subscriber of the [hidden email] mailing list. > To unsubscribe: mailto:[hidden email] > For general help: mailto:[hidden email]?subject=help > OW2 mailing lists service home page: http://www.ow2.org/wws > > > ________________________________ > View message @ > http://n4.nabble.com/Two-questions-related-to-running-XForms-1-1-test-suite-automaticly-xf-message-How-do-you-know-when-a-tp1288325p1469658.html > To start a new topic under ObjectWeb OPS - Users, email > [hidden email] > To unsubscribe from ObjectWeb OPS - Users, click here. > -- Regards, Nick Van den Bleeken |
Re: Re: Two questions related to running XForms 1.1 testsuiteautomaticly (xf:message, How do you know when an AJAX call has returned)
|
|
Nick,
Excellent! We will review this. BTW I think you might have forgotten to commit message-dialog.xml. Can you add it? -Erik On Fri, Feb 12, 2010 at 11:48 AM, nvdbleek <[hidden email]> wrote: > Hi Erik, > > I implemented xf:message using a YUI Panel. Could you have a look at > it ( > http://github.com/nvdbleek/orbeon-forms/commit/4e88fd8d73da014b3758ef972135f4e81fb3002c > ), any comments for improvements are welcome. And if it is good enough > to be merged to the Orbeon please tree go ahead ;) > > I tested it with message sandbox sample, and a form that sends > multiple messages. > > Regards, > > Nick > > On Fri, Feb 5, 2010 at 02:10, Erik Bruchez-3 [via Orbeon Forms > (ops-users)] <[hidden email]> wrote: >> Nick, >> >> (It seems my GTD system doesn't work very well.) >> >> 1. We think it would be great to use a lightweight dialog for xf:message. >> >> As far as the order is concerned: I don't think we need to worry too >> much about this, because anyway the server doesn't keep message, load, >> and scripts in the proper order. So we can worry about that later I >> think. >> >> We should probably keep the old native alert code and switch between >> native/lightweight with a property. >> >> 2. There is a JS ORBEON.util.Test.executeCausingAjaxRequest() used for >> tests. You should be able to use that. See for example in >> currency-unittest.js. >> >> -Erik >> >> On Sat, Jan 23, 2010 at 9:59 AM, Nick Van den Bleeken <[hidden email]> >> wrote: >>> Erik, Alessandro, >>> >>> While working on a test harness for the XForms 1.1 test suite >>> (http://github.com/nvdbleek/com.orbeon.testsuite.w3c ) I hit the >>> following two problems which I'm a bit stuck on. >>> >>> 1. xf:message uses javascript alert() >>> >>> The XForms 1.1 uses an xf:message in a lot of tests to display a >>> message to the user. In orbeon the message is shown to the user using >>> the javascript alert function. The alert box blocks all javascript >>> execution (javascript is single threaded if you don't use workers). >>> And therefore selenium can't test for alert boxes when they are shown >>> before selenium can execute the code to replace the alert method (they >>> replace it with a function so they can check if there was an alert and >>> what the message was, but for all messages shown before xforms-ready >>> finishes this fails, and this feature is heavily used by the tests). >>> >>> To work around this issue I wanted to replace the code that handles >>> the xf:message in xforms.js with >>> >>> if (ORBEON.util.Dom.getAttribute(messageElement, "level") == "modal") { >>> if (ORBEON.xforms.Globals.alertDialog == null) { >>> YUI alert dialog used by alert action >>> ORBEON.xforms.Globals.alertDialog = new >>> YAHOO.widget.SimpleDialog("alert_dlg1", { >>> width : "200px", >>> effect : { >>> effect : >>> YAHOO.widget.ContainerEffect.FADE, >>> duration : 0.15 >>> }, >>> fixedcenter : true, >>> modal : true, >>> visible : false, >>> close : true, >>> constraintoviewport : true, >>> buttons : [ { >>> text : "close", >>> handler : function() { >>> this.hide(); >>> }, >>> isDefault : true >>> } ], >>> draggable : false, >>> effect : [ { >>> effect : >>> YAHOO.widget.ContainerEffect.FADE, >>> duration : 0.1 >>> } ] >>> }); >>> >>> ORBEON.xforms.Globals.alertDialog.form = >>> ORBEON.xforms.Globals.requestForm; >>> ORBEON.xforms.Globals.alertDialog.setHeader("Alert"); >>> ORBEON.xforms.Globals.alertDialog.render(document.body); >>> } >>> ORBEON.xforms.Globals.alertDialog.cfg.setProperty("text",message); >>> ORBEON.xforms.Globals.alertDialog.show(); >>> } >>> >>> But this messes up the form object. I saw that Orbeon patched the >>> dialog for a similar reason I guess... >>> >>> What is you're opinion in changing the xf:message to a YUI dialog? It >>> will also introduce a behavior change if implemented like this. Namely >>> when you use alert and have actions (possibly other xf:message >>> actions) after the xf:message those will be handled (likely) before >>> the user confirms the message. If you make the action list global and >>> handle the next action when the dialog is confirmed, you can still >>> have the old behavior. But this requires quite some changes (and the >>> handleResponseDom method should also check if there is currently no >>> message shown when it is first called, if so it should add his actions >>> to the global action list). What do you think of this? >>> >>> Another approach is to leave alone the current implementation, and >>> only change the xf:message handler when it is running tests. It could >>> just append the message to a global list of non-confirmed messages, >>> and the test can remove the item when it expects a message (and check >>> at the end if the list is empty -> if no messages should be shown in >>> the test it should assert this). This has the main advantage that the >>> change is simple and only affects the current code when we are testing >>> (we could do this by a special attribute on the xf:message element or >>> a configuration option). The main disadvantage is that you aren't >>> testing the code that the user will use when he is running the form in >>> real-life mode. >>> >>> I'm interested in what your opinion is about this 'issue' and how I or >>> we can solve my problem. >>> >>> >>> >>> 2. How do you know when an AJAX call has returned (selection option, >>> typing text,...) >>> >>> I found 'ORBEON.xforms.Globals.requestInProgress || >>> ORBEON.xforms.Globals.eventQueue.length > 0' but in some cases the >>> boolean isn't true yet and the event isn't yet in eventQueue. Is there >>> a reliable way to know if all the updates for the operation (typing >>> text, selectin an option) is done? >>> -- >>> Regards, >>> >>> Nick Van den Bleeken >>> >>> >>> -- >>> You receive this message as a subscriber of the [hidden email] mailing >>> list. >>> To unsubscribe: mailto:[hidden email] >>> For general help: mailto:[hidden email]?subject=help >>> OW2 mailing lists service home page: http://www.ow2.org/wws >>> >>> >> >> -- >> You receive this message as a subscriber of the [hidden email] mailing >> list. >> To unsubscribe: mailto:[hidden email] >> For general help: mailto:[hidden email]?subject=help >> OW2 mailing lists service home page: http://www.ow2.org/wws >> >> >> ________________________________ >> View message @ >> >> http://n4.nabble.com/Two-questions-related-to-running-XForms-1-1-test-suite-automaticly-xf-message-How-do-you-know-when-a-tp1288325p1469658.html >> To start a new topic under ObjectWeb OPS - Users, email >> [hidden email] >> To unsubscribe from ObjectWeb OPS - Users, click here. >> > > > -- > Regards, > > Nick Van den Bleeken > > ________________________________ > View this message in context: Re: Two questions related to running XForms > 1.1 test suite automaticly (xf:message, How do you know when an AJAX call > has returned) > Sent from the ObjectWeb OPS - Users mailing list archive at Nabble.com. > > > -- > You receive this message as a subscriber of the [hidden email] mailing > list. > To unsubscribe: mailto:[hidden email] > For general help: mailto:[hidden email]?subject=help > OW2 mailing lists service home page: http://www.ow2.org/wws > > -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help OW2 mailing lists service home page: http://www.ow2.org/wws |
|
|
Erik,
Thank you for the quick response, I added message-dialog.xml ( http://github.com/nvdbleek/orbeon-forms/commit/5ca143fcf5d636ae968ed766265fa688e967948c ). I hope the next commit will be correct right away... Regards, Nick On Sat, Feb 13, 2010 at 03:00, Erik Bruchez-3 [via Orbeon Forms (ops-users)] <[hidden email]> wrote: > Nick, > > Excellent! We will review this. BTW I think you might have forgotten > to commit message-dialog.xml. Can you add it? > > -Erik > > On Fri, Feb 12, 2010 at 11:48 AM, nvdbleek <[hidden email]> wrote: >> Hi Erik, >> >> I implemented xf:message using a YUI Panel. Could you have a look at >> it ( >> >> http://github.com/nvdbleek/orbeon-forms/commit/4e88fd8d73da014b3758ef972135f4e81fb3002c >> ), any comments for improvements are welcome. And if it is good enough >> to be merged to the Orbeon please tree go ahead ;) >> >> I tested it with message sandbox sample, and a form that sends >> multiple messages. >> >> Regards, >> >> Nick >> >> On Fri, Feb 5, 2010 at 02:10, Erik Bruchez-3 [via Orbeon Forms >> (ops-users)] <[hidden email]> wrote: >>> Nick, >>> >>> (It seems my GTD system doesn't work very well.) >>> >>> 1. We think it would be great to use a lightweight dialog for xf:message. >>> >>> As far as the order is concerned: I don't think we need to worry too >>> much about this, because anyway the server doesn't keep message, load, >>> and scripts in the proper order. So we can worry about that later I >>> think. >>> >>> We should probably keep the old native alert code and switch between >>> native/lightweight with a property. >>> >>> 2. There is a JS ORBEON.util.Test.executeCausingAjaxRequest() used for >>> tests. You should be able to use that. See for example in >>> currency-unittest.js. >>> >>> -Erik >>> >>> On Sat, Jan 23, 2010 at 9:59 AM, Nick Van den Bleeken <[hidden email]> >>> wrote: >>>> Erik, Alessandro, >>>> >>>> While working on a test harness for the XForms 1.1 test suite >>>> (http://github.com/nvdbleek/com.orbeon.testsuite.w3c ) I hit the >>>> following two problems which I'm a bit stuck on. >>>> >>>> 1. xf:message uses javascript alert() >>>> >>>> The XForms 1.1 uses an xf:message in a lot of tests to display a >>>> message to the user. In orbeon the message is shown to the user using >>>> the javascript alert function. The alert box blocks all javascript >>>> execution (javascript is single threaded if you don't use workers). >>>> And therefore selenium can't test for alert boxes when they are shown >>>> before selenium can execute the code to replace the alert method (they >>>> replace it with a function so they can check if there was an alert and >>>> what the message was, but for all messages shown before xforms-ready >>>> finishes this fails, and this feature is heavily used by the tests). >>>> >>>> To work around this issue I wanted to replace the code that handles >>>> the xf:message in xforms.js with >>>> >>>> if (ORBEON.util.Dom.getAttribute(messageElement, "level") == "modal") { >>>> if (ORBEON.xforms.Globals.alertDialog == null) { >>>> YUI alert dialog used by alert action >>>> ORBEON.xforms.Globals.alertDialog = new >>>> YAHOO.widget.SimpleDialog("alert_dlg1", { >>>> width : "200px", >>>> effect : { >>>> effect : >>>> YAHOO.widget.ContainerEffect.FADE, >>>> duration : 0.15 >>>> }, >>>> fixedcenter : true, >>>> modal : true, >>>> visible : false, >>>> close : true, >>>> constraintoviewport : true, >>>> buttons : [ { >>>> text : "close", >>>> handler : function() { >>>> this.hide(); >>>> }, >>>> isDefault : true >>>> } ], >>>> draggable : false, >>>> effect : [ { >>>> effect : >>>> YAHOO.widget.ContainerEffect.FADE, >>>> duration : 0.1 >>>> } ] >>>> }); >>>> >>>> ORBEON.xforms.Globals.alertDialog.form = >>>> ORBEON.xforms.Globals.requestForm; >>>> ORBEON.xforms.Globals.alertDialog.setHeader("Alert"); >>>> ORBEON.xforms.Globals.alertDialog.render(document.body); >>>> } >>>> >>>> ORBEON.xforms.Globals.alertDialog.cfg.setProperty("text",message); >>>> ORBEON.xforms.Globals.alertDialog.show(); >>>> } >>>> >>>> But this messes up the form object. I saw that Orbeon patched the >>>> dialog for a similar reason I guess... >>>> >>>> What is you're opinion in changing the xf:message to a YUI dialog? It >>>> will also introduce a behavior change if implemented like this. Namely >>>> when you use alert and have actions (possibly other xf:message >>>> actions) after the xf:message those will be handled (likely) before >>>> the user confirms the message. If you make the action list global and >>>> handle the next action when the dialog is confirmed, you can still >>>> have the old behavior. But this requires quite some changes (and the >>>> handleResponseDom method should also check if there is currently no >>>> message shown when it is first called, if so it should add his actions >>>> to the global action list). What do you think of this? >>>> >>>> Another approach is to leave alone the current implementation, and >>>> only change the xf:message handler when it is running tests. It could >>>> just append the message to a global list of non-confirmed messages, >>>> and the test can remove the item when it expects a message (and check >>>> at the end if the list is empty -> if no messages should be shown in >>>> the test it should assert this). This has the main advantage that the >>>> change is simple and only affects the current code when we are testing >>>> (we could do this by a special attribute on the xf:message element or >>>> a configuration option). The main disadvantage is that you aren't >>>> testing the code that the user will use when he is running the form in >>>> real-life mode. >>>> >>>> I'm interested in what your opinion is about this 'issue' and how I or >>>> we can solve my problem. >>>> >>>> >>>> >>>> 2. How do you know when an AJAX call has returned (selection option, >>>> typing text,...) >>>> >>>> I found 'ORBEON.xforms.Globals.requestInProgress || >>>> ORBEON.xforms.Globals.eventQueue.length > 0' but in some cases the >>>> boolean isn't true yet and the event isn't yet in eventQueue. Is there >>>> a reliable way to know if all the updates for the operation (typing >>>> text, selectin an option) is done? >>>> -- >>>> Regards, >>>> >>>> Nick Van den Bleeken >>>> >>>> >>>> -- >>>> You receive this message as a subscriber of the [hidden email] mailing >>>> list. >>>> To unsubscribe: mailto:[hidden email] >>>> For general help: mailto:[hidden email]?subject=help >>>> OW2 mailing lists service home page: http://www.ow2.org/wws >>>> >>>> >>> >>> -- >>> You receive this message as a subscriber of the [hidden email] mailing >>> list. >>> To unsubscribe: mailto:[hidden email] >>> For general help: mailto:[hidden email]?subject=help >>> OW2 mailing lists service home page: http://www.ow2.org/wws >>> >>> >>> ________________________________ >>> View message @ >>> >>> >>> http://n4.nabble.com/Two-questions-related-to-running-XForms-1-1-test-suite-automaticly-xf-message-How-do-you-know-when-a-tp1288325p1469658.html >>> To start a new topic under ObjectWeb OPS - Users, email >>> [hidden email] >>> To unsubscribe from ObjectWeb OPS - Users, click here. >>> >> >> >> -- >> Regards, >> >> Nick Van den Bleeken >> >> ________________________________ >> View this message in context: Re: Two questions related to running XForms >> 1.1 test suite automaticly (xf:message, How do you know when an AJAX call >> has returned) >> Sent from the ObjectWeb OPS - Users mailing list archive at Nabble.com. >> >> >> -- >> You receive this message as a subscriber of the [hidden email] mailing >> list. >> To unsubscribe: mailto:[hidden email] >> For general help: mailto:[hidden email]?subject=help >> OW2 mailing lists service home page: http://www.ow2.org/wws >> >> > > -- > You receive this message as a subscriber of the [hidden email] mailing list. > To unsubscribe: mailto:[hidden email] > For general help: mailto:[hidden email]?subject=help > OW2 mailing lists service home page: http://www.ow2.org/wws > > > ________________________________ > View message @ > http://n4.nabble.com/Two-questions-related-to-running-XForms-1-1-test-suite-automaticly-xf-message-How-do-you-know-when-a-tp1288325p1497907.html > To start a new topic under ObjectWeb OPS - Users, email > [hidden email] > To unsubscribe from ObjectWeb OPS - Users, click here. > -- Regards, Nick Van den Bleeken |
Re: Re: Re: Two questions related to running XForms 1.1testsuiteautomaticly (xf:message, How do you know when an AJAX call has returned)
|
|
Cool thanks!
-Erik On Fri, Feb 12, 2010 at 11:46 PM, nvdbleek <[hidden email]> wrote: > Erik, > > Thank you for the quick response, I added message-dialog.xml ( > http://github.com/nvdbleek/orbeon-forms/commit/5ca143fcf5d636ae968ed766265fa688e967948c > ). I hope the next commit will be correct right away... > > Regards, > > Nick > > On Sat, Feb 13, 2010 at 03:00, Erik Bruchez-3 [via Orbeon Forms > (ops-users)] <[hidden email]> wrote: >> Nick, >> >> Excellent! We will review this. BTW I think you might have forgotten >> to commit message-dialog.xml. Can you add it? >> >> -Erik >> >> On Fri, Feb 12, 2010 at 11:48 AM, nvdbleek <[hidden email]> wrote: >>> Hi Erik, >>> >>> I implemented xf:message using a YUI Panel. Could you have a look at >>> it ( >>> >>> >>> http://github.com/nvdbleek/orbeon-forms/commit/4e88fd8d73da014b3758ef972135f4e81fb3002c >>> ), any comments for improvements are welcome. And if it is good enough >>> to be merged to the Orbeon please tree go ahead ;) >>> >>> I tested it with message sandbox sample, and a form that sends >>> multiple messages. >>> >>> Regards, >>> >>> Nick >>> >>> On Fri, Feb 5, 2010 at 02:10, Erik Bruchez-3 [via Orbeon Forms >>> (ops-users)] <[hidden email]> wrote: >>>> Nick, >>>> >>>> (It seems my GTD system doesn't work very well.) >>>> >>>> 1. We think it would be great to use a lightweight dialog for >>>> xf:message. >>>> >>>> As far as the order is concerned: I don't think we need to worry too >>>> much about this, because anyway the server doesn't keep message, load, >>>> and scripts in the proper order. So we can worry about that later I >>>> think. >>>> >>>> We should probably keep the old native alert code and switch between >>>> native/lightweight with a property. >>>> >>>> 2. There is a JS ORBEON.util.Test.executeCausingAjaxRequest() used for >>>> tests. You should be able to use that. See for example in >>>> currency-unittest.js. >>>> >>>> -Erik >>>> >>>> On Sat, Jan 23, 2010 at 9:59 AM, Nick Van den Bleeken <[hidden email]> >>>> wrote: >>>>> Erik, Alessandro, >>>>> >>>>> While working on a test harness for the XForms 1.1 test suite >>>>> (http://github.com/nvdbleek/com.orbeon.testsuite.w3c ) I hit the >>>>> following two problems which I'm a bit stuck on. >>>>> >>>>> 1. xf:message uses javascript alert() >>>>> >>>>> The XForms 1.1 uses an xf:message in a lot of tests to display a >>>>> message to the user. In orbeon the message is shown to the user using >>>>> the javascript alert function. The alert box blocks all javascript >>>>> execution (javascript is single threaded if you don't use workers). >>>>> And therefore selenium can't test for alert boxes when they are shown >>>>> before selenium can execute the code to replace the alert method (they >>>>> replace it with a function so they can check if there was an alert and >>>>> what the message was, but for all messages shown before xforms-ready >>>>> finishes this fails, and this feature is heavily used by the tests). >>>>> >>>>> To work around this issue I wanted to replace the code that handles >>>>> the xf:message in xforms.js with >>>>> >>>>> if (ORBEON.util.Dom.getAttribute(messageElement, "level") == "modal") { >>>>> if (ORBEON.xforms.Globals.alertDialog == null) { >>>>> YUI alert dialog used by alert action >>>>> ORBEON.xforms.Globals.alertDialog = new >>>>> YAHOO.widget.SimpleDialog("alert_dlg1", { >>>>> width : "200px", >>>>> effect : { >>>>> effect : >>>>> YAHOO.widget.ContainerEffect.FADE, >>>>> duration : 0.15 >>>>> }, >>>>> fixedcenter : true, >>>>> modal : true, >>>>> visible : false, >>>>> close : true, >>>>> constraintoviewport : true, >>>>> buttons : [ { >>>>> text : "close", >>>>> handler : function() { >>>>> this.hide(); >>>>> }, >>>>> isDefault : true >>>>> } ], >>>>> draggable : false, >>>>> effect : [ { >>>>> effect : >>>>> YAHOO.widget.ContainerEffect.FADE, >>>>> duration : 0.1 >>>>> } ] >>>>> }); >>>>> >>>>> ORBEON.xforms.Globals.alertDialog.form = >>>>> ORBEON.xforms.Globals.requestForm; >>>>> ORBEON.xforms.Globals.alertDialog.setHeader("Alert"); >>>>> ORBEON.xforms.Globals.alertDialog.render(document.body); >>>>> } >>>>> >>>>> ORBEON.xforms.Globals.alertDialog.cfg.setProperty("text",message); >>>>> ORBEON.xforms.Globals.alertDialog.show(); >>>>> } >>>>> >>>>> But this messes up the form object. I saw that Orbeon patched the >>>>> dialog for a similar reason I guess... >>>>> >>>>> What is you're opinion in changing the xf:message to a YUI dialog? It >>>>> will also introduce a behavior change if implemented like this. Namely >>>>> when you use alert and have actions (possibly other xf:message >>>>> actions) after the xf:message those will be handled (likely) before >>>>> the user confirms the message. If you make the action list global and >>>>> handle the next action when the dialog is confirmed, you can still >>>>> have the old behavior. But this requires quite some changes (and the >>>>> handleResponseDom method should also check if there is currently no >>>>> message shown when it is first called, if so it should add his actions >>>>> to the global action list). What do you think of this? >>>>> >>>>> Another approach is to leave alone the current implementation, and >>>>> only change the xf:message handler when it is running tests. It could >>>>> just append the message to a global list of non-confirmed messages, >>>>> and the test can remove the item when it expects a message (and check >>>>> at the end if the list is empty -> if no messages should be shown in >>>>> the test it should assert this). This has the main advantage that the >>>>> change is simple and only affects the current code when we are testing >>>>> (we could do this by a special attribute on the xf:message element or >>>>> a configuration option). The main disadvantage is that you aren't >>>>> testing the code that the user will use when he is running the form in >>>>> real-life mode. >>>>> >>>>> I'm interested in what your opinion is about this 'issue' and how I or >>>>> we can solve my problem. >>>>> >>>>> >>>>> >>>>> 2. How do you know when an AJAX call has returned (selection option, >>>>> typing text,...) >>>>> >>>>> I found 'ORBEON.xforms.Globals.requestInProgress || >>>>> ORBEON.xforms.Globals.eventQueue.length > 0' but in some cases the >>>>> boolean isn't true yet and the event isn't yet in eventQueue. Is there >>>>> a reliable way to know if all the updates for the operation (typing >>>>> text, selectin an option) is done? >>>>> -- >>>>> Regards, >>>>> >>>>> Nick Van den Bleeken >>>>> >>>>> >>>>> -- >>>>> You receive this message as a subscriber of the [hidden email] mailing >>>>> list. >>>>> To unsubscribe: mailto:[hidden email] >>>>> For general help: mailto:[hidden email]?subject=help >>>>> OW2 mailing lists service home page: http://www.ow2.org/wws >>>>> >>>>> >>>> >>>> -- >>>> You receive this message as a subscriber of the [hidden email] mailing >>>> list. >>>> To unsubscribe: mailto:[hidden email] >>>> For general help: mailto:[hidden email]?subject=help >>>> OW2 mailing lists service home page: http://www.ow2.org/wws >>>> >>>> >>>> ________________________________ >>>> View message @ >>>> >>>> >>>> >>>> http://n4.nabble.com/Two-questions-related-to-running-XForms-1-1-test-suite-automaticly-xf-message-How-do-you-know-when-a-tp1288325p1469658.html >>>> To start a new topic under ObjectWeb OPS - Users, email >>>> [hidden email] >>>> To unsubscribe from ObjectWeb OPS - Users, click here. >>>> >>> >>> >>> -- >>> Regards, >>> >>> Nick Van den Bleeken >>> >>> ________________________________ >>> View this message in context: Re: Two questions related to running XForms >>> 1.1 test suite automaticly (xf:message, How do you know when an AJAX call >>> has returned) >>> Sent from the ObjectWeb OPS - Users mailing list archive at Nabble.com. >>> >>> >>> -- >>> You receive this message as a subscriber of the [hidden email] mailing >>> list. >>> To unsubscribe: mailto:[hidden email] >>> For general help: mailto:[hidden email]?subject=help >>> OW2 mailing lists service home page: http://www.ow2.org/wws >>> >>> >> >> -- >> You receive this message as a subscriber of the [hidden email] mailing >> list. >> To unsubscribe: mailto:[hidden email] >> For general help: mailto:[hidden email]?subject=help >> OW2 mailing lists service home page: http://www.ow2.org/wws >> >> >> ________________________________ >> View message @ >> >> http://n4.nabble.com/Two-questions-related-to-running-XForms-1-1-test-suite-automaticly-xf-message-How-do-you-know-when-a-tp1288325p1497907.html >> To start a new topic under ObjectWeb OPS - Users, email >> [hidden email] >> To unsubscribe from ObjectWeb OPS - Users, click here. >> > > > -- > Regards, > > Nick Van den Bleeken > > ________________________________ > View this message in context: Re: Re: Two questions related to running > XForms 1.1 testsuiteautomaticly (xf:message, How do you know when an AJAX > call has returned) > Sent from the ObjectWeb OPS - Users mailing list archive at Nabble.com. > > > -- > You receive this message as a subscriber of the [hidden email] mailing > list. > To unsubscribe: mailto:[hidden email] > For general help: mailto:[hidden email]?subject=help > OW2 mailing lists service home page: http://www.ow2.org/wws > > -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help OW2 mailing lists service home page: http://www.ow2.org/wws |
Re: Two questions related to running XForms 1.1 test suite automaticly (xf:message, How do you know when an AJAX call has returned)
Administrator
|
In reply to this post by nvdbleek
Hi Nick,
Sorry for the delay integrating this! We have a couple of options to implement a dialog at the HTML level: A1. Use a SimpleDialog, as you did in your initial submission. A2. Use a "regular" dialog created based on markup present in the page, which can be customized by overriding an XML originally in the jar. Then there is the question of giving developers the option of keeping the current behavior: B1. We have a property to choose if the xforms:message uses alert() or an HTML dialog. B2. We don't have such a property; the HTML dialog is always used. I went with A1/B1, as in my experience the xforms:message is used mostly for debugging, and so folk don't care that much about how it is displayed. If they need something nicer, they can use the alert dialog XBL component (http://wiki.orbeon.com/forms/doc/developer-guide/xbl-components#TOC-Alert-dialog), and if they want something custom, they can easily create their own XBL component for this. The only downside I can think of, is that this will prevent one from showing a debug message just before running an xforms:submission replace="all". It turns out we don't allow this ("by mistake"), so nobody is using this feature presently, hence this shouldn't be a problem. Anyway, for debugging, it is better to use level="xxforms:log-debug" an look at the logs. This change is now in. Again, my apologies for the delay, and you'll let us know how this works for you. Alex On Sat, Jan 23, 2010 at 10:59 AM, Nick Van den Bleeken <[hidden email]> wrote: > Erik, Alessandro, > > While working on a test harness for the XForms 1.1 test suite > (http://github.com/nvdbleek/com.orbeon.testsuite.w3c ) I hit the > following two problems which I'm a bit stuck on. > > 1. xf:message uses javascript alert() > > The XForms 1.1 uses an xf:message in a lot of tests to display a > message to the user. In orbeon the message is shown to the user using > the javascript alert function. The alert box blocks all javascript > execution (javascript is single threaded if you don't use workers). > And therefore selenium can't test for alert boxes when they are shown > before selenium can execute the code to replace the alert method (they > replace it with a function so they can check if there was an alert and > what the message was, but for all messages shown before xforms-ready > finishes this fails, and this feature is heavily used by the tests). > > To work around this issue I wanted to replace the code that handles > the xf:message in xforms.js with > > if (ORBEON.util.Dom.getAttribute(messageElement, "level") == "modal") { > if (ORBEON.xforms.Globals.alertDialog == null) { > YUI alert dialog used by alert action > ORBEON.xforms.Globals.alertDialog = new > YAHOO.widget.SimpleDialog("alert_dlg1", { > width : "200px", > effect : { > effect : YAHOO.widget.ContainerEffect.FADE, > duration : 0.15 > }, > fixedcenter : true, > modal : true, > visible : false, > close : true, > constraintoviewport : true, > buttons : [ { > text : "close", > handler : function() { > this.hide(); > }, > isDefault : true > } ], > draggable : false, > effect : [ { > effect : YAHOO.widget.ContainerEffect.FADE, > duration : 0.1 > } ] > }); > > ORBEON.xforms.Globals.alertDialog.form = ORBEON.xforms.Globals.requestForm; > ORBEON.xforms.Globals.alertDialog.setHeader("Alert"); > ORBEON.xforms.Globals.alertDialog.render(document.body); > } > ORBEON.xforms.Globals.alertDialog.cfg.setProperty("text",message); > ORBEON.xforms.Globals.alertDialog.show(); > } > > But this messes up the form object. I saw that Orbeon patched the > dialog for a similar reason I guess... > > What is you're opinion in changing the xf:message to a YUI dialog? It > will also introduce a behavior change if implemented like this. Namely > when you use alert and have actions (possibly other xf:message > actions) after the xf:message those will be handled (likely) before > the user confirms the message. If you make the action list global and > handle the next action when the dialog is confirmed, you can still > have the old behavior. But this requires quite some changes (and the > handleResponseDom method should also check if there is currently no > message shown when it is first called, if so it should add his actions > to the global action list). What do you think of this? > > Another approach is to leave alone the current implementation, and > only change the xf:message handler when it is running tests. It could > just append the message to a global list of non-confirmed messages, > and the test can remove the item when it expects a message (and check > at the end if the list is empty -> if no messages should be shown in > the test it should assert this). This has the main advantage that the > change is simple and only affects the current code when we are testing > (we could do this by a special attribute on the xf:message element or > a configuration option). The main disadvantage is that you aren't > testing the code that the user will use when he is running the form in > real-life mode. > > I'm interested in what your opinion is about this 'issue' and how I or > we can solve my problem. > > > > 2. How do you know when an AJAX call has returned (selection option, > typing text,...) > > I found 'ORBEON.xforms.Globals.requestInProgress || > ORBEON.xforms.Globals.eventQueue.length > 0' but in some cases the > boolean isn't true yet and the event isn't yet in eventQueue. Is there > a reliable way to know if all the updates for the operation (typing > text, selectin an option) is done? > -- > Regards, > > Nick Van den Bleeken > > > -- > You receive this message as a subscriber of the [hidden email] mailing list. > To unsubscribe: mailto:[hidden email] > For general help: mailto:[hidden email]?subject=help > OW2 mailing lists service home page: http://www.ow2.org/wws > > -- Orbeon Forms - Web forms, open-source, for the Enterprise - http://www.orbeon.com/ My Twitter: http://twitter.com/avernet -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help OW2 mailing lists service home page: http://www.ow2.org/wws
--
Follow Orbeon on Twitter: @orbeon Follow me on Twitter: @avernet |
|
|
Hi Alex,
I didn't sport this e-mail before sending the other one (sorry for this). It is great work you did, the only big difference I see is that when sending multiple messages they are shown simultaneous (didn't try it yet, but just looked to the code). And so you don't know the order of the messages. In the patch I had an array with all messages that should be shown, this is really handy when writing the unit tests for the XForms WG test suite. Did you have a specific reason to drop the the array to manage the messages? Regards, On Thu, Mar 18, 2010 at 23:42, Alessandro Vernet [via Orbeon Forms (ops-users)] <[hidden email]> wrote: Hi Nick, -- Regards, Nick Van den Bleeken |
Re: Re: Two questions related to running XForms 1.1 testsuiteautomaticly (xf:message, How do you know when an AJAX call has returned)
|
Administrator
|
Hi Nick,
My bad. I based this on your first submission using a SimpleDialog, and didn't think about the case where you have multiple xforms:message in one Ajax response, which you handled in your second submission. I push a change for this so the messages are queued, like you did. You'll let me know how this works for you. Alex On Fri, Mar 19, 2010 at 6:48 AM, nvdbleek <[hidden email]> wrote: > Hi Alex, > > I didn't sport this e-mail before sending the other one (sorry for this). It > is great work you did, the only big difference I see is that when sending > multiple messages they are shown simultaneous (didn't try it yet, but just > looked to the code). And so you don't know the order of the messages. In the > patch I had an array with all messages that should be shown, this is really > handy when writing the unit tests for the XForms WG test suite. > > Did you have a specific reason to drop the the array to manage the messages? > > Regards, > > On Thu, Mar 18, 2010 at 23:42, Alessandro Vernet [via Orbeon Forms > (ops-users)] <[hidden email]> wrote: >> >> Hi Nick, >> >> Sorry for the delay integrating this! We have a couple of options to >> implement a dialog at the HTML level: >> >> A1. Use a SimpleDialog, as you did in your initial submission. >> A2. Use a "regular" dialog created based on markup present in the >> page, which can be customized by overriding an XML originally in the >> jar. >> >> Then there is the question of giving developers the option of keeping >> the current behavior: >> >> B1. We have a property to choose if the xforms:message uses alert() or >> an HTML dialog. >> B2. We don't have such a property; the HTML dialog is always used. >> >> I went with A1/B1, as in my experience the xforms:message is used >> mostly for debugging, and so folk don't care that much about how it is >> displayed. If they need something nicer, they can use the alert dialog >> XBL component >> (http://wiki.orbeon.com/forms/doc/developer-guide/xbl-components#TOC-Alert-dialog), >> and if they want something custom, they can easily create their own >> XBL component for this. >> >> The only downside I can think of, is that this will prevent one from >> showing a debug message just before running an xforms:submission >> replace="all". It turns out we don't allow this ("by mistake"), so >> nobody is using this feature presently, hence this shouldn't be a >> problem. Anyway, for debugging, it is better to use >> level="xxforms:log-debug" an look at the logs. >> >> This change is now in. Again, my apologies for the delay, and you'll >> let us know how this works for you. >> >> Alex >> >> On Sat, Jan 23, 2010 at 10:59 AM, Nick Van den Bleeken <[hidden email]> >> wrote: >> > Erik, Alessandro, >> > >> > While working on a test harness for the XForms 1.1 test suite >> > (http://github.com/nvdbleek/com.orbeon.testsuite.w3c ) I hit the >> > following two problems which I'm a bit stuck on. >> > >> > 1. xf:message uses javascript alert() >> > >> > The XForms 1.1 uses an xf:message in a lot of tests to display a >> > message to the user. In orbeon the message is shown to the user using >> > the javascript alert function. The alert box blocks all javascript >> > execution (javascript is single threaded if you don't use workers). >> > And therefore selenium can't test for alert boxes when they are shown >> > before selenium can execute the code to replace the alert method (they >> > replace it with a function so they can check if there was an alert and >> > what the message was, but for all messages shown before xforms-ready >> > finishes this fails, and this feature is heavily used by the tests). >> > >> > To work around this issue I wanted to replace the code that handles >> > the xf:message in xforms.js with >> > >> > if (ORBEON.util.Dom.getAttribute(messageElement, "level") == "modal") { >> > if (ORBEON.xforms.Globals.alertDialog == null) { >> > YUI alert dialog used by alert action >> > ORBEON.xforms.Globals.alertDialog = new >> > YAHOO.widget.SimpleDialog("alert_dlg1", { >> > width : "200px", >> > effect : { >> > effect : >> > YAHOO.widget.ContainerEffect.FADE, >> > duration : 0.15 >> > }, >> > fixedcenter : true, >> > modal : true, >> > visible : false, >> > close : true, >> > constraintoviewport : true, >> > buttons : [ { >> > text : "close", >> > handler : function() { >> > this.hide(); >> > }, >> > isDefault : true >> > } ], >> > draggable : false, >> > effect : [ { >> > effect : >> > YAHOO.widget.ContainerEffect.FADE, >> > duration : 0.1 >> > } ] >> > }); >> > >> > ORBEON.xforms.Globals.alertDialog.form = >> > ORBEON.xforms.Globals.requestForm; >> > ORBEON.xforms.Globals.alertDialog.setHeader("Alert"); >> > ORBEON.xforms.Globals.alertDialog.render(document.body); >> > } >> > >> > ORBEON.xforms.Globals.alertDialog.cfg.setProperty("text",message); >> > ORBEON.xforms.Globals.alertDialog.show(); >> > } >> > >> > But this messes up the form object. I saw that Orbeon patched the >> > dialog for a similar reason I guess... >> > >> > What is you're opinion in changing the xf:message to a YUI dialog? It >> > will also introduce a behavior change if implemented like this. Namely >> > when you use alert and have actions (possibly other xf:message >> > actions) after the xf:message those will be handled (likely) before >> > the user confirms the message. If you make the action list global and >> > handle the next action when the dialog is confirmed, you can still >> > have the old behavior. But this requires quite some changes (and the >> > handleResponseDom method should also check if there is currently no >> > message shown when it is first called, if so it should add his actions >> > to the global action list). What do you think of this? >> > >> > Another approach is to leave alone the current implementation, and >> > only change the xf:message handler when it is running tests. It could >> > just append the message to a global list of non-confirmed messages, >> > and the test can remove the item when it expects a message (and check >> > at the end if the list is empty -> if no messages should be shown in >> > the test it should assert this). This has the main advantage that the >> > change is simple and only affects the current code when we are testing >> > (we could do this by a special attribute on the xf:message element or >> > a configuration option). The main disadvantage is that you aren't >> > testing the code that the user will use when he is running the form in >> > real-life mode. >> > >> > I'm interested in what your opinion is about this 'issue' and how I or >> > we can solve my problem. >> > >> > >> > >> > 2. How do you know when an AJAX call has returned (selection option, >> > typing text,...) >> > >> > I found 'ORBEON.xforms.Globals.requestInProgress || >> > ORBEON.xforms.Globals.eventQueue.length > 0' but in some cases the >> > boolean isn't true yet and the event isn't yet in eventQueue. Is there >> > a reliable way to know if all the updates for the operation (typing >> > text, selectin an option) is done? >> > -- >> > Regards, >> > >> > Nick Van den Bleeken >> > >> > >> > -- >> > You receive this message as a subscriber of the [hidden email] mailing >> > list. >> > To unsubscribe: mailto:[hidden email] >> > For general help: mailto:[hidden email]?subject=help >> > OW2 mailing lists service home page: http://www.ow2.org/wws >> > >> > >> >> -- >> Orbeon Forms - Web forms, open-source, for the Enterprise - >> http://www.orbeon.com/ >> My Twitter: http://twitter.com/avernet >> >> >> -- >> You receive this message as a subscriber of the [hidden email] mailing >> list. >> To unsubscribe: mailto:[hidden email] >> For general help: mailto:[hidden email]?subject=help >> OW2 mailing lists service home page: http://www.ow2.org/wws > > > > -- > Regards, > > Nick Van den Bleeken > > ________________________________ > View this message in context: Re: Two questions related to running XForms > 1.1 test suite automaticly (xf:message, How do you know when an AJAX call > has returned) > Sent from the Orbeon Forms (ops-users) mailing list archive at Nabble.com. > > > -- > You receive this message as a subscriber of the [hidden email] mailing > list. > To unsubscribe: mailto:[hidden email] > For general help: mailto:[hidden email]?subject=help > OW2 mailing lists service home page: http://www.ow2.org/wws > > -- Orbeon Forms - Web forms, open-source, for the Enterprise - http://www.orbeon.com/ My Twitter: http://twitter.com/avernet -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help OW2 mailing lists service home page: http://www.ow2.org/wws
--
Follow Orbeon on Twitter: @orbeon Follow me on Twitter: @avernet |
|
|
Alex,
Thank you in advance for merging in my fix for supporting multiple xforms:message in one Ajax response (the array can also be used by automated unit tests, that's why I shift the array after closing the message). If you need more info on the patch please let me know (but I think you can figure it out yourself quite easy, because its quite straightforward). Regards, Nick On Fri, Mar 19, 2010 at 19:36, Alessandro Vernet [via Orbeon Forms (ops-users)] <[hidden email]> wrote: Hi Nick, -- Regards, Nick Van den Bleeken |
|
|
In reply to this post by Alessandro Vernet
Hi Alex,
Just hit a small problem with the patch I did (and it is also in yours) if a message action is executed before xforms-ready (in xforms-model-construct in my case) the normal code path for displaying the message isn't used. The message is then shown in xformsPageLoadedServer() which is generated by XHTMLHeadHandler. See http://github.com/nvdbleek/orbeon-forms/commit/909b62431c06a3ecedc20690047fabd7590a951b for my commit that solves the problem for my version of the YUI message. Sorry for the inconvenience, but you can fix it when you fix the multiple messages problem ;) Regards, Nick Van den Bleeken On Fri, Mar 19, 2010 at 19:36, Alessandro Vernet [via Orbeon Forms (ops-users)] <[hidden email]> wrote: Hi Nick, -- Regards, Nick Van den Bleeken |
Re: Re: Re: Two questions related to running XForms 1.1testsuiteautomaticly (xf:message, How do you know when an AJAX call has returned)
|
Administrator
|
Hi Nick,
Good point! I put in the support for the xforms:messages that happen before the HTML is sent to the client. This will be in the next nightly build, so you'll let me know if this all works for you. Alex On Sun, Mar 21, 2010 at 10:02 AM, nvdbleek <[hidden email]> wrote: > Hi Alex, > > Just hit a small problem with the patch I did (and it is also in yours) if a > message action is executed before xforms-ready (in xforms-model-construct in > my case) the normal code path for displaying the message isn't used. The > message is then shown in xformsPageLoadedServer() which is generated by > XHTMLHeadHandler. See > http://github.com/nvdbleek/orbeon-forms/commit/909b62431c06a3ecedc20690047fabd7590a951b > for my commit that solves the problem for my version of the YUI message. > > Sorry for the inconvenience, but you can fix it when you fix the multiple > messages problem ;) > > Regards, > > Nick Van den Bleeken > > On Fri, Mar 19, 2010 at 19:36, Alessandro Vernet [via Orbeon Forms > (ops-users)] <[hidden email]> wrote: >> >> Hi Nick, >> >> My bad. I based this on your first submission using a SimpleDialog, >> and didn't think about the case where you have multiple xforms:message >> in one Ajax response, which you handled in your second submission. I >> push a change for this so the messages are queued, like you did. >> You'll let me know how this works for you. >> >> Alex >> >> On Fri, Mar 19, 2010 at 6:48 AM, nvdbleek <[hidden email]> wrote: >> > Hi Alex, >> > >> > I didn't sport this e-mail before sending the other one (sorry for >> > this). It >> > is great work you did, the only big difference I see is that when >> > sending >> > multiple messages they are shown simultaneous (didn't try it yet, but >> > just >> > looked to the code). And so you don't know the order of the messages. In >> > the >> > patch I had an array with all messages that should be shown, this is >> > really >> > handy when writing the unit tests for the XForms WG test suite. >> > >> > Did you have a specific reason to drop the the array to manage the >> > messages? >> > >> > Regards, >> > >> > On Thu, Mar 18, 2010 at 23:42, Alessandro Vernet [via Orbeon Forms >> > (ops-users)] <[hidden email]> wrote: >> >> >> >> Hi Nick, >> >> >> >> Sorry for the delay integrating this! We have a couple of options to >> >> implement a dialog at the HTML level: >> >> >> >> A1. Use a SimpleDialog, as you did in your initial submission. >> >> A2. Use a "regular" dialog created based on markup present in the >> >> page, which can be customized by overriding an XML originally in the >> >> jar. >> >> >> >> Then there is the question of giving developers the option of keeping >> >> the current behavior: >> >> >> >> B1. We have a property to choose if the xforms:message uses alert() or >> >> an HTML dialog. >> >> B2. We don't have such a property; the HTML dialog is always used. >> >> >> >> I went with A1/B1, as in my experience the xforms:message is used >> >> mostly for debugging, and so folk don't care that much about how it is >> >> displayed. If they need something nicer, they can use the alert dialog >> >> XBL component >> >> >> >> (http://wiki.orbeon.com/forms/doc/developer-guide/xbl-components#TOC-Alert-dialog), >> >> and if they want something custom, they can easily create their own >> >> XBL component for this. >> >> >> >> The only downside I can think of, is that this will prevent one from >> >> showing a debug message just before running an xforms:submission >> >> replace="all". It turns out we don't allow this ("by mistake"), so >> >> nobody is using this feature presently, hence this shouldn't be a >> >> problem. Anyway, for debugging, it is better to use >> >> level="xxforms:log-debug" an look at the logs. >> >> >> >> This change is now in. Again, my apologies for the delay, and you'll >> >> let us know how this works for you. >> >> >> >> Alex >> >> >> >> On Sat, Jan 23, 2010 at 10:59 AM, Nick Van den Bleeken <[hidden email]> >> >> wrote: >> >> > Erik, Alessandro, >> >> > >> >> > While working on a test harness for the XForms 1.1 test suite >> >> > (http://github.com/nvdbleek/com.orbeon.testsuite.w3c ) I hit the >> >> > following two problems which I'm a bit stuck on. >> >> > >> >> > 1. xf:message uses javascript alert() >> >> > >> >> > The XForms 1.1 uses an xf:message in a lot of tests to display a >> >> > message to the user. In orbeon the message is shown to the user using >> >> > the javascript alert function. The alert box blocks all javascript >> >> > execution (javascript is single threaded if you don't use workers). >> >> > And therefore selenium can't test for alert boxes when they are shown >> >> > before selenium can execute the code to replace the alert method >> >> > (they >> >> > replace it with a function so they can check if there was an alert >> >> > and >> >> > what the message was, but for all messages shown before xforms-ready >> >> > finishes this fails, and this feature is heavily used by the tests). >> >> > >> >> > To work around this issue I wanted to replace the code that handles >> >> > the xf:message in xforms.js with >> >> > >> >> > if (ORBEON.util.Dom.getAttribute(messageElement, "level") == "modal") >> >> > { >> >> > if (ORBEON.xforms.Globals.alertDialog == null) { >> >> > YUI alert dialog used by alert action >> >> > ORBEON.xforms.Globals.alertDialog = new >> >> > YAHOO.widget.SimpleDialog("alert_dlg1", { >> >> > width : "200px", >> >> > effect : { >> >> > effect : >> >> > YAHOO.widget.ContainerEffect.FADE, >> >> > duration : 0.15 >> >> > }, >> >> > fixedcenter : true, >> >> > modal : true, >> >> > visible : false, >> >> > close : true, >> >> > constraintoviewport : true, >> >> > buttons : [ { >> >> > text : "close", >> >> > handler : function() { >> >> > this.hide(); >> >> > }, >> >> > isDefault : true >> >> > } ], >> >> > draggable : false, >> >> > effect : [ { >> >> > effect : >> >> > YAHOO.widget.ContainerEffect.FADE, >> >> > duration : 0.1 >> >> > } ] >> >> > }); >> >> > >> >> > ORBEON.xforms.Globals.alertDialog.form = >> >> > ORBEON.xforms.Globals.requestForm; >> >> > ORBEON.xforms.Globals.alertDialog.setHeader("Alert"); >> >> > >> >> > ORBEON.xforms.Globals.alertDialog.render(document.body); >> >> > } >> >> > >> >> > ORBEON.xforms.Globals.alertDialog.cfg.setProperty("text",message); >> >> > ORBEON.xforms.Globals.alertDialog.show(); >> >> > } >> >> > >> >> > But this messes up the form object. I saw that Orbeon patched the >> >> > dialog for a similar reason I guess... >> >> > >> >> > What is you're opinion in changing the xf:message to a YUI dialog? It >> >> > will also introduce a behavior change if implemented like this. >> >> > Namely >> >> > when you use alert and have actions (possibly other xf:message >> >> > actions) after the xf:message those will be handled (likely) before >> >> > the user confirms the message. If you make the action list global and >> >> > handle the next action when the dialog is confirmed, you can still >> >> > have the old behavior. But this requires quite some changes (and the >> >> > handleResponseDom method should also check if there is currently no >> >> > message shown when it is first called, if so it should add his >> >> > actions >> >> > to the global action list). What do you think of this? >> >> > >> >> > Another approach is to leave alone the current implementation, and >> >> > only change the xf:message handler when it is running tests. It could >> >> > just append the message to a global list of non-confirmed messages, >> >> > and the test can remove the item when it expects a message (and check >> >> > at the end if the list is empty -> if no messages should be shown in >> >> > the test it should assert this). This has the main advantage that the >> >> > change is simple and only affects the current code when we are >> >> > testing >> >> > (we could do this by a special attribute on the xf:message element or >> >> > a configuration option). The main disadvantage is that you aren't >> >> > testing the code that the user will use when he is running the form >> >> > in >> >> > real-life mode. >> >> > >> >> > I'm interested in what your opinion is about this 'issue' and how I >> >> > or >> >> > we can solve my problem. >> >> > >> >> > >> >> > >> >> > 2. How do you know when an AJAX call has returned (selection option, >> >> > typing text,...) >> >> > >> >> > I found 'ORBEON.xforms.Globals.requestInProgress || >> >> > ORBEON.xforms.Globals.eventQueue.length > 0' but in some cases the >> >> > boolean isn't true yet and the event isn't yet in eventQueue. Is >> >> > there >> >> > a reliable way to know if all the updates for the operation (typing >> >> > text, selectin an option) is done? >> >> > -- >> >> > Regards, >> >> > >> >> > Nick Van den Bleeken >> >> > >> >> > >> >> > -- >> >> > You receive this message as a subscriber of the [hidden email] >> >> > mailing >> >> > list. >> >> > To unsubscribe: mailto:[hidden email] >> >> > For general help: mailto:[hidden email]?subject=help >> >> > OW2 mailing lists service home page: http://www.ow2.org/wws >> >> > >> >> > >> >> >> >> -- >> >> Orbeon Forms - Web forms, open-source, for the Enterprise - >> >> http://www.orbeon.com/ >> >> My Twitter: http://twitter.com/avernet >> >> >> >> >> >> -- >> >> You receive this message as a subscriber of the [hidden email] mailing >> >> list. >> >> To unsubscribe: mailto:[hidden email] >> >> For general help: mailto:[hidden email]?subject=help >> >> OW2 mailing lists service home page: http://www.ow2.org/wws >> > >> > >> > >> > -- >> > Regards, >> > >> > Nick Van den Bleeken >> > >> > ________________________________ >> > View this message in context: Re: Two questions related to running >> > XForms >> > 1.1 test suite automaticly (xf:message, How do you know when an AJAX >> > call >> > has returned) >> > Sent from the Orbeon Forms (ops-users) mailing list archive at >> > Nabble.com. >> > >> > >> > -- >> > You receive this message as a subscriber of the [hidden email] mailing >> > list. >> > To unsubscribe: mailto:[hidden email] >> > For general help: mailto:[hidden email]?subject=help >> > OW2 mailing lists service home page: http://www.ow2.org/wws >> > >> > >> >> -- >> Orbeon Forms - Web forms, open-source, for the Enterprise - >> http://www.orbeon.com/ >> My Twitter: http://twitter.com/avernet >> >> >> -- >> You receive this message as a subscriber of the [hidden email] mailing >> list. >> To unsubscribe: mailto:[hidden email] >> For general help: mailto:[hidden email]?subject=help >> OW2 mailing lists service home page: http://www.ow2.org/wws > > > > -- > Regards, > > Nick Van den Bleeken > > ________________________________ > View this message in context: Re: Re: Two questions related to running > XForms 1.1 testsuiteautomaticly (xf:message, How do you know when an AJAX > call has returned) > Sent from the Orbeon Forms (ops-users) mailing list archive at Nabble.com. > > > -- > You receive this message as a subscriber of the [hidden email] mailing > list. > To unsubscribe: mailto:[hidden email] > For general help: mailto:[hidden email]?subject=help > OW2 mailing lists service home page: http://www.ow2.org/wws > > -- Orbeon Forms - Web forms, open-source, for the Enterprise - http://www.orbeon.com/ My Twitter: http://twitter.com/avernet -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help OW2 mailing lists service home page: http://www.ow2.org/wws
--
Follow Orbeon on Twitter: @orbeon Follow me on Twitter: @avernet |
|
|
Hi Alex,
Looks good, I'll merge it in after the FtF meeting. It will require some changes in my unit test code because I access the messageQueue directly and not the text in the dialog (didn't want to rely on the 'presentation' of the message, otherwise when somebody decided to show extra stuff in the message dialog, the tests will break, but that is probably to theoretical). By the way, the XForms test suite work is progressing well (did 328 of the 458 tests). Again thank you for 'merging' it in (sorry for all the rewrite work you had to do). Regards, Nick On Tue, Mar 23, 2010 at 00:45, Alessandro Vernet [via Orbeon Forms (ops-users)] <[hidden email]> wrote: Hi Nick, -- Regards, Nick Van den Bleeken |
Re: Re: Re: Re: Two questions related to running XForms1.1testsuiteautomaticly (xf:message, How do you know when an AJAX call has returned)
|
Administrator
|
Nick,
You are saying that you want to access the message that is being displayed programmatically without looking for it in the DOM? That might be harder the way I put the code in, as I haven't used a global message queue, but kept instead a message queue local to the handleResponseDom() function (see code in the: case "message":). Is that a problem for the unit tests? Also, related to the xforms:message, I was discussing with a client this morning who happens to use thexforms:message to show a message to end users before going to another page. So the new implementation won't work for this, and don't think we can get away without also providing a blocking implementation of xforms:message. We can either: 1. Have a property to choose if you want to use the new non-blocking HTML message dialog or the browser's blocking alert(). 2. Refactor the code in handleResponseDom() to make the HTML message dialog blocking. Obviously 2 is more complicated, but I am tempted to go that route as it would allow us to clean up that code while at it putting in practice some good old object oriented paradigms ;). Alex On Tue, Mar 23, 2010 at 1:41 AM, nvdbleek <[hidden email]> wrote: > Hi Alex, > > Looks good, I'll merge it in after the FtF meeting. It will require some > changes in my unit test code because I access the messageQueue directly and > not the text in the dialog (didn't want to rely on the 'presentation' of the > message, otherwise when somebody decided to show extra stuff in the message > dialog, the tests will break, but that is probably to theoretical). By the > way, the XForms test suite work is progressing well (did 328 of the 458 > tests). > > Again thank you for 'merging' it in (sorry for all the rewrite work you had > to do). > > Regards, > > Nick > > On Tue, Mar 23, 2010 at 00:45, Alessandro Vernet [via Orbeon Forms > (ops-users)] <[hidden email]> wrote: >> >> Hi Nick, >> >> Good point! I put in the support for the xforms:messages that happen >> before the HTML is sent to the client. This will be in the next >> nightly build, so you'll let me know if this all works for you. >> >> Alex >> >> On Sun, Mar 21, 2010 at 10:02 AM, nvdbleek <[hidden email]> wrote: >> > Hi Alex, >> > >> > Just hit a small problem with the patch I did (and it is also in yours) >> > if a >> > message action is executed before xforms-ready (in >> > xforms-model-construct in >> > my case) the normal code path for displaying the message isn't used. The >> > message is then shown in xformsPageLoadedServer() which is generated by >> > XHTMLHeadHandler. See >> > >> > http://github.com/nvdbleek/orbeon-forms/commit/909b62431c06a3ecedc20690047fabd7590a951b >> > for my commit that solves the problem for my version of the YUI message. >> > >> > Sorry for the inconvenience, but you can fix it when you fix the >> > multiple >> > messages problem ;) >> > >> > Regards, >> > >> > Nick Van den Bleeken >> > >> > On Fri, Mar 19, 2010 at 19:36, Alessandro Vernet [via Orbeon Forms >> > (ops-users)] <[hidden email]> wrote: >> >> >> >> Hi Nick, >> >> >> >> My bad. I based this on your first submission using a SimpleDialog, >> >> and didn't think about the case where you have multiple xforms:message >> >> in one Ajax response, which you handled in your second submission. I >> >> push a change for this so the messages are queued, like you did. >> >> You'll let me know how this works for you. >> >> >> >> Alex >> >> >> >> On Fri, Mar 19, 2010 at 6:48 AM, nvdbleek <[hidden email]> wrote: >> >> > Hi Alex, >> >> > >> >> > I didn't sport this e-mail before sending the other one (sorry for >> >> > this). It >> >> > is great work you did, the only big difference I see is that when >> >> > sending >> >> > multiple messages they are shown simultaneous (didn't try it yet, but >> >> > just >> >> > looked to the code). And so you don't know the order of the messages. >> >> > In >> >> > the >> >> > patch I had an array with all messages that should be shown, this is >> >> > really >> >> > handy when writing the unit tests for the XForms WG test suite. >> >> > >> >> > Did you have a specific reason to drop the the array to manage the >> >> > messages? >> >> > >> >> > Regards, >> >> > >> >> > On Thu, Mar 18, 2010 at 23:42, Alessandro Vernet [via Orbeon Forms >> >> > (ops-users)] <[hidden email]> wrote: >> >> >> >> >> >> Hi Nick, >> >> >> >> >> >> Sorry for the delay integrating this! We have a couple of options to >> >> >> implement a dialog at the HTML level: >> >> >> >> >> >> A1. Use a SimpleDialog, as you did in your initial submission. >> >> >> A2. Use a "regular" dialog created based on markup present in the >> >> >> page, which can be customized by overriding an XML originally in the >> >> >> jar. >> >> >> >> >> >> Then there is the question of giving developers the option of >> >> >> keeping >> >> >> the current behavior: >> >> >> >> >> >> B1. We have a property to choose if the xforms:message uses alert() >> >> >> or >> >> >> an HTML dialog. >> >> >> B2. We don't have such a property; the HTML dialog is always used. >> >> >> >> >> >> I went with A1/B1, as in my experience the xforms:message is used >> >> >> mostly for debugging, and so folk don't care that much about how it >> >> >> is >> >> >> displayed. If they need something nicer, they can use the alert >> >> >> dialog >> >> >> XBL component >> >> >> >> >> >> >> >> >> (http://wiki.orbeon.com/forms/doc/developer-guide/xbl-components#TOC-Alert-dialog), >> >> >> and if they want something custom, they can easily create their own >> >> >> XBL component for this. >> >> >> >> >> >> The only downside I can think of, is that this will prevent one from >> >> >> showing a debug message just before running an xforms:submission >> >> >> replace="all". It turns out we don't allow this ("by mistake"), so >> >> >> nobody is using this feature presently, hence this shouldn't be a >> >> >> problem. Anyway, for debugging, it is better to use >> >> >> level="xxforms:log-debug" an look at the logs. >> >> >> >> >> >> This change is now in. Again, my apologies for the delay, and you'll >> >> >> let us know how this works for you. >> >> >> >> >> >> Alex >> >> >> >> >> >> On Sat, Jan 23, 2010 at 10:59 AM, Nick Van den Bleeken <[hidden >> >> >> email]> >> >> >> wrote: >> >> >> > Erik, Alessandro, >> >> >> > >> >> >> > While working on a test harness for the XForms 1.1 test suite >> >> >> > (http://github.com/nvdbleek/com.orbeon.testsuite.w3c ) I hit the >> >> >> > following two problems which I'm a bit stuck on. >> >> >> > >> >> >> > 1. xf:message uses javascript alert() >> >> >> > >> >> >> > The XForms 1.1 uses an xf:message in a lot of tests to display a >> >> >> > message to the user. In orbeon the message is shown to the user >> >> >> > using >> >> >> > the javascript alert function. The alert box blocks all javascript >> >> >> > execution (javascript is single threaded if you don't use >> >> >> > workers). >> >> >> > And therefore selenium can't test for alert boxes when they are >> >> >> > shown >> >> >> > before selenium can execute the code to replace the alert method >> >> >> > (they >> >> >> > replace it with a function so they can check if there was an alert >> >> >> > and >> >> >> > what the message was, but for all messages shown before >> >> >> > xforms-ready >> >> >> > finishes this fails, and this feature is heavily used by the >> >> >> > tests). >> >> >> > >> >> >> > To work around this issue I wanted to replace the code that >> >> >> > handles >> >> >> > the xf:message in xforms.js with >> >> >> > >> >> >> > if (ORBEON.util.Dom.getAttribute(messageElement, "level") == >> >> >> > "modal") >> >> >> > { >> >> >> > if (ORBEON.xforms.Globals.alertDialog == null) { >> >> >> > YUI alert dialog used by alert action >> >> >> > ORBEON.xforms.Globals.alertDialog = new >> >> >> > YAHOO.widget.SimpleDialog("alert_dlg1", { >> >> >> > width : "200px", >> >> >> > effect : { >> >> >> > effect : >> >> >> > YAHOO.widget.ContainerEffect.FADE, >> >> >> > duration : 0.15 >> >> >> > }, >> >> >> > fixedcenter : true, >> >> >> > modal : true, >> >> >> > visible : false, >> >> >> > close : true, >> >> >> > constraintoviewport : true, >> >> >> > buttons : [ { >> >> >> > text : "close", >> >> >> > handler : function() { >> >> >> > this.hide(); >> >> >> > }, >> >> >> > isDefault : true >> >> >> > } ], >> >> >> > draggable : false, >> >> >> > effect : [ { >> >> >> > effect : >> >> >> > YAHOO.widget.ContainerEffect.FADE, >> >> >> > duration : 0.1 >> >> >> > } ] >> >> >> > }); >> >> >> > >> >> >> > ORBEON.xforms.Globals.alertDialog.form = >> >> >> > ORBEON.xforms.Globals.requestForm; >> >> >> > >> >> >> > ORBEON.xforms.Globals.alertDialog.setHeader("Alert"); >> >> >> > >> >> >> > ORBEON.xforms.Globals.alertDialog.render(document.body); >> >> >> > } >> >> >> > >> >> >> > >> >> >> > ORBEON.xforms.Globals.alertDialog.cfg.setProperty("text",message); >> >> >> > ORBEON.xforms.Globals.alertDialog.show(); >> >> >> > } >> >> >> > >> >> >> > But this messes up the form object. I saw that Orbeon patched the >> >> >> > dialog for a similar reason I guess... >> >> >> > >> >> >> > What is you're opinion in changing the xf:message to a YUI dialog? >> >> >> > It >> >> >> > will also introduce a behavior change if implemented like this. >> >> >> > Namely >> >> >> > when you use alert and have actions (possibly other xf:message >> >> >> > actions) after the xf:message those will be handled (likely) >> >> >> > before >> >> >> > the user confirms the message. If you make the action list global >> >> >> > and >> >> >> > handle the next action when the dialog is confirmed, you can still >> >> >> > have the old behavior. But this requires quite some changes (and >> >> >> > the >> >> >> > handleResponseDom method should also check if there is currently >> >> >> > no >> >> >> > message shown when it is first called, if so it should add his >> >> >> > actions >> >> >> > to the global action list). What do you think of this? >> >> >> > >> >> >> > Another approach is to leave alone the current implementation, and >> >> >> > only change the xf:message handler when it is running tests. It >> >> >> > could >> >> >> > just append the message to a global list of non-confirmed >> >> >> > messages, >> >> >> > and the test can remove the item when it expects a message (and >> >> >> > check >> >> >> > at the end if the list is empty -> if no messages should be shown >> >> >> > in >> >> >> > the test it should assert this). This has the main advantage that >> >> >> > the >> >> >> > change is simple and only affects the current code when we are >> >> >> > testing >> >> >> > (we could do this by a special attribute on the xf:message element >> >> >> > or >> >> >> > a configuration option). The main disadvantage is that you aren't >> >> >> > testing the code that the user will use when he is running the >> >> >> > form >> >> >> > in >> >> >> > real-life mode. >> >> >> > >> >> >> > I'm interested in what your opinion is about this 'issue' and how >> >> >> > I >> >> >> > or >> >> >> > we can solve my problem. >> >> >> > >> >> >> > >> >> >> > >> >> >> > 2. How do you know when an AJAX call has returned (selection >> >> >> > option, >> >> >> > typing text,...) >> >> >> > >> >> >> > I found 'ORBEON.xforms.Globals.requestInProgress || >> >> >> > ORBEON.xforms.Globals.eventQueue.length > 0' but in some cases the >> >> >> > boolean isn't true yet and the event isn't yet in eventQueue. Is >> >> >> > there >> >> >> > a reliable way to know if all the updates for the operation >> >> >> > (typing >> >> >> > text, selectin an option) is done? >> >> >> > -- >> >> >> > Regards, >> >> >> > >> >> >> > Nick Van den Bleeken >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > You receive this message as a subscriber of the [hidden email] >> >> >> > mailing >> >> >> > list. >> >> >> > To unsubscribe: mailto:[hidden email] >> >> >> > For general help: mailto:[hidden email]?subject=help >> >> >> > OW2 mailing lists service home page: http://www.ow2.org/wws >> >> >> > >> >> >> > >> >> >> >> >> >> -- >> >> >> Orbeon Forms - Web forms, open-source, for the Enterprise - >> >> >> http://www.orbeon.com/ >> >> >> My Twitter: http://twitter.com/avernet >> >> >> >> >> >> >> >> >> -- >> >> >> You receive this message as a subscriber of the [hidden email] >> >> >> mailing >> >> >> list. >> >> >> To unsubscribe: mailto:[hidden email] >> >> >> For general help: mailto:[hidden email]?subject=help >> >> >> OW2 mailing lists service home page: http://www.ow2.org/wws >> >> > >> >> > >> >> > >> >> > -- >> >> > Regards, >> >> > >> >> > Nick Van den Bleeken >> >> > >> >> > ________________________________ >> >> > View this message in context: Re: Two questions related to running >> >> > XForms >> >> > 1.1 test suite automaticly (xf:message, How do you know when an AJAX >> >> > call >> >> > has returned) >> >> > Sent from the Orbeon Forms (ops-users) mailing list archive at >> >> > Nabble.com. >> >> > >> >> > >> >> > -- >> >> > You receive this message as a subscriber of the [hidden email] >> >> > mailing >> >> > list. >> >> > To unsubscribe: mailto:[hidden email] >> >> > For general help: mailto:[hidden email]?subject=help >> >> > OW2 mailing lists service home page: http://www.ow2.org/wws >> >> > >> >> > >> >> >> >> -- >> >> Orbeon Forms - Web forms, open-source, for the Enterprise - >> >> http://www.orbeon.com/ >> >> My Twitter: http://twitter.com/avernet >> >> >> >> >> >> -- >> >> You receive this message as a subscriber of the [hidden email] mailing >> >> list. >> >> To unsubscribe: mailto:[hidden email] >> >> For general help: mailto:[hidden email]?subject=help >> >> OW2 mailing lists service home page: http://www.ow2.org/wws >> > >> > >> > >> > -- >> > Regards, >> > >> > Nick Van den Bleeken >> > >> > ________________________________ >> > View this message in context: Re: Re: Two questions related to running >> > XForms 1.1 testsuiteautomaticly (xf:message, How do you know when an >> > AJAX >> > call has returned) >> > Sent from the Orbeon Forms (ops-users) mailing list archive at >> > Nabble.com. >> > >> > >> > -- >> > You receive this message as a subscriber of the [hidden email] mailing >> > list. >> > To unsubscribe: mailto:[hidden email] >> > For general help: mailto:[hidden email]?subject=help >> > OW2 mailing lists service home page: http://www.ow2.org/wws >> > >> > >> -- >> Orbeon Forms - Web forms, open-source, for the Enterprise - >> http://www.orbeon.com/ >> My Twitter: http://twitter.com/avernet >> >> >> -- >> You receive this message as a subscriber of the [hidden email] mailing >> list. >> To unsubscribe: mailto:[hidden email] >> For general help: mailto:[hidden email]?subject=help >> OW2 mailing lists service home page: http://www.ow2.org/wws > > > > -- > Regards, > > Nick Van den Bleeken > > ________________________________ > View this message in context: Re: Re: Re: Two questions related to running > XForms 1.1testsuiteautomaticly (xf:message, How do you know when an AJAX > call has returned) > Sent from the Orbeon Forms (ops-users) mailing list archive at Nabble.com. > > > -- > You receive this message as a subscriber of the [hidden email] mailing > list. > To unsubscribe: mailto:[hidden email] > For general help: mailto:[hidden email]?subject=help > OW2 mailing lists service home page: http://www.ow2.org/wws > > -- Orbeon Forms - Web forms, open-source, for the Enterprise - http://www.orbeon.com/ My Twitter: http://twitter.com/avernet -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help OW2 mailing lists service home page: http://www.ow2.org/wws
--
Follow Orbeon on Twitter: @orbeon Follow me on Twitter: @avernet |
|
|
Hi Alex,
Both methods will work for me. Just need to to adjust my unit test glue code. (Could you send me an e-mail when you have the final version of your code, I'll wait till that's available to merge it in and make the adjustments). But I'm not sure that you need to block everything, if you want to comply with the XForms spec. I'm not sure that the action blocks until the user has closed the message. And by consequence also blocks delayed dispatch actions. Maybe we should ask Erik what he thinks about this. Nick On Tue, Mar 23, 2010 at 19:10, Alessandro Vernet [via Orbeon Forms (ops-users)] <[hidden email]> wrote: Nick, -- Regards, Nick Van den Bleeken |
Re: Re: Re: Re: Re: Two questions related to running XForms1.1testsuiteautomaticly (xf:message, How do you know when an AJAX call has returned)
|
Administrator
|
Nick,
This is a good point: I don't see in the spec that a modal xforms:message should block subsequent actions until the user "closed" the message. Is this left to the implementation? Am I missing something? Alex On Wed, Mar 24, 2010 at 1:45 AM, nvdbleek <[hidden email]> wrote: > Hi Alex, > > Both methods will work for me. Just need to to adjust my unit test glue > code. (Could you send me an e-mail when you have the final version of your > code, I'll wait till that's available to merge it in and make the > adjustments). > > But I'm not sure that you need to block everything, if you want to comply > with the XForms spec. I'm not sure that the action blocks until the user has > closed the message. And by consequence also blocks delayed dispatch actions. > Maybe we should ask Erik what he thinks about this. > > Nick > > On Tue, Mar 23, 2010 at 19:10, Alessandro Vernet [via Orbeon Forms > (ops-users)] <[hidden email]> wrote: >> >> Nick, >> >> You are saying that you want to access the message that is being >> displayed programmatically without looking for it in the DOM? That >> might be harder the way I put the code in, as I haven't used a global >> message queue, but kept instead a message queue local to the >> handleResponseDom() function (see code in the: case "message":). Is >> that a problem for the unit tests? >> >> Also, related to the xforms:message, I was discussing with a client >> this morning who happens to use thexforms:message to show a message to >> end users before going to another page. So the new implementation >> won't work for this, and don't think we can get away without also >> providing a blocking implementation of xforms:message. We can either: >> >> 1. Have a property to choose if you want to use the new non-blocking >> HTML message dialog or the browser's blocking alert(). >> 2. Refactor the code in handleResponseDom() to make the HTML message >> dialog blocking. >> >> Obviously 2 is more complicated, but I am tempted to go that route as >> it would allow us to clean up that code while at it putting in >> practice some good old object oriented paradigms ;). >> >> Alex >> >> On Tue, Mar 23, 2010 at 1:41 AM, nvdbleek <[hidden email]> wrote: >> > Hi Alex, >> > >> > Looks good, I'll merge it in after the FtF meeting. It will require some >> > changes in my unit test code because I access the messageQueue directly >> > and >> > not the text in the dialog (didn't want to rely on the 'presentation' of >> > the >> > message, otherwise when somebody decided to show extra stuff in the >> > message >> > dialog, the tests will break, but that is probably to theoretical). By >> > the >> > way, the XForms test suite work is progressing well (did 328 of the 458 >> > tests). >> > >> > Again thank you for 'merging' it in (sorry for all the rewrite work you >> > had >> > to do). >> > >> > Regards, >> > >> > Nick >> > >> > On Tue, Mar 23, 2010 at 00:45, Alessandro Vernet [via Orbeon Forms >> > (ops-users)] <[hidden email]> wrote: >> >> >> >> Hi Nick, >> >> >> >> Good point! I put in the support for the xforms:messages that happen >> >> before the HTML is sent to the client. This will be in the next >> >> nightly build, so you'll let me know if this all works for you. >> >> >> >> Alex >> >> >> >> On Sun, Mar 21, 2010 at 10:02 AM, nvdbleek <[hidden email]> wrote: >> >> > Hi Alex, >> >> > >> >> > Just hit a small problem with the patch I did (and it is also in >> >> > yours) >> >> > if a >> >> > message action is executed before xforms-ready (in >> >> > xforms-model-construct in >> >> > my case) the normal code path for displaying the message isn't used. >> >> > The >> >> > message is then shown in xformsPageLoadedServer() which is generated >> >> > by >> >> > XHTMLHeadHandler. See >> >> > >> >> > >> >> > http://github.com/nvdbleek/orbeon-forms/commit/909b62431c06a3ecedc20690047fabd7590a951b >> >> > for my commit that solves the problem for my version of the YUI >> >> > message. >> >> > >> >> > Sorry for the inconvenience, but you can fix it when you fix the >> >> > multiple >> >> > messages problem ;) >> >> > >> >> > Regards, >> >> > >> >> > Nick Van den Bleeken >> >> > >> >> > On Fri, Mar 19, 2010 at 19:36, Alessandro Vernet [via Orbeon Forms >> >> > (ops-users)] <[hidden email]> wrote: >> >> >> >> >> >> Hi Nick, >> >> >> >> >> >> My bad. I based this on your first submission using a SimpleDialog, >> >> >> and didn't think about the case where you have multiple >> >> >> xforms:message >> >> >> in one Ajax response, which you handled in your second submission. I >> >> >> push a change for this so the messages are queued, like you did. >> >> >> You'll let me know how this works for you. >> >> >> >> >> >> Alex >> >> >> >> >> >> On Fri, Mar 19, 2010 at 6:48 AM, nvdbleek <[hidden email]> wrote: >> >> >> > Hi Alex, >> >> >> > >> >> >> > I didn't sport this e-mail before sending the other one (sorry for >> >> >> > this). It >> >> >> > is great work you did, the only big difference I see is that when >> >> >> > sending >> >> >> > multiple messages they are shown simultaneous (didn't try it yet, >> >> >> > but >> >> >> > just >> >> >> > looked to the code). And so you don't know the order of the >> >> >> > messages. >> >> >> > In >> >> >> > the >> >> >> > patch I had an array with all messages that should be shown, this >> >> >> > is >> >> >> > really >> >> >> > handy when writing the unit tests for the XForms WG test suite. >> >> >> > >> >> >> > Did you have a specific reason to drop the the array to manage the >> >> >> > messages? >> >> >> > >> >> >> > Regards, >> >> >> > >> >> >> > On Thu, Mar 18, 2010 at 23:42, Alessandro Vernet [via Orbeon Forms >> >> >> > (ops-users)] <[hidden email]> wrote: >> >> >> >> >> >> >> >> Hi Nick, >> >> >> >> >> >> >> >> Sorry for the delay integrating this! We have a couple of options >> >> >> >> to >> >> >> >> implement a dialog at the HTML level: >> >> >> >> >> >> >> >> A1. Use a SimpleDialog, as you did in your initial submission. >> >> >> >> A2. Use a "regular" dialog created based on markup present in the >> >> >> >> page, which can be customized by overriding an XML originally in >> >> >> >> the >> >> >> >> jar. >> >> >> >> >> >> >> >> Then there is the question of giving developers the option of >> >> >> >> keeping >> >> >> >> the current behavior: >> >> >> >> >> >> >> >> B1. We have a property to choose if the xforms:message uses >> >> >> >> alert() >> >> >> >> or >> >> >> >> an HTML dialog. >> >> >> >> B2. We don't have such a property; the HTML dialog is always >> >> >> >> used. >> >> >> >> >> >> >> >> I went with A1/B1, as in my experience the xforms:message is used >> >> >> >> mostly for debugging, and so folk don't care that much about how >> >> >> >> it >> >> >> >> is >> >> >> >> displayed. If they need something nicer, they can use the alert >> >> >> >> dialog >> >> >> >> XBL component >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> (http://wiki.orbeon.com/forms/doc/developer-guide/xbl-components#TOC-Alert-dialog), >> >> >> >> and if they want something custom, they can easily create their >> >> >> >> own >> >> >> >> XBL component for this. >> >> >> >> >> >> >> >> The only downside I can think of, is that this will prevent one >> >> >> >> from >> >> >> >> showing a debug message just before running an xforms:submission >> >> >> >> replace="all". It turns out we don't allow this ("by mistake"), >> >> >> >> so >> >> >> >> nobody is using this feature presently, hence this shouldn't be a >> >> >> >> problem. Anyway, for debugging, it is better to use >> >> >> >> level="xxforms:log-debug" an look at the logs. >> >> >> >> >> >> >> >> This change is now in. Again, my apologies for the delay, and >> >> >> >> you'll >> >> >> >> let us know how this works for you. >> >> >> >> >> >> >> >> Alex >> >> >> >> >> >> >> >> On Sat, Jan 23, 2010 at 10:59 AM, Nick Van den Bleeken <[hidden >> >> >> >> email]> >> >> >> >> wrote: >> >> >> >> > Erik, Alessandro, >> >> >> >> > >> >> >> >> > While working on a test harness for the XForms 1.1 test suite >> >> >> >> > (http://github.com/nvdbleek/com.orbeon.testsuite.w3c ) I hit >> >> >> >> > the >> >> >> >> > following two problems which I'm a bit stuck on. >> >> >> >> > >> >> >> >> > 1. xf:message uses javascript alert() >> >> >> >> > >> >> >> >> > The XForms 1.1 uses an xf:message in a lot of tests to display >> >> >> >> > a >> >> >> >> > message to the user. In orbeon the message is shown to the user >> >> >> >> > using >> >> >> >> > the javascript alert function. The alert box blocks all >> >> >> >> > javascript >> >> >> >> > execution (javascript is single threaded if you don't use >> >> >> >> > workers). >> >> >> >> > And therefore selenium can't test for alert boxes when they are >> >> >> >> > shown >> >> >> >> > before selenium can execute the code to replace the alert >> >> >> >> > method >> >> >> >> > (they >> >> >> >> > replace it with a function so they can check if there was an >> >> >> >> > alert >> >> >> >> > and >> >> >> >> > what the message was, but for all messages shown before >> >> >> >> > xforms-ready >> >> >> >> > finishes this fails, and this feature is heavily used by the >> >> >> >> > tests). >> >> >> >> > >> >> >> >> > To work around this issue I wanted to replace the code that >> >> >> >> > handles >> >> >> >> > the xf:message in xforms.js with >> >> >> >> > >> >> >> >> > if (ORBEON.util.Dom.getAttribute(messageElement, "level") == >> >> >> >> > "modal") >> >> >> >> > { >> >> >> >> > if (ORBEON.xforms.Globals.alertDialog == null) { >> >> >> >> > YUI alert dialog used by alert action >> >> >> >> > ORBEON.xforms.Globals.alertDialog = new >> >> >> >> > YAHOO.widget.SimpleDialog("alert_dlg1", { >> >> >> >> > width : "200px", >> >> >> >> > effect : { >> >> >> >> > effect : >> >> >> >> > YAHOO.widget.ContainerEffect.FADE, >> >> >> >> > duration : 0.15 >> >> >> >> > }, >> >> >> >> > fixedcenter : true, >> >> >> >> > modal : true, >> >> >> >> > visible : false, >> >> >> >> > close : true, >> >> >> >> > constraintoviewport : true, >> >> >> >> > buttons : [ { >> >> >> >> > text : "close", >> >> >> >> > handler : function() { >> >> >> >> > this.hide(); >> >> >> >> > }, >> >> >> >> > isDefault : true >> >> >> >> > } ], >> >> >> >> > draggable : false, >> >> >> >> > effect : [ { >> >> >> >> > effect : >> >> >> >> > YAHOO.widget.ContainerEffect.FADE, >> >> >> >> > duration : 0.1 >> >> >> >> > } ] >> >> >> >> > }); >> >> >> >> > >> >> >> >> > ORBEON.xforms.Globals.alertDialog.form = >> >> >> >> > ORBEON.xforms.Globals.requestForm; >> >> >> >> > >> >> >> >> > ORBEON.xforms.Globals.alertDialog.setHeader("Alert"); >> >> >> >> > >> >> >> >> > ORBEON.xforms.Globals.alertDialog.render(document.body); >> >> >> >> > } >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > ORBEON.xforms.Globals.alertDialog.cfg.setProperty("text",message); >> >> >> >> > ORBEON.xforms.Globals.alertDialog.show(); >> >> >> >> > } >> >> >> >> > >> >> >> >> > But this messes up the form object. I saw that Orbeon patched >> >> >> >> > the >> >> >> >> > dialog for a similar reason I guess... >> >> >> >> > >> >> >> >> > What is you're opinion in changing the xf:message to a YUI >> >> >> >> > dialog? >> >> >> >> > It >> >> >> >> > will also introduce a behavior change if implemented like this. >> >> >> >> > Namely >> >> >> >> > when you use alert and have actions (possibly other xf:message >> >> >> >> > actions) after the xf:message those will be handled (likely) >> >> >> >> > before >> >> >> >> > the user confirms the message. If you make the action list >> >> >> >> > global >> >> >> >> > and >> >> >> >> > handle the next action when the dialog is confirmed, you can >> >> >> >> > still >> >> >> >> > have the old behavior. But this requires quite some changes >> >> >> >> > (and >> >> >> >> > the >> >> >> >> > handleResponseDom method should also check if there is >> >> >> >> > currently >> >> >> >> > no >> >> >> >> > message shown when it is first called, if so it should add his >> >> >> >> > actions >> >> >> >> > to the global action list). What do you think of this? >> >> >> >> > >> >> >> >> > Another approach is to leave alone the current implementation, >> >> >> >> > and >> >> >> >> > only change the xf:message handler when it is running tests. It >> >> >> >> > could >> >> >> >> > just append the message to a global list of non-confirmed >> >> >> >> > messages, >> >> >> >> > and the test can remove the item when it expects a message (and >> >> >> >> > check >> >> >> >> > at the end if the list is empty -> if no messages should be >> >> >> >> > shown >> >> >> >> > in >> >> >> >> > the test it should assert this). This has the main advantage >> >> >> >> > that >> >> >> >> > the >> >> >> >> > change is simple and only affects the current code when we are >> >> >> >> > testing >> >> >> >> > (we could do this by a special attribute on the xf:message >> >> >> >> > element >> >> >> >> > or >> >> >> >> > a configuration option). The main disadvantage is that you >> >> >> >> > aren't >> >> >> >> > testing the code that the user will use when he is running the >> >> >> >> > form >> >> >> >> > in >> >> >> >> > real-life mode. >> >> >> >> > >> >> >> >> > I'm interested in what your opinion is about this 'issue' and >> >> >> >> > how >> >> >> >> > I >> >> >> >> > or >> >> >> >> > we can solve my problem. >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > 2. How do you know when an AJAX call has returned (selection >> >> >> >> > option, >> >> >> >> > typing text,...) >> >> >> >> > >> >> >> >> > I found 'ORBEON.xforms.Globals.requestInProgress || >> >> >> >> > ORBEON.xforms.Globals.eventQueue.length > 0' but in some cases >> >> >> >> > the >> >> >> >> > boolean isn't true yet and the event isn't yet in eventQueue. >> >> >> >> > Is >> >> >> >> > there >> >> >> >> > a reliable way to know if all the updates for the operation >> >> >> >> > (typing >> >> >> >> > text, selectin an option) is done? >> >> >> >> > -- >> >> >> >> > Regards, >> >> >> >> > >> >> >> >> > Nick Van den Bleeken >> >> >> >> > >> >> >> >> > >> >> >> >> > -- >> >> >> >> > You receive this message as a subscriber of the [hidden email] >> >> >> >> > mailing >> >> >> >> > list. >> >> >> >> > To unsubscribe: mailto:[hidden email] >> >> >> >> > For general help: mailto:[hidden email]?subject=help >> >> >> >> > OW2 mailing lists service home page: http://www.ow2.org/wws >> >> >> >> > >> >> >> >> > >> >> >> >> >> >> >> >> -- >> >> >> >> Orbeon Forms - Web forms, open-source, for the Enterprise - >> >> >> >> http://www.orbeon.com/ >> >> >> >> My Twitter: http://twitter.com/avernet >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> You receive this message as a subscriber of the [hidden email] >> >> >> >> mailing >> >> >> >> list. >> >> >> >> To unsubscribe: mailto:[hidden email] >> >> >> >> For general help: mailto:[hidden email]?subject=help >> >> >> >> OW2 mailing lists service home page: http://www.ow2.org/wws >> >> >> > >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > Regards, >> >> >> > >> >> >> > Nick Van den Bleeken >> >> >> > >> >> >> > ________________________________ >> >> >> > View this message in context: Re: Two questions related to running >> >> >> > XForms >> >> >> > 1.1 test suite automaticly (xf:message, How do you know when an >> >> >> > AJAX >> >> >> > call >> >> >> > has returned) >> >> >> > Sent from the Orbeon Forms (ops-users) mailing list archive at >> >> >> > Nabble.com. >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > You receive this message as a subscriber of the [hidden email] >> >> >> > mailing >> >> >> > list. >> >> >> > To unsubscribe: mailto:[hidden email] >> >> >> > For general help: mailto:[hidden email]?subject=help >> >> >> > OW2 mailing lists service home page: http://www.ow2.org/wws >> >> >> > >> >> >> > >> >> >> >> >> >> -- >> >> >> Orbeon Forms - Web forms, open-source, for the Enterprise - >> >> >> http://www.orbeon.com/ >> >> >> My Twitter: http://twitter.com/avernet >> >> >> >> >> >> >> >> >> -- >> >> >> You receive this message as a subscriber of the [hidden email] >> >> >> mailing >> >> >> list. >> >> >> To unsubscribe: mailto:[hidden email] >> >> >> For general help: mailto:[hidden email]?subject=help >> >> >> OW2 mailing lists service home page: http://www.ow2.org/wws >> >> > >> >> > >> >> > >> >> > -- >> >> > Regards, >> >> > >> >> > Nick Van den Bleeken >> >> > >> >> > ________________________________ >> >> > View this message in context: Re: Re: Two questions related to >> >> > running >> >> > XForms 1.1 testsuiteautomaticly (xf:message, How do you know when an >> >> > AJAX >> >> > call has returned) >> >> > Sent from the Orbeon Forms (ops-users) mailing list archive at >> >> > Nabble.com. >> >> > >> >> > >> >> > -- >> >> > You receive this message as a subscriber of the [hidden email] >> >> > mailing >> >> > list. >> >> > To unsubscribe: mailto:[hidden email] >> >> > For general help: mailto:[hidden email]?subject=help >> >> > OW2 mailing lists service home page: http://www.ow2.org/wws >> >> > >> >> > >> >> -- >> >> Orbeon Forms - Web forms, open-source, for the Enterprise - >> >> http://www.orbeon.com/ >> >> My Twitter: http://twitter.com/avernet >> >> >> >> >> >> -- >> >> You receive this message as a subscriber of the [hidden email] mailing >> >> list. >> >> To unsubscribe: mailto:[hidden email] >> >> For general help: mailto:[hidden email]?subject=help >> >> OW2 mailing lists service home page: http://www.ow2.org/wws >> > >> > >> > >> > -- >> > Regards, >> > >> > Nick Van den Bleeken >> > >> > ________________________________ >> > View this message in context: Re: Re: Re: Two questions related to >> > running >> > XForms 1.1testsuiteautomaticly (xf:message, How do you know when an AJAX >> > call has returned) >> > Sent from the Orbeon Forms (ops-users) mailing list archive at >> > Nabble.com. >> > >> > >> > -- >> > You receive this message as a subscriber of the [hidden email] mailing >> > list. >> > To unsubscribe: mailto:[hidden email] >> > For general help: mailto:[hidden email]?subject=help >> > OW2 mailing lists service home page: http://www.ow2.org/wws >> > >> > >> -- >> Orbeon Forms - Web forms, open-source, for the Enterprise - >> http://www.orbeon.com/ >> My Twitter: http://twitter.com/avernet >> >> >> -- >> You receive this message as a subscriber of the [hidden email] mailing >> list. >> To unsubscribe: mailto:[hidden email] >> For general help: mailto:[hidden email]?subject=help >> OW2 mailing lists service home page: http://www.ow2.org/wws > > > > -- > Regards, > > Nick Van den Bleeken > > ________________________________ > View this message in context: Re: Re: Re: Re: Two questions related to > running XForms1.1testsuiteautomaticly (xf:message, How do you know when an > AJAX call has returned) > Sent from the Orbeon Forms (ops-users) mailing list archive at Nabble.com. > > > -- > You receive this message as a subscriber of the [hidden email] mailing > list. > To unsubscribe: mailto:[hidden email] > For general help: mailto:[hidden email]?subject=help > OW2 mailing lists service home page: http://www.ow2.org/wws > > -- Orbeon Forms - Web forms, open-source, for the Enterprise - http://www.orbeon.com/ My Twitter: http://twitter.com/avernet -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help OW2 mailing lists service home page: http://www.ow2.org/wws
--
Follow Orbeon on Twitter: @orbeon Follow me on Twitter: @avernet |
Re: Re: Re: Re: Re: Re: Two questions related to runningXForms1.1testsuiteautom
|
|
After a brief discussion at the XForms f2f, it doesn't seem that the
spec clearly requires one or the other. Implementations seem to do whatever is the easiest! If anything, the blocking behavior seems to be losing favor. -Erik On Thu, Mar 25, 2010 at 12:51 AM, Alessandro Vernet <[hidden email]> wrote: > Nick, > > This is a good point: I don't see in the spec that a modal > xforms:message should block subsequent actions until the user "closed" > the message. Is this left to the implementation? Am I missing > something? > > Alex > > On Wed, Mar 24, 2010 at 1:45 AM, nvdbleek <[hidden email]> wrote: >> Hi Alex, >> >> Both methods will work for me. Just need to to adjust my unit test glue >> code. (Could you send me an e-mail when you have the final version of your >> code, I'll wait till that's available to merge it in and make the >> adjustments). >> >> But I'm not sure that you need to block everything, if you want to comply >> with the XForms spec. I'm not sure that the action blocks until the user has >> closed the message. And by consequence also blocks delayed dispatch actions. >> Maybe we should ask Erik what he thinks about this. >> >> Nick >> >> On Tue, Mar 23, 2010 at 19:10, Alessandro Vernet [via Orbeon Forms >> (ops-users)] <[hidden email]> wrote: >>> >>> Nick, >>> >>> You are saying that you want to access the message that is being >>> displayed programmatically without looking for it in the DOM? That >>> might be harder the way I put the code in, as I haven't used a global >>> message queue, but kept instead a message queue local to the >>> handleResponseDom() function (see code in the: case "message":). Is >>> that a problem for the unit tests? >>> >>> Also, related to the xforms:message, I was discussing with a client >>> this morning who happens to use thexforms:message to show a message to >>> end users before going to another page. So the new implementation >>> won't work for this, and don't think we can get away without also >>> providing a blocking implementation of xforms:message. We can either: >>> >>> 1. Have a property to choose if you want to use the new non-blocking >>> HTML message dialog or the browser's blocking alert(). >>> 2. Refactor the code in handleResponseDom() to make the HTML message >>> dialog blocking. >>> >>> Obviously 2 is more complicated, but I am tempted to go that route as >>> it would allow us to clean up that code while at it putting in >>> practice some good old object oriented paradigms ;). >>> >>> Alex >>> >>> On Tue, Mar 23, 2010 at 1:41 AM, nvdbleek <[hidden email]> wrote: >>> > Hi Alex, >>> > >>> > Looks good, I'll merge it in after the FtF meeting. It will require some >>> > changes in my unit test code because I access the messageQueue directly >>> > and >>> > not the text in the dialog (didn't want to rely on the 'presentation' of >>> > the >>> > message, otherwise when somebody decided to show extra stuff in the >>> > message >>> > dialog, the tests will break, but that is probably to theoretical). By >>> > the >>> > way, the XForms test suite work is progressing well (did 328 of the 458 >>> > tests). >>> > >>> > Again thank you for 'merging' it in (sorry for all the rewrite work you >>> > had >>> > to do). >>> > >>> > Regards, >>> > >>> > Nick >>> > >>> > On Tue, Mar 23, 2010 at 00:45, Alessandro Vernet [via Orbeon Forms >>> > (ops-users)] <[hidden email]> wrote: >>> >> >>> >> Hi Nick, >>> >> >>> >> Good point! I put in the support for the xforms:messages that happen >>> >> before the HTML is sent to the client. This will be in the next >>> >> nightly build, so you'll let me know if this all works for you. >>> >> >>> >> Alex >>> >> >>> >> On Sun, Mar 21, 2010 at 10:02 AM, nvdbleek <[hidden email]> wrote: >>> >> > Hi Alex, >>> >> > >>> >> > Just hit a small problem with the patch I did (and it is also in >>> >> > yours) >>> >> > if a >>> >> > message action is executed before xforms-ready (in >>> >> > xforms-model-construct in >>> >> > my case) the normal code path for displaying the message isn't used. >>> >> > The >>> >> > message is then shown in xformsPageLoadedServer() which is generated >>> >> > by >>> >> > XHTMLHeadHandler. See >>> >> > >>> >> > >>> >> > http://github.com/nvdbleek/orbeon-forms/commit/909b62431c06a3ecedc20690047fabd7590a951b >>> >> > for my commit that solves the problem for my version of the YUI >>> >> > message. >>> >> > >>> >> > Sorry for the inconvenience, but you can fix it when you fix the >>> >> > multiple >>> >> > messages problem ;) >>> >> > >>> >> > Regards, >>> >> > >>> >> > Nick Van den Bleeken >>> >> > >>> >> > On Fri, Mar 19, 2010 at 19:36, Alessandro Vernet [via Orbeon Forms >>> >> > (ops-users)] <[hidden email]> wrote: >>> >> >> >>> >> >> Hi Nick, >>> >> >> >>> >> >> My bad. I based this on your first submission using a SimpleDialog, >>> >> >> and didn't think about the case where you have multiple >>> >> >> xforms:message >>> >> >> in one Ajax response, which you handled in your second submission. I >>> >> >> push a change for this so the messages are queued, like you did. >>> >> >> You'll let me know how this works for you. >>> >> >> >>> >> >> Alex >>> >> >> >>> >> >> On Fri, Mar 19, 2010 at 6:48 AM, nvdbleek <[hidden email]> wrote: >>> >> >> > Hi Alex, >>> >> >> > >>> >> >> > I didn't sport this e-mail before sending the other one (sorry for >>> >> >> > this). It >>> >> >> > is great work you did, the only big difference I see is that when >>> >> >> > sending >>> >> >> > multiple messages they are shown simultaneous (didn't try it yet, >>> >> >> > but >>> >> >> > just >>> >> >> > looked to the code). And so you don't know the order of the >>> >> >> > messages. >>> >> >> > In >>> >> >> > the >>> >> >> > patch I had an array with all messages that should be shown, this >>> >> >> > is >>> >> >> > really >>> >> >> > handy when writing the unit tests for the XForms WG test suite. >>> >> >> > >>> >> >> > Did you have a specific reason to drop the the array to manage the >>> >> >> > messages? >>> >> >> > >>> >> >> > Regards, >>> >> >> > >>> >> >> > On Thu, Mar 18, 2010 at 23:42, Alessandro Vernet [via Orbeon Forms >>> >> >> > (ops-users)] <[hidden email]> wrote: >>> >> >> >> >>> >> >> >> Hi Nick, >>> >> >> >> >>> >> >> >> Sorry for the delay integrating this! We have a couple of options >>> >> >> >> to >>> >> >> >> implement a dialog at the HTML level: >>> >> >> >> >>> >> >> >> A1. Use a SimpleDialog, as you did in your initial submission. >>> >> >> >> A2. Use a "regular" dialog created based on markup present in the >>> >> >> >> page, which can be customized by overriding an XML originally in >>> >> >> >> the >>> >> >> >> jar. >>> >> >> >> >>> >> >> >> Then there is the question of giving developers the option of >>> >> >> >> keeping >>> >> >> >> the current behavior: >>> >> >> >> >>> >> >> >> B1. We have a property to choose if the xforms:message uses >>> >> >> >> alert() >>> >> >> >> or >>> >> >> >> an HTML dialog. >>> >> >> >> B2. We don't have such a property; the HTML dialog is always >>> >> >> >> used. >>> >> >> >> >>> >> >> >> I went with A1/B1, as in my experience the xforms:message is used >>> >> >> >> mostly for debugging, and so folk don't care that much about how >>> >> >> >> it >>> >> >> >> is >>> >> >> >> displayed. If they need something nicer, they can use the alert >>> >> >> >> dialog >>> >> >> >> XBL component >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> (http://wiki.orbeon.com/forms/doc/developer-guide/xbl-components#TOC-Alert-dialog), >>> >> >> >> and if they want something custom, they can easily create their >>> >> >> >> own >>> >> >> >> XBL component for this. >>> >> >> >> >>> >> >> >> The only downside I can think of, is that this will prevent one >>> >> >> >> from >>> >> >> >> showing a debug message just before running an xforms:submission >>> >> >> >> replace="all". It turns out we don't allow this ("by mistake"), >>> >> >> >> so >>> >> >> >> nobody is using this feature presently, hence this shouldn't be a >>> >> >> >> problem. Anyway, for debugging, it is better to use >>> >> >> >> level="xxforms:log-debug" an look at the logs. >>> >> >> >> >>> >> >> >> This change is now in. Again, my apologies for the delay, and >>> >> >> >> you'll >>> >> >> >> let us know how this works for you. >>> >> >> >> >>> >> >> >> Alex >>> >> >> >> >>> >> >> >> On Sat, Jan 23, 2010 at 10:59 AM, Nick Van den Bleeken <[hidden >>> >> >> >> email]> >>> >> >> >> wrote: >>> >> >> >> > Erik, Alessandro, >>> >> >> >> > >>> >> >> >> > While working on a test harness for the XForms 1.1 test suite >>> >> >> >> > (http://github.com/nvdbleek/com.orbeon.testsuite.w3c ) I hit >>> >> >> >> > the >>> >> >> >> > following two problems which I'm a bit stuck on. >>> >> >> >> > >>> >> >> >> > 1. xf:message uses javascript alert() >>> >> >> >> > >>> >> >> >> > The XForms 1.1 uses an xf:message in a lot of tests to display >>> >> >> >> > a >>> >> >> >> > message to the user. In orbeon the message is shown to the user >>> >> >> >> > using >>> >> >> >> > the javascript alert function. The alert box blocks all >>> >> >> >> > javascript >>> >> >> >> > execution (javascript is single threaded if you don't use >>> >> >> >> > workers). >>> >> >> >> > And therefore selenium can't test for alert boxes when they are >>> >> >> >> > shown >>> >> >> >> > before selenium can execute the code to replace the alert >>> >> >> >> > method >>> >> >> >> > (they >>> >> >> >> > replace it with a function so they can check if there was an >>> >> >> >> > alert >>> >> >> >> > and >>> >> >> >> > what the message was, but for all messages shown before >>> >> >> >> > xforms-ready >>> >> >> >> > finishes this fails, and this feature is heavily used by the >>> >> >> >> > tests). >>> >> >> >> > >>> >> >> >> > To work around this issue I wanted to replace the code that >>> >> >> >> > handles >>> >> >> >> > the xf:message in xforms.js with >>> >> >> >> > >>> >> >> >> > if (ORBEON.util.Dom.getAttribute(messageElement, "level") == >>> >> >> >> > "modal") >>> >> >> >> > { >>> >> >> >> > if (ORBEON.xforms.Globals.alertDialog == null) { >>> >> >> >> > YUI alert dialog used by alert action >>> >> >> >> > ORBEON.xforms.Globals.alertDialog = new >>> >> >> >> > YAHOO.widget.SimpleDialog("alert_dlg1", { >>> >> >> >> > width : "200px", >>> >> >> >> > effect : { >>> >> >> >> > effect : >>> >> >> >> > YAHOO.widget.ContainerEffect.FADE, >>> >> >> >> > duration : 0.15 >>> >> >> >> > }, >>> >> >> >> > fixedcenter : true, >>> >> >> >> > modal : true, >>> >> >> >> > visible : false, >>> >> >> >> > close : true, >>> >> >> >> > constraintoviewport : true, >>> >> >> >> > buttons : [ { >>> >> >> >> > text : "close", >>> >> >> >> > handler : function() { >>> >> >> >> > this.hide(); >>> >> >> >> > }, >>> >> >> >> > isDefault : true >>> >> >> >> > } ], >>> >> >> >> > draggable : false, >>> >> >> >> > effect : [ { >>> >> >> >> > effect : >>> >> >> >> > YAHOO.widget.ContainerEffect.FADE, >>> >> >> >> > duration : 0.1 >>> >> >> >> > } ] >>> >> >> >> > }); >>> >> >> >> > >>> >> >> >> > ORBEON.xforms.Globals.alertDialog.form = >>> >> >> >> > ORBEON.xforms.Globals.requestForm; >>> >> >> >> > >>> >> >> >> > ORBEON.xforms.Globals.alertDialog.setHeader("Alert"); >>> >> >> >> > >>> >> >> >> > ORBEON.xforms.Globals.alertDialog.render(document.body); >>> >> >> >> > } >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > ORBEON.xforms.Globals.alertDialog.cfg.setProperty("text",message); >>> >> >> >> > ORBEON.xforms.Globals.alertDialog.show(); >>> >> >> >> > } >>> >> >> >> > >>> >> >> >> > But this messes up the form object. I saw that Orbeon patched >>> >> >> >> > the >>> >> >> >> > dialog for a similar reason I guess... >>> >> >> >> > >>> >> >> >> > What is you're opinion in changing the xf:message to a YUI >>> >> >> >> > dialog? >>> >> >> >> > It >>> >> >> >> > will also introduce a behavior change if implemented like this. >>> >> >> >> > Namely >>> >> >> >> > when you use alert and have actions (possibly other xf:message >>> >> >> >> > actions) after the xf:message those will be handled (likely) >>> >> >> >> > before >>> >> >> >> > the user confirms the message. If you make the action list >>> >> >> >> > global >>> >> >> >> > and >>> >> >> >> > handle the next action when the dialog is confirmed, you can >>> >> >> >> > still >>> >> >> >> > have the old behavior. But this requires quite some changes >>> >> >> >> > (and >>> >> >> >> > the >>> >> >> >> > handleResponseDom method should also check if there is >>> >> >> >> > currently >>> >> >> >> > no >>> >> >> >> > message shown when it is first called, if so it should add his >>> >> >> >> > actions >>> >> >> >> > to the global action list). What do you think of this? >>> >> >> >> > >>> >> >> >> > Another approach is to leave alone the current implementation, >>> >> >> >> > and >>> >> >> >> > only change the xf:message handler when it is running tests. It >>> >> >> >> > could >>> >> >> >> > just append the message to a global list of non-confirmed >>> >> >> >> > messages, >>> >> >> >> > and the test can remove the item when it expects a message (and >>> >> >> >> > check >>> >> >> >> > at the end if the list is empty -> if no messages should be >>> >> >> >> > shown >>> >> >> >> > in >>> >> >> >> > the test it should assert this). This has the main advantage >>> >> >> >> > that >>> >> >> >> > the >>> >> >> >> > change is simple and only affects the current code when we are >>> >> >> >> > testing >>> >> >> >> > (we could do this by a special attribute on the xf:message >>> >> >> >> > element >>> >> >> >> > or >>> >> >> >> > a configuration option). The main disadvantage is that you >>> >> >> >> > aren't >>> >> >> >> > testing the code that the user will use when he is running the >>> >> >> >> > form >>> >> >> >> > in >>> >> >> >> > real-life mode. >>> >> >> >> > >>> >> >> >> > I'm interested in what your opinion is about this 'issue' and >>> >> >> >> > how >>> >> >> >> > I >>> >> >> >> > or >>> >> >> >> > we can solve my problem. >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > 2. How do you know when an AJAX call has returned (selection >>> >> >> >> > option, >>> >> >> >> > typing text,...) >>> >> >> >> > >>> >> >> >> > I found 'ORBEON.xforms.Globals.requestInProgress || >>> >> >> >> > ORBEON.xforms.Globals.eventQueue.length > 0' but in some cases >>> >> >> >> > the >>> >> >> >> > boolean isn't true yet and the event isn't yet in eventQueue. >>> >> >> >> > Is >>> >> >> >> > there >>> >> >> >> > a reliable way to know if all the updates for the operation >>> >> >> >> > (typing >>> >> >> >> > text, selectin an option) is done? >>> >> >> >> > -- >>> >> >> >> > Regards, >>> >> >> >> > >>> >> >> >> > Nick Van den Bleeken >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > -- >>> >> >> >> > You receive this message as a subscriber of the [hidden email] >>> >> >> >> > mailing >>> >> >> >> > list. >>> >> >> >> > To unsubscribe: mailto:[hidden email] >>> >> >> >> > For general help: mailto:[hidden email]?subject=help >>> >> >> >> > OW2 mailing lists service home page: http://www.ow2.org/wws >>> >> >> >> > >>> >> >> >> > >>> >> >> >> >>> >> >> >> -- >>> >> >> >> Orbeon Forms - Web forms, open-source, for the Enterprise - >>> >> >> >> http://www.orbeon.com/ >>> >> >> >> My Twitter: http://twitter.com/avernet >>> >> >> >> >>> >> >> >> >>> >> >> >> -- >>> >> >> >> You receive this message as a subscriber of the [hidden email] >>> >> >> >> mailing >>> >> >> >> list. >>> >> >> >> To unsubscribe: mailto:[hidden email] >>> >> >> >> For general help: mailto:[hidden email]?subject=help >>> >> >> >> OW2 mailing lists service home page: http://www.ow2.org/wws >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > -- >>> >> >> > Regards, >>> >> >> > >>> >> >> > Nick Van den Bleeken >>> >> >> > >>> >> >> > ________________________________ >>> >> >> > View this message in context: Re: Two questions related to running >>> >> >> > XForms >>> >> >> > 1.1 test suite automaticly (xf:message, How do you know when an >>> >> >> > AJAX >>> >> >> > call >>> >> >> > has returned) >>> >> >> > Sent from the Orbeon Forms (ops-users) mailing list archive at >>> >> >> > Nabble.com. >>> >> >> > >>> >> >> > >>> >> >> > -- >>> >> >> > You receive this message as a subscriber of the [hidden email] >>> >> >> > mailing >>> >> >> > list. >>> >> >> > To unsubscribe: mailto:[hidden email] >>> >> >> > For general help: mailto:[hidden email]?subject=help >>> >> >> > OW2 mailing lists service home page: http://www.ow2.org/wws >>> >> >> > >>> >> >> > >>> >> >> >>> >> >> -- >>> >> >> Orbeon Forms - Web forms, open-source, for the Enterprise - >>> >> >> http://www.orbeon.com/ >>> >> >> My Twitter: http://twitter.com/avernet >>> >> >> >>> >> >> >>> >> >> -- >>> >> >> You receive this message as a subscriber of the [hidden email] >>> >> >> mailing >>> >> >> list. >>> >> >> To unsubscribe: mailto:[hidden email] >>> >> >> For general help: mailto:[hidden email]?subject=help >>> >> >> OW2 mailing lists service home page: http://www.ow2.org/wws >>> >> > >>> >> > >>> >> > >>> >> > -- >>> >> > Regards, >>> >> > >>> >> > Nick Van den Bleeken >>> >> > >>> >> > ________________________________ >>> >> > View this message in context: Re: Re: Two questions related to >>> >> > running >>> >> > XForms 1.1 testsuiteautomaticly (xf:message, How do you know when an >>> >> > AJAX >>> >> > call has returned) >>> >> > Sent from the Orbeon Forms (ops-users) mailing list archive at >>> >> > Nabble.com. >>> >> > >>> >> > >>> >> > -- >>> >> > You receive this message as a subscriber of the [hidden email] >>> >> > mailing >>> >> > list. >>> >> > To unsubscribe: mailto:[hidden email] >>> >> > For general help: mailto:[hidden email]?subject=help >>> >> > OW2 mailing lists service home page: http://www.ow2.org/wws >>> >> > >>> >> > >>> >> -- >>> >> Orbeon Forms - Web forms, open-source, for the Enterprise - >>> >> http://www.orbeon.com/ >>> >> My Twitter: http://twitter.com/avernet >>> >> >>> >> >>> >> -- >>> >> You receive this message as a subscriber of the [hidden email] mailing >>> >> list. >>> >> To unsubscribe: mailto:[hidden email] >>> >> For general help: mailto:[hidden email]?subject=help >>> >> OW2 mailing lists service home page: http://www.ow2.org/wws >>> > >>> > >>> > >>> > -- >>> > Regards, >>> > >>> > Nick Van den Bleeken >>> > >>> > ________________________________ >>> > View this message in context: Re: Re: Re: Two questions related to >>> > running >>> > XForms 1.1testsuiteautomaticly (xf:message, How do you know when an AJAX >>> > call has returned) >>> > Sent from the Orbeon Forms (ops-users) mailing list archive at >>> > Nabble.com. >>> > >>> > >>> > -- >>> > You receive this message as a subscriber of the [hidden email] mailing >>> > list. >>> > To unsubscribe: mailto:[hidden email] >>> > For general help: mailto:[hidden email]?subject=help >>> > OW2 mailing lists service home page: http://www.ow2.org/wws >>> > >>> > >>> -- >>> Orbeon Forms - Web forms, open-source, for the Enterprise - >>> http://www.orbeon.com/ >>> My Twitter: http://twitter.com/avernet >>> >>> >>> -- >>> You receive this message as a subscriber of the [hidden email] mailing >>> list. >>> To unsubscribe: mailto:[hidden email] >>> For general help: mailto:[hidden email]?subject=help >>> OW2 mailing lists service home page: http://www.ow2.org/wws >> >> >> >> -- >> Regards, >> >> Nick Van den Bleeken >> >> ________________________________ >> View this message in context: Re: Re: Re: Re: Two questions related to >> running XForms1.1testsuiteautomaticly (xf:message, How do you know when an >> AJAX call has returned) >> Sent from the Orbeon Forms (ops-users) mailing list archive at Nabble.com. >> >> >> -- >> You receive this message as a subscriber of the [hidden email] mailing >> list. >> To unsubscribe: mailto:[hidden email] >> For general help: mailto:[hidden email]?subject=help >> OW2 mailing lists service home page: http://www.ow2.org/wws >> >> > > > > -- > Orbeon Forms - Web forms, open-source, for the Enterprise - > http://www.orbeon.com/ > My Twitter: http://twitter.com/avernet > > > -- > You receive this message as a subscriber of the [hidden email] mailing list. > To unsubscribe: mailto:[hidden email] > For general help: mailto:[hidden email]?subject=help > OW2 mailing lists service home page: http://www.ow2.org/wws > > -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help OW2 mailing lists service home page: http://www.ow2.org/wws |
«
Return to Orbeon Forms community mailing list
|
1 view|%1 views
| Free forum by Nabble | Edit this page |