Orbeon Forms community mailing list

Event Handling within nested XBL components

Classic

List

Threaded

10 messages Options

Philip.Cantin

Event Handling within nested XBL components

Hello,

I'm using nested XBL components within my main XHTML form that look like this:

<fr:idinfo>
<fr:citation>
<fr:citeinfo />
</fr:citation>
</fr:idinfo>

and I have a question about event handling within the components.

Currently, I have a textarea within the <fr:citeinfo> XBL component that, when the icon next to it is clicked:

1) <fr:citeinfo> dispatches an event listened to by <fr:citation>
2) <fr:citation> dispatches an event listened to by <fr:idinfo>
3) <fr:idinfo> dispatches an <xxforms:show> event which opens up an HTML editor
4) The user types in information, and after clicking the 'Update' button within the editor, the formatted text is saved to the textarea.

I already understand how to pass information from inner XBL nodes to outer XBL nodes, but how does one pass information the other way?

I've tried using the <xbl:handlers> tag to pass information from the main XHTML form downward to the innermost XBL component, but this doesn't seem to work. What's the proper way of doing this, if any?

And is it even necessary to pass information like this from an XHTML form to XBL components? For instance, is it possible to pass context information from the innermost XBL component to the main form, and, within the <xxforms:dialog> tag, execute an <xforms:setvalue> with that context information?

Please let me know if my use case doesn't make sense, and I will be more than happy to explain further. And attached is a ZIP file that contains reproducible code that illustrates my thinking process.

Thanks in advance for any suggestions or advice!

---Philip

xforms-xbl-test.zip

Alessandro Vernet

Re: Event Handling within nested XBL components

Administrator

Philip,

Philip.Cantin wrote

I already understand how to pass information from inner XBL nodes to outer XBL nodes, but how does one pass information the other way?

I've tried using the <xbl:handlers> tag to pass information from the main XHTML form downward to the innermost XBL component, but this doesn't seem to work. What's the proper way of doing this, if any?

I think you *do* understand well how it is supposed to work, but it looks to me like there is a glitch. I think you had a typo in your code where idinfo.xbl was dispatching pass-value3 to citation-component, but citation.xbl had a listener for pass-value2. So I changed that pass-value3 by pass-value2, but it doesn't solve the problem: for some reason, pass-value2 doesn't seem to get to the citation.

For now I added a bug for this, but we'll investigate this one further.

http://forge.ow2.org/tracker/index.php?func=detail&aid=314033&group_id=168&atid=350207

Alex

Philip.Cantin

Re: Event Handling within nested XBL components

Alex,

While this bug is being investigated, I was wondering if it was possible to somehow "capture" the context being passed to the main form's <xxforms:dialog> control from the nested XBL component, and use it in an <xforms:setvalue> statement within the main form. I was able to do this once using the 'xxforms-dialog-open' event inside <xforms:setvalue>, but I can't seem to reference that context a second time outside of the 'xxforms-dialog-open' event.

Is there a way I can achieve this? Perhaps I can dispatch an event like this:

<xxforms:dialog id="my-dialog">

<xf:action ev:event="xxforms-dialog-open">
<xf:setvalue ref="..." value="event('my-event')" />
<xf:dispatch name="dialog-event1" target="my-dialog">
<xxforms:context name="dialog-context1" select="event('my-event')" />
</xf:dispatch>
</xf:action>

...

</xxforms:dialog>

and reference the context of the event somewhere else within <xxforms:dialog>?

In short, my ultimate goal is simply to have a textarea display the value coming from a nested XBL component. And the code I am referencing above is the same code that is provided as an attachment within this thread.

Thanks in advance!

---Philip

Alessandro Vernet wrote

Philip,

Philip.Cantin wrote

I already understand how to pass information from inner XBL nodes to outer XBL nodes, but how does one pass information the other way?

I've tried using the <xbl:handlers> tag to pass information from the main XHTML form downward to the innermost XBL component, but this doesn't seem to work. What's the proper way of doing this, if any?

I think you *do* understand well how it is supposed to work, but it looks to me like there is a glitch. I think you had a typo in your code where idinfo.xbl was dispatching pass-value3 to citation-component, but citation.xbl had a listener for pass-value2. So I changed that pass-value3 by pass-value2, but it doesn't solve the problem: for some reason, pass-value2 doesn't seem to get to the citation.

For now I added a bug for this, but we'll investigate this one further.

http://forge.ow2.org/tracker/index.php?func=detail&aid=314033&group_id=168&atid=350207

Alex

Betty Harvey

XForms and Section 508 Compliancy

