A problem with unnecessary xforms-value-changed after replace="instance" submission and one more thing

Hello everyone,

I've been wondering if you could help me with a problem I've
encountered. The system I'm working on provides a simple facility to
save the content of the current form using a submission. The submission
is a replace="instance" submission, its PFC-based backend makes some
(small) data modifications and returns the altered version back to the
form. In order to simplify the considerations I've forged a mock form
with a mock GET submission to a static file, the same file which is the
default value of the instance. This submission mocks my "save submission".

The problem is that even if the data returned from the submission is
exactly the same as the data sent (which is the case of my test form),
the xforms-value-changed is triggered and an event handler subscribed to
xforms-value-changed event and placed withing a control bound to data
that hasn't changed get fired. Is it a correct behaviour? If it is - can
I suppress xforms-value-changed after the submission? If it's not - will
it be fixed? It is easy to reproduce this problem with a form I've
uploaded here: http://gamma.mini.pw.edu.pl/~arciuchm/esp.xhtml (it works
in XForms Sandbox). Why does the popup appear?

So far I've solved the problem by making my submission replace="none"
and triggering an ugly JavaScript redirect upond xforms-submit-done. Is
there any better solution? I've browsed the archives searching for a
clear answer, but I couldn't find a definitive answer to my problem. If
I've missed something, I apologize and please point me to it.

The second problem is that the form's HTML file contains a meta field
(<meta> something </meta>, which shouldn't be displayed, but after
Orbeon transformations the meta tag get opened (see the top). How can I
fix it?

Thanks in advance,
--
Maciej Arciuch
programista
tel. +48 22 564 2482


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

The previous mail I've sent got somehow corrupted, here I repost it using Nabble, I'm sorry for inconvenience and here it is again:

I've been wondering if you could help me with a problem I've
encountered. The system I'm working on provides a simple facility to
save the content of the current form using a submission. The submission
is a replace="instance" submission, its PFC-based backend makes some
(small) data modifications and returns the altered version back to the
form. In order to simplify the considerations I've forged a mock form
with a mock GET submission to a static file, the same file which is the
default value of the instance. This submission mocks my "save submission".

The problem is that even if the data returned from the submission is
exactly the same as the data sent (which is the case of my test form),
the xforms-value-changed is triggered and an event handler subscribed to
xforms-value-changed event and placed within a control bound to data
that hasn't changed gets fired. Is it a correct behaviour? If it is - can
I suppress xforms-value-changed after the submission? If it's not - will
it be fixed? It is easy to reproduce this problem with a form I've
uploaded here: http://gamma.mini.pw.edu.pl/~arciuchm/esp.xhtml (it works
in XForms Sandbox). Why does the popup appear?

So far I've solved the problem by making my submission replace="none"
and triggering an ugly JavaScript redirect upon xforms-submit-done. Is
there any better solution? I've browsed the archives searching for a
clear answer, but I couldn't find a definitive answer to my problem. If
I've missed something, I apologize and please point me to it.

The second problem is that the form's HTML file contains a meta field
(<meta> something </meta>), which shouldn't be displayed, but after
Orbeon transformations the meta tag get opened (see the top). How can I
fix it?

Thanks in advance,
Maciek

Maciej,

2009/10/14 Maciej Arciuch <[hidden email]>:
> The problem is that even if the data returned from the submission is exactly
> the same as the data sent (which is the case of my test form), the
> xforms-value-changed is triggered and an event handler subscribed to
> xforms-value-changed event and placed withing a control bound to data that
> hasn't changed get fired. Is it a correct behaviour?

