DOMActivate in xf:group

[cityEHR]

Hi,

I'm trying to upgrade from Orbeon 3.9 to the latest CE (please don't laugh!). Most things still work OK, or I've been able to fix, but I'm having trouble with the following code placed in xhtml:body which works in 3.9, but not in 2021.1 CE

                        <xforms:group>
                            <xforms:output ref="'Press me'"/>
                            <xforms:action ev:event="DOMActivate">
                                <xforms:message ref="'I was activated'"/>
                            </xforms:action>
                        </xforms:group>

As far as I can tell from https://doc.orbeon.com/xforms/xbl/guide/event-handling this should still work in 2021.1 CE.

Thanks, John

[Alessandro Vernet]

Hi John,

The `DOMActivate` isn't dispatched to a group. You can try using a trigger for this, as in the code below. By default, the "trigger" is rendered as a button, but if you want it to show as a link, you can add the attribute `appearance="minimal"`, and it will then show as a link. Would this work for you?

    <xforms:trigger>
        <xforms:label>

            <xforms:output ref="'Press me'"/>

        </xforms:label>

        <xforms:action ev:event="DOMActivate">
            <xforms:message ref="'I was activated'"/>
        </xforms:action>

    </xforms:trigger>

I am not sure if `DOMActivate` was indeed dispatched to a `xf:group` in the past – I don't remember that this was the case, but if your example worked, it must been so – but checking the spec, it shouldn't, and `DOMActivate` should only dispatched to "Core Controls", and `xf:group` isn't in that list.

https://www.w3.org/community/xformsusers/wiki/XForms_2.0#The_DOMActivate_Event

-Alex

[cityEHR]

Thanks Alex.

Actually, using the DOMActivate on xf:group was a workaround for trigger not working in 2021.1 CE in the same way as 3.9. So if I go back to using xf:trigger as you suggest, then I need to solve the following, which works in 3.9 but not 2021.1 CE. I am using this code because I want to chose different icons for the trigger, depending on what action its going to invoke.

<xforms:repeat nodeset="$actionList">

    <xxforms:variable name="action" select="."/>
    <xxforms:variable name="controlId" select="$action/@id"/>
    <xxforms:variable name="icon" select="concat(xxforms:instance('view-parameters-instance')/staticFileRoot,'/icons/',$controlId,'.png')"/>
    <xxforms:variable name="displayName" select="$action/@displayName"/>

    <xforms:trigger appearance="minimal" xxforms:modal="true">
        <xforms:label>
            <xhtml:img src="{$icon}" alt=""/>
        </xforms:label>
        <xforms:hint class="actionHint" ref="$displayName"/>

        <xforms:action ev:event="DOMActivate">

            <xforms:dispatch name="{$controlId}" target="viewControlsActions-model"/>
        </xforms:action>
    </xforms:trigger>

</xforms:repeat>

This crashes in 2021.1 CE because it doesn't like the AVT src="{$icon}" (it does work if I hard wire a path in @src).

Is there another way to do this in  2021.1 CE?

Thanks

[Alessandro Vernet]

Hi,

That `<xhtml:img src="{$icon}" alt=""/>` looks fine to me. I can run the following just fine:

    <xxf:var name="icon" value="'https://placekitten.com/g/100/100'"/>
    <xf:trigger appearance="minimal" xxf:modal="true">
        <xf:label>
            <xh:img src="{$icon}" alt=""/>
        </xf:label>
    </xf:trigger>