I have started some initial testing with Orbeon forms and Section 508
compliancy. I am not finding any issues with Section 508 yet. However,
my analysis hasn't been extensive.

Before I delved into testing further I thought it might be useful to
see if any else has done any formal analysis of Section 508 compliancy
in XForms in general or Orbeon's implementation of XForms. Likewise
if anyone is aware of any formal studies, use cases, etc. about
accessibility and XForms that would be great!

TIA!

Betty

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Betty Harvey | Phone: 410-787-9200 FAX: 9830
Electronic Commerce Connection, Inc. |
[hidden email] | Washington,DC XML Users Grp URL:
http://www.eccnet.com | http://www.eccnet.com/xmlug/
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\\/\/

--
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

Alessandro Vernet

Re: Event Handling within nested XBL components

Administrator

In reply to this post by Philip.Cantin

Philip,

Philip.Cantin wrote

While this bug is being investigated, I was wondering if it was possible to somehow "capture" the context being passed to the main form's <xxforms:dialog> control from the nested XBL component, and use it in an <xforms:setvalue> statement within the main form. I was able to do this once using the 'xxforms-dialog-open' event inside <xforms:setvalue>, but I can't seem to reference that context a second time outside of the 'xxforms-dialog-open' event.

You're talking about "capturing the context being passed to the main form's <xxforms:dialog> control from the nested XBL component". Is the dialog opened from within the XBL? I am afraid I don't quite get it. Would you have a very minimal example showing what you are trying to do and where the problem lies?

Alex

Alessandro Vernet

Re: XForms and Section 508 Compliancy

Administrator

In reply to this post by Betty Harvey

Hi Betty,

Betty Harvey wrote

I have started some initial testing with Orbeon forms and Section 508
compliancy. I am not finding any issues with Section 508 yet. However,
my analysis hasn't been extensive.

Before I delved into testing further I thought it might be useful to
see if any else has done any formal analysis of Section 508 compliancy
in XForms in general or Orbeon's implementation of XForms. Likewise
if anyone is aware of any formal studies, use cases, etc. about
accessibility and XForms that would be great!

When it comes to web applications, section 508 to me is a non-controversial subset of the W3C WCAG 1.0. I linked the relevant part of section 508 below; it is quite short and you can relatively quickly go through it, and I really don't see anything that would be a show stopper for using Orbeon Forms (or even other implementation of XForms) on a web site that need to be compliant with section 508.

http://www.section508.gov/index.cfm?FuseAction=Content&ID=12#Web

The main "problem" with WCAG 1.0 (but not with WCAG 2.0) is section 6.3 which mandates that you must at least provide a version of your pages that can be accessed with a browser with JavaScript turned off. We developed the non-script mode of Orbeon Forms to be compliant with that requirement. Section 508 doesn't have an equivalent to WCAG 1.1 section 6.3, so if you just need to be compliant with section 508, you don't even need to worry about this.

Alex

Philip.Cantin

Re: Event Handling within nested XBL components

In reply to this post by Alessandro Vernet

Alex,

Sorry for not being more clear; my use case was referring to the sandbox example that I attached as a ZIP at the beginning of this thread (xforms-xbl-test.zip).

The obstacle I'm trying to overcome can be reproduced with the following steps:

1) Open the ZIP file (I'll re-attach it below this message), copy the folder and run it in Orbeon.
2) Type "hello" within the text area.
3) Click the icon next to the text area - this will pop up a rich text editor. The word "hello" should be the value of the instance('yui-info')/tmp node.
4) Type "goodbye" and then click the 'Update' button within the editor.

The value "goodbye" is saved to the <tmp> node of the 'yui-info' instance, but the value "hello" remains in the text area. I imagine there must be something wrong with my <xf:setvalue> statement. In addition, I would also like the value of the text area to appear in the rich text editor whenever it is loaded.

I know, at least, that test_xforms.xhtml (my main XHTML form) is getting the value of the <title> node within the nested XBL components. I just want to be able to have that value of the text area loaded into the RTE, update that value, and have it display properly in the text area.

If there's anything else you need to know, please let me know! And thank you in advance, Alex!

---Philip

xforms-xbl-test.zip

Alessandro Vernet wrote

Philip,

Philip.Cantin wrote

While this bug is being investigated, I was wondering if it was possible to somehow "capture" the context being passed to the main form's <xxforms:dialog> control from the nested XBL component, and use it in an <xforms:setvalue> statement within the main form. I was able to do this once using the 'xxforms-dialog-open' event inside <xforms:setvalue>, but I can't seem to reference that context a second time outside of the 'xxforms-dialog-open' event.