It is the correct behavior according to the XForms specification, but
we don't think it should. We have a proposal to change this, which we
will be discussing at the XForms WG
(http://wiki.orbeon.com/forms/doc/developer-guide/xforms-refresh-events),
and which hopefully, in some form or another, will make it  into the
XForms specification.

In the meantime, we took the liberty of implementing this the way we
think it should be done, and the way you expected it to work. Those
changes are very recent and haven't made it yet to the "master"
nightly builds we publish. If you are interested, you can test this in
this build: http://forge.objectweb.org/nightlybuilds/ops/ops/orbeon-development.war.
The changes should make it to the nightly builds in the next few
weeks.

> So far I've solved the problem by making my submission replace="none" and
> triggering an ugly JavaScript redirect upond xforms-submit-done.

If you are not interested in the result, i.e. if it is always the same
as what you send, you should indeed use replace="none". But I am not
sure why you need to run JavaScript on xforms-submit-done. What does
the JavaScript do?

> The second problem is that the form's HTML file contains a meta field
> (<meta> something </meta>, which shouldn't be displayed, but after Orbeon
> transformations the meta tag get opened (see the top). How can I fix it?

The HTML converter produces some unexpected output with the text you
have inside the meta element, because you are not supposed to have any
content there (http://www.w3.org/TR/html5/semantics.html#meta).
Instead of:

<meta property="description">META VALUE WHICH SHOULDN'T BE VISIBLE</meta>

Try:

<meta property="description" content="META VALUE WHICH SHOULDN'T BE VISIBLE"/>

Alex
--
Orbeon Forms - Web forms, open-source, for the Enterprise
Orbeon's Blog: http://www.orbeon.com/blog/
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

Alessandro Vernet wrote

we took the liberty of implementing this the way we
think it should be done, and the way you expected it to work. Those
changes are very recent and haven't made it yet to the "master"
nightly builds we publish. [...]
The changes should make it to the nightly builds in the next few
weeks.

I will check it out immediately. Are these builds made of a separate branch? Could you tell me where are the relevant changes located? How can I know that it is already in the "<<master>> nightbuilds"?

Alessandro Vernet wrote

If you are not interested in the result, i.e. if it is always the same
as what you send, you should indeed use replace="none". But I am not
sure why you need to run JavaScript on xforms-submit-done. What does
the JavaScript do?

Unfortunately in the real life the data is changed a bit during the saving process and as for now I need to get this data back to the form. My system consists of two main XPL-pipelines. The first one is the "reading pipeline" which obtains the form, its content from the database, decorates and present to the user. The second one is the "saving pipeline" which is intended to persist the instance data. So, AFAIK I have two options. First option is to enter the "reading pipeline" only once, then let the user work with the document and use a replace="instance" saving submission to persist the data and receive the modified data back to the form in a Ajax-like way. This will hopefully work with your bleeding-edge build. Alternatively, I can just make my saving submission replace="none" and in order to get my altered data back - issue a JS reload resulting in entering the "reading pipeline" again. The second option seems ugly to me, but guess what - it's how it is done now. I'd like to improve the system, so that's why in so interested in more clever changes detection.

Alessandro Vernet wrote

The HTML converter produces some unexpected output with the text you
have inside the meta element, because you are not supposed to have any
content there (http://www.w3.org/TR/html5/semantics.html#meta).

Right. Funny thing is that when the tag is called e.g. <mymeta> its contents don't show up. Does the HTML converter use a JTidy or something similar? Another thing is that in Orbeon 3.6 the tag content didn't show up either. But anyway, my code is incorrect and I will happily fix it. Thanks.

As regards the changes of behaviour, let me ask you one more small question. In the 3.7.1 release notes you write: "Previous versions of Orbeon Forms displayed an alert icon and message (if provided) only if the value associated with the control was invalid. Orbeon Forms now by default shows the control in alert state when the value is invalid, but also when it is required but empty. ". Can I somehow restore the old behaviour which resulted in a alert exclamation icon even if the was no <xf:alert> element explicitely put in the inside the <xf:input>? The problem is that my clients are reluctant to the change their forms and if we switch to the new Orbeon version they will start complaining about "broken validation", although they could simply add a red background to xforms-invalid class.

Thank you for quick response,
Maciek

Alessandro Vernet wrote

If you are interested, you can test this in
this build: http://forge.objectweb.org/nightlybuilds/ops/ops/orbeon-development.war.

It worked like a charm on my local Tomcat, but the WebSphere 6.0 (which is used in the production environment) failed to run the development WAR, because it's been probably compiled for Java 1.5 (it seems that 3.7.1 package was 1.4-compatible - am I right?) - WebSphere complaints about unsupported class file version 49.0.

Where can I get the sources for this bleeding-edge version so that I can recompile it myself for 1.4?

Thanks, Maciek

Maciej,

On Fri, Oct 16, 2009 at 1:06 AM, Maciej Arciuch
<[hidden email]> wrote:
> I will check it out immediately. Are these builds made of a separate branch?
> Could you tell me where are the relevant changes located?

Yes, they are made off a separate branch we created to do some risky
changes, which we didn't want to go into nightly builds right away.
We'll most likely post something on Twitter as @orbeon
(http://twitter.com/orbeon) when those changes make it to regular
nightly builds, so you might want to follow @orbeon, if you are not
already doing so.

> How can I know that it is already in the "<<master>> nightbuilds"?

The changes for this are "all over the place" in the Java code, which
has been refactored quite a bit. So this is not a simple change that
you can easily reapply on a version you would be using.
I see. Another option, with the current code, is to "set a flag"
(store in an element <submission-in-progress> of an  instance "true"
instead of "false") before you do the <xforms:send>. Then on
xforms-submit-done you reset the flag, and in xforms-value-changed,
you don't do anything if the flag is set. Or you can keep the JS you
have now, if it works, and switch to a nightly build a few weeks from
now once we merged those changes back into the master branch.

> Right. Funny thing is that when the tag is called e.g. <mymeta> its contents
> don't show up. Does the HTML converter use a JTidy or something similar?
> Another thing is that in Orbeon 3.6 the tag content didn't show up either.
> But anyway, my code is incorrect and I will happily fix it. Thanks.

The HTML converter does the opposite of what JTidy does: generate HTML
from XHTML. We use code in Saxon for this, and I assume it is some
code in Saxon that exhibits this behavior.
Yes, you can.

When you put an <xforms:alert>Fix this!</xforms:alert>, "next" to the
input you'll have a <span> (used to be a <label>) that contains the
message ("Fix this!"). It has the class xforms-alert, and
xforms-alert-active when it is "active". You can use those classes to
style the alert message. For instance you can hide the text of the
message and show an alert icon (like in the XForms Controls example)
or show the message below the field it is invalid (like in Form
Builder).

Now if you just want to have the border of the field in red when
invalid, you can ignore everything about the <xforms:alert/>, and use
the class xforms-invalid which is put on the control when invalid. I'd
recommend you look at what the DOM looks like exactly with Firebug.
You can also find more about what the HTML looks like, which is
important when you write CSS:

http://wiki.orbeon.com/forms/doc/developer-guide/html-layout

Alex
--
Orbeon Forms - Web forms, open-source, for the Enterprise
Orbeon's Blog: http://www.orbeon.com/blog/
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

Maciej,

On Fri, Oct 16, 2009 at 6:32 AM, Maciej Arciuch
<[hidden email]> wrote:
> It worked like a charm on my local Tomcat, but the WebSphere 6.0 (which is
> used in the production environment) failed to run the development WAR,
> because it's been probably compiled for Java 1.5 (it seems that 3.7.1
> package was 1.4-compatible - am I right?) - WebSphere complaints about
> unsupported class file version 49.0.

Yes, we made the switch, and recently started using Java 5 features in
the code. <sarcastic>5 years after it was released! ;)</sarcastic>
More seriously, new versions of both Saxon and eXist, two products we
heavily rely on, will require Java 5. (For Saxon starting with 9.x,
and for eXist starting with 1.4.) So our own code requiring Java 5
won't add any new requirement as the libraries we will us already
require Java 5. We haven't upgraded to those versions of eXist and
Saxon yet, so you might be OK with just recompiling the code.

> Where can I get the sources for this bleeding-edge version so that I can
> recompile it myself for 1.4?

Here:

http://github.com/orbeon/orbeon-forms/tree/development

Alex
--
Orbeon Forms - Web forms, open-source, for the Enterprise
Orbeon's Blog: http://www.orbeon.com/blog/
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

Alessandro Vernet wrote

I see. Another option, with the current code, is to "set a flag"
(store in an element <submission-in-progress> of an  instance "true"
instead of "false") before you do the <xforms:send>. Then on
xforms-submit-done you reset the flag, and in xforms-value-changed,
you don't do anything if the flag is set.

I've tried to solve my problem like this, but my attempts failed, because xforms-submit-done is sent before the RRRR (refresh - which causes undesired xforms-value-changed, rebuild, recalculate, revalidate), so the resetting happend too early. Is there any event that marks "the end of submission and of all of its consequences" (RRRR)? I attach an excerpt from my event log here: http://gamma.mini.pw.edu.pl/~arciuchm/log.txt

This would be perfect place to place a trigger resetting another flag, the "dirty" flag (a flag that informs that the document has been modified after last save).

Anyways, huge thanks for providing me with the development build, Maciek

Maciej,

You could also try to force an RRRR in the xforms-submit-done:

<xforms:action ev:event="xforms-submit-done">
    <xforms:rebuild/>
    <xforms:recalculate/>
    <xforms:revalidate/>
    <xforms:refresh/>
    ...
</xforms:action>

-Erik

On Mon, Oct 19, 2009 at 1:02 AM, Maciej Arciuch
<[hidden email]> wrote:

--
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 Bruchez-3 wrote

You could also try to force an RRRR in the xforms-submit-done:
<xforms:action ev:event="xforms-submit-done">
    <xforms:rebuild/>
    <xforms:recalculate/>
    <xforms:revalidate/>
    <xforms:refresh/>
    ...
</xforms:action>

Thanks, that did the trick! It solved my "dirty form detection" problem (xforms-submit-done is finally marks the end of submission and of events it triggers), as well as the problem of unnecessary xforms-value-changes: I raise a flag on xforms-submit, cancel it on xforms-submit-done and use XSLT transform which adds an "if" condition blocking the execution of xforms-value-changed handlers when the flag is on.

If anyone has experienced the same problem - this might be the solution.

Nevertheless I'm eagerly waiting for the inclusion of the xforms-value-changed handling into the main tree.

Best wishes, Maciek