Thursday, February 10, 2011

XPages: RichTextEditor + custom partial refresh + validation error = lost content

I ran into a problem today with content disappearing from a rich text editor when there was a validation error/saving. I did a little investigation, and it turns out that the RichTextEditor has a submitListener that updates a hidden field. This hidden field is used by the server to set the field/scope value on the server (at least it looks that way).

When my custom partial refresh ran, the hidden field didn't have a value. When combined with a validation error, this resulted in an empy RichTextEditor after refresh.

To work around this problem, I run the code (CSJS) below before running any "custom" partial refreshes:
// Process any autogenerated submit listeners
if( XSP._processListeners ){ // Not sure if this is valid in all versions of XPages
 XSP._processListeners( XSP.querySubmitListeners, document.forms[0].id );
}
This code won't work if you have multiple forms. Then you'd have to write a loop that calls the method once per form.

6 comments:

Erik Brooks said...

Ew, what a nasty bug. There have been some recent fixes revolving around RichTextEditors near this area.

What version of XPages/Domino was this? Have you reported it as a bug?

Tommy Valand said...

This was on Domino 8.5.2. I haven't reported is a bug. The reason is mostly because my previous attempts at reporting bugs have been disappointing/felt like a waste of time.

If reporting Domino bugs was as simple as reporting bugs in the XPages Extension Library, I would gladly do it.

Paul Hannan | IBM said...

The issue surrounding validation and the rich text editor has been around for a while both in the Dojo Editor (per-852) and the CKEditor (852+). The server side validation issue is a 3rd party bug and client side issue (DEGN8B5HHM) is open but this won't be addressed in the 85x timeframe (that is unless its severity weight increases).


What more concerning is the data loss. Could you provide more detail as to how this is arising?

Also, if you or your customer has a support contract I would encourage you to call this or any issue you may have in with them. If the issue is valid we can then set about channelling a hotfix, if possible, for that issue.

p.

mark said...

Loss of data can depends on what you put in a custom validate expression, for example this causes loss of data

try {
if (currentDocument.getItemValueInteger("Status") >= 2) {
return true;
} else {
return /(\b[a-z0-9]+\b.*){10,}/i.test(value);
}
} catch (e) {
print (e);
}

So you can re-write the expression or in this case I used the validate length method - not as nice but at least it doesn't lose data!

Girth said...

We have an application where the users are constantly reporting data loss on RTF fields, and it appears that the loss happens randomly when submitting and there is a validation problem.

The difference with my app I think is that none of the fields have validation defined on the XPage itself. The workflow buttons are type Button (not submit) and they do a full update. The SSJS that runs calls a custom querySave function that validates the document. If that returns true, currentDocument.save() is called. This type of save doesn't fire the querySave and postSave events on the data source, a feature I am exploiting because I don't want certain things in the actual PostSave event to run. If the currentDocument.save() call returns true, the custom postSave function for workflow is called.

This all works nicely except when there is a problems (sometimes) and the RTF field loses it's value. You say in your post that the code should be called before any "custom" refreshes - would you put this at the start of the SSJS code before the custom querySave and postSave are run? Thanks

Tommy Valand said...

The code snippet I posted is client side (I'll update the post), so you should run it when the page loads/in CSJS.