You're talking about "capturing the context being passed to the main form's <xxforms:dialog> control from the nested XBL component". Is the dialog opened from within the XBL? I am afraid I don't quite get it. Would you have a very minimal example showing what you are trying to do and where the problem lies?

Alex

Erik Bruchez

Re: Re: Event Handling within nested XBL components

Administrator

Philip,

The event dispatch bug is now fixed and will be in the next automatic
build. Please let us know if that works for you!

http://github.com/orbeon/orbeon-forms/commit/96cf532036c04a489b1a88556de172aa46163259

-Erik

On Wed, Jul 22, 2009 at 3:41 PM, Philip.Cantin<[hidden email]> wrote:

>
> Alex,
>
> Sorry for not being more clear; my use case was referring to the sandbox
> example that I attached as a ZIP at the beginning of this thread
> (xforms-xbl-test.zip).
>
> The obstacle I'm trying to overcome can be reproduced with the following
> steps:
>
> 1) Open the ZIP file (I'll re-attach it below this message), copy the folder
> and run it in Orbeon.
> 2) Type "hello" within the text area.
> 3) Click the icon next to the text area - this will pop up a rich text
> editor. The word "hello" should be the value of the instance('yui-info')/tmp
> node.
> 4) Type "goodbye" and then click the 'Update' button within the editor.
>
> The value "goodbye" is saved to the <tmp> node of the 'yui-info' instance,
> but the value "hello" remains in the text area. I imagine there must be
> something wrong with my <xf:setvalue> statement. In addition, I would also
> like the value of the text area to appear in the rich text editor whenever
> it is loaded.
>
> I know, at least, that test_xforms.xhtml (my main XHTML form) is getting the
> value of the <title> node within the nested XBL components. I just want to
> be able to have that value of the text area loaded into the RTE, update that
> value, and have it display properly in the text area.
>
> If there's anything else you need to know, please let me know! And thank you
> in advance, Alex!
>
>
> ---Philip
>
>
> http://www.nabble.com/file/p24616191/xforms-xbl-test.zip xforms-xbl-test.zip
>
>
>
> Alessandro Vernet wrote:
>>
>> Philip,
>>
>>
>> Philip.Cantin wrote:
>>>
>>> While this bug is being investigated, I was wondering if it was possible
>>> to somehow "capture" the context being passed to the main form's
>>> <xxforms:dialog> control from the nested XBL component, and use it in an
>>> <xforms:setvalue> statement within the main form. I was able to do this
>>> once using the 'xxforms-dialog-open' event inside <xforms:setvalue>, but
>>> I can't seem to reference that context a second time outside of the
>>> 'xxforms-dialog-open' event.
>>>
>>
>> You're talking about "capturing the context being passed to the main
>> form's <xxforms:dialog> control from the nested XBL component". Is the
>> dialog opened from within the XBL? I am afraid I don't quite get it. Would
>> you have a very minimal example showing what you are trying to do and
>> where the problem lies?
>>
>> Alex
>>
>
> --
> View this message in context: http://www.nabble.com/Event-Handling-within-nested-XBL-components-tp24434096p24616191.html
> 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

Philip.Cantin

Re: Re: Event Handling within nested XBL components

Erik,

Apologies once again for this rather late reply, but thanks a bunch!!! I tested it with the 07-31-2009 and the 08-14-2009 nightly builds, and both seem to work just fine. The event handling now travels to the innermost XBL component and successfully carries out the action located there, with the help of <xbl:handlers> tags in each XBL component.

Now there is just one thing left for me to consider before I call this piece of functionality a victory. If you would, could you take a look at the reproducible example I have attached to this message? I may/may not have found another bug. Follow these steps below for reproduction:

1) Download attached ZIP file and place folder in the orbeon/WEB-INF/resources/apps folder, then run it.
2) Click icon next to first text area. A dialog window should pop up with a small (non-YUI) text area.
3) Type "hello" in the text area, and click the 'Update' button at the top. The first text area should have the value "hello" with some extra HTML.
4) Click the 'Add' button to the left of the first text area. A new section should be added.
5) Click icon next to second text area. A dialog window should pop up with NO value inside the text area of the dialog box. This reflects the current value of the second text area.
6) Repeat steps 1-5, but this time, in test_xbl.xhtml, change:

<xf:textarea ref="instance('yui-info')/tmp">

to

<xf:textarea ref="instance('yui-info')/tmp" mediatype="text/html">

so that the dialog box pops up with a YUI RTE instead of a regular text area.

Now when you get to step 5, the stale value "hello" should appear in the YUI RTE instead of a blank value. I'm wondering if this is a bug with the YUI RTE?

