Posted by
Alessandro Vernet on
Oct 16, 2009; 5:57pm
URL: https://discuss.orbeon.com/A-problem-with-unnecessary-xforms-value-changed-after-replace-instance-submission-and-one-more-thing-tp252592p252965.html
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.
> 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.
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.
> 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.
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-layoutAlex
--
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
--
Follow Orbeon on Twitter: @orbeon
Follow me on Twitter: @avernet