(I'd recommend you switch from the `xxforms:variable` to `xforms:var`, which is now standard, and uses a `ref` instead of `select`. We also tend to use the prefixes `xf` instead of `xforms` and `xxf` instead of `xxforms`.)

Would you be able to create a minimal example that I can run locally and that shows the problem you're having with the `<xhtml:img src="{$icon}" alt=""/>`?

-Alex

[cityEHR]

Thanks Alex,

I have managed to resolve this now using your suggestions, although I think it reveals an issue with namespace handling in Orbeon.

In 2021.1 CE, if I change my namespace declarations to us xf: and xxf: prefixes, then I can paste in your code snippet and it works. If on the other hand I keep xforms: and xxforms: prefixes and adjust these in your snippet, then it crashes,

So I have a work around, and because I want to use the same code base for 2021.1 CE and 3.9, I have changed all the namespace declarations to use xf: and xxf: prefixes throughout my code. This then results in multiple crashes in Orbeon 3.9 with code that has previously been working (with xforms: and xxforms: prefixes). I've worked through and fixed these now - they all involved xf:group in various ways and I've been able to work around that (in fact I think I'm going to eliminate the use of xf:group going forward).

So my issue is resolved - thank you for helping with that.

But there does seem to be an underlying issue with how Orbeon handles namespaces in both 2021.1 CE and 3.9 - easily avoided by using xf: and xxf: as prefixes and working around some uses of xf:group in 3.9, but strictly speaking something is a bit wrong with Orbeon namespace handling.

 

Thanks,

John

[Alessandro Vernet]

Hi John,

On Fri, Aug 26, 2022 at 3:39 AM 'cityEHR' via Orbeon Forms <orb...@googlegroups.com> wrote:

Thanks Alex,

I have managed to resolve this now using your suggestions, although I think it reveals an issue with namespace handling in Orbeon.

I don't think that we are aware of such a problem, which of course doesn't mean it doesn't exist! Is there any chance that you could create a minimal example that we can run here and that reproduces the problem you're seeing with prefixes resolution?

-Alex

[cityEHR]

Hi Alex - Here's the smallest example I could create - I expect I'm doing something silly, but I can't spot it.

As I say, its easy to work around by always using the xxf prefix, but that doesn't seem quite right.

In 2021.1 CE, the following works as expected

<?xml version="1.0" encoding="UTF-8"?>
<xh:html xmlns:xh="http://www.w3.org/1999/xhtml"
    xmlns:xf="http://www.w3.org/2002/xforms"
    xmlns:xxf="http://orbeon.org/oxf/xml/xforms"
    xmlns:ev="http://www.w3.org/2001/xml-events">

    <xh:head>
        <xf:model id="main-model"/>
    </xh:head>

    <xh:body>
        <xh:div>

            <xxf:var name="icon" value="'https://placekitten.com/g/100/100'"/>
            <xf:trigger appearance="minimal">

                <xf:label>
                    <xh:img src="{$icon}" alt="press" />
                </xf:label>
                <xf:action ev:event="DOMActivate">
                    <xf:message ref="'hello'"/>
                </xf:action>
            </xf:trigger>
        </xh:div>
    </xh:body>

</xh:html>

But if I change to use xforms: and xxforms: as prefixes, it crashes.

In fact, the problem seems to be using anything other than xxf as the prefix for xmlns:xxf="http://orbeon.org/oxf/xml/xforms"

Also, if I declare xmlns:xxf="http://orbeon.org/oxf/xml/xforms" as well, but don't use it then it works.

So I think Orbeon must be using the xxf: prefix somewhere behind the scenes but relying on my code to declare it.

<xh:html xmlns:xh="http://www.w3.org/1999/xhtml"
    xmlns:xforms="http://www.w3.org/2002/xforms"
    xmlns:xxforms="http://orbeon.org/oxf/xml/xforms"
    xmlns:ev="http://www.w3.org/2001/xml-events">

    <xh:head>
        <xforms:model id="main-model"/>
    </xh:head>

    <xh:body>
        <xh:div>
            <xxforms:var name="icon" value="'https://placekitten.com/g/100/100'"/>
            <xforms:trigger appearance="minimal">
                <xforms:label>
                    <xh:img src="{$icon}" alt="press" />

                </xforms:label>
                <xforms:action ev:event="DOMActivate">

                    <xforms:message ref="'hello'"/>
                </xforms:action>
            </xforms:trigger>
        </xh:div>
    </xh:body>

</xh:html>

[Alessandro Vernet]

Hi John,

Got it, thank you for the simple example. We're tracking as #5428, and will let you know when fixed.

https://github.com/orbeon/orbeon-forms/issues/5428

-Alex

[Alessandro Vernet]

Hi John,

Just a quick update on this one: #5428 is now fixed, and will be in 2022.1, as well as the upcoming 2021.1.5.

-Alex