Thanks in advance if you get the time to take a look!

---Philip

xforms-xbl-test.zip

Erik Bruchez wrote

Philip,

The event dispatch bug is now fixed and will be in the next automatic
build. Please let us know if that works for you!

http://github.com/orbeon/orbeon-forms/commit/96cf532036c04a489b1a88556de172aa46163259

-Erik

On Wed, Jul 22, 2009 at 3:41 PM, Philip.Cantin<pjcantin@gmail.com> wrote:
>
> Alex,
>
> Sorry for not being more clear; my use case was referring to the sandbox
> example that I attached as a ZIP at the beginning of this thread
> (xforms-xbl-test.zip).
>
> The obstacle I'm trying to overcome can be reproduced with the following
> steps:
>
> 1) Open the ZIP file (I'll re-attach it below this message), copy the folder
> and run it in Orbeon.
> 2) Type "hello" within the text area.
> 3) Click the icon next to the text area - this will pop up a rich text
> editor. The word "hello" should be the value of the instance('yui-info')/tmp
> node.
> 4) Type "goodbye" and then click the 'Update' button within the editor.
>
> The value "goodbye" is saved to the <tmp> node of the 'yui-info' instance,
> but the value "hello" remains in the text area. I imagine there must be
> something wrong with my <xf:setvalue> statement. In addition, I would also
> like the value of the text area to appear in the rich text editor whenever
> it is loaded.
>
> I know, at least, that test_xforms.xhtml (my main XHTML form) is getting the
> value of the <title> node within the nested XBL components. I just want to
> be able to have that value of the text area loaded into the RTE, update that
> value, and have it display properly in the text area.
>
> If there's anything else you need to know, please let me know! And thank you
> in advance, Alex!
>
>
> ---Philip
>
>
> http://www.nabble.com/file/p24616191/xforms-xbl-test.zip xforms-xbl-test.zip
>
>
>
> Alessandro Vernet wrote:
>>
>> Philip,
>>
>>
>> Philip.Cantin wrote:
>>>
>>> While this bug is being investigated, I was wondering if it was possible
>>> to somehow "capture" the context being passed to the main form's
>>> <xxforms:dialog> control from the nested XBL component, and use it in an
>>> <xforms:setvalue> statement within the main form. I was able to do this
>>> once using the 'xxforms-dialog-open' event inside <xforms:setvalue>, but
>>> I can't seem to reference that context a second time outside of the
>>> 'xxforms-dialog-open' event.
>>>
>>
>> You're talking about "capturing the context being passed to the main
>> form's <xxforms:dialog> control from the nested XBL component". Is the
>> dialog opened from within the XBL? I am afraid I don't quite get it. Would
>> you have a very minimal example showing what you are trying to do and
>> where the problem lies?
>>
>> Alex
>>
>
> --
> View this message in context: http://www.nabble.com/Event-Handling-within-nested-XBL-components-tp24434096p24616191.html
> Sent from the ObjectWeb OPS - Users mailing list archive at Nabble.com.
>
>
>
> --
> You receive this message as a subscriber of the ops-users@ow2.org mailing list.
> To unsubscribe: mailto:ops-users-unsubscribe@ow2.org
> For general help: mailto:sympa@ow2.org?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws
>
>

--
You receive this message as a subscriber of the ops-users@ow2.org mailing list.
To unsubscribe: mailto:ops-users-unsubscribe@ow2.org
For general help: mailto:sympa@ow2.org?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws

Alessandro Vernet

Re: Re: Event Handling within nested XBL components

Administrator

Philip,

Philip.Cantin wrote

1) Download attached ZIP file and place folder in the orbeon/WEB-INF/resources/apps folder, then run it.
2) Click icon next to first text area. A dialog window should pop up with a small (non-YUI) text area.
3) Type "hello" in the text area, and click the 'Update' button at the top. The first text area should have the value "hello" with some extra HTML.
4) Click the 'Add' button to the left of the first text area. A new section should be added.
5) Click icon next to second text area. A dialog window should pop up with NO value inside the text area of the dialog box. This reflects the current value of the second text area.
6) Repeat steps 1-5, but this time, in test_xbl.xhtml, change:

Yes, this is a bug in the HTML editor. Nice catch. It was introduced on June 23 with commit 5a8cf6c0b76ab965faba2e0618a8822706cde8b7. I created a new bug for this (linked below), fixed it, and pushed the fix to GitHub. The nightly builds are stuck at this point, so it might be a few more days before we address that issue and you get a new nightly build with this change.

http://forge.ow2.org/tracker/index.php?func=detail&aid=314164&group_id=168&atid=350207

Alex