Posted by Maciej Arciuch on Oct 16, 2009; 8:06am
URL: https://discuss.orbeon.com/A-problem-with-unnecessary-xforms-value-changed-after-replace-instance-submission-and-one-more-thing-tp252592p252898.html

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