new type of RT field rendering for standard Web forms still isn’t working for me in 8.5 GOLD release:entering some data into the editor using Firefox 3.x results in a “MIME” field instead of an expected RT field when looking at it from the Notes client.
Can someone please confirm that this still is a bug (or otherwise tell me that it’s working on your side?)
Thanks,
-Lothar
Subject: Additional info:
meanwhile we did some more testing:
the behaviour is the same for various installations in our company, so it’s not a local problem on my machine / installation
the problem obviously only occurs if we submit the web form using plain JavaScript, i.e. using
document.forms[0].submit()
@Command([FileSave])
the RT field’s content is saved alright!
Subject: This is know Bug in Domino 8.5.3 onward server
http://www-01.ibm.com/support/docview.wss?uid=swg1LO72515
This bug is in 8.5.3.
The temp fix is to create a hidden submit button like below.
and use this code (“document.getElementById(“hiddenSubmit”).click();”) instead of (“document.forms[0].submit();”).
Subject: working as designed
8.5 adds a Dojo editor to the choices for rendering Domino rich text. (The other choices are HTML, Java Applet, and DHTML in IE on pre-Vista windows - which the designer calls ‘Best Fit for OS’).
All display rich text that has been converted to HTML from the MIME generated by the converters Domino would use to send out internet email. (If the rich text was stored as MIME, those converters have an easy job.)
When saving a document on the web, all those renderers return their HTML to the Domino web server, which needs to do only minimal conversion to make it MIME that can be saved as if it were an in-coming internet email.
So it is expected that the storage type of rich text saved from the web will be MIME.
With the new XPage conversion of MIME to HTML we made a different set of rendering trade-offs - perhaps they would be more to your liking? It’s still stored as MIME though.
Subject: I think you got me wrong
sorry, I can’t believe that this is intended, so I guess you got me wrong:
create a RT field on a standard Notes form and set it to use the new Dojo rendering; also create a JavaScript .submit()-button
create a new doc using that form from Firefox3 and enter some (formatted) ionfo into the dojo RT field
submit the form
look at the newly created doc using your Notes client
Result: there’s no RT content at all!
Result: no RT content at all
Tested in several machines using 8.5 Gold…
Subject: IIRC…
… there’s a Dojo method that needs to be called prior to the JS submit() call. Whether Domino should be putting that in the onSubmit() function (or more correctly, instantiating the appropriate Dojo.addOnSubmit() call) is another question.
Or perhaps instead of calling submit() directly, you should be calling Dojo.submit() or the equivalent?
Subject: You’re right - that’s a bug
Could you send me the JavaScript you used on your button - I’ll use that to reproduce the problem and spr it.
Subject: as simple as can be…
in my testing environment it’s just a plain
document.forms[0].submit();
nothing more.
(sort of relieved that it’s not just in my environment…)
Subject: Try this please
could you use a text editor to add the bolded text to your server’s data\domino\template\dojo-1.1.1\dom_richtext.htm file? You will need to restart http to get it to take effect - please let me know if this works!
&DOMINO_CTRL_HEAD;
&DOMINO_CTRL_INCLUDE;dom_common.htm&DOMINO_CTRL_INCLUDE_END;
&DOMINO_CTRL_HEAD_END; &DOMINO_CTRL_FLD_INIT_END;You will also need to add a call to GetJSEditorData() just before your call to submit:
GetJSEditorData();
document.forms[0].submit();
If this works for you (as it does for me) I will submit it to 8.5.1
Subject: Partial success
Hi,just tried adding your code lines, then restarted my server (it’s a testing machine anyways).
Fact is that, if I just enter plain text into the rt editor it now comes out as planned. These are the body field’s properties then:
Field Name: Body
Data Type: MIME Part
Data Length: 137 bytes
Seq Num: 1
Dup Item ID: 0
Field Flags: SIGN SEAL
"MIME-Version: 1.0
Content-Transfer-Encoding: binary
Content-Type: text/html; charset=UTF-8
-áAnother test
"
If however I add some formatting to my text entered into the rt editor (no matter which: underline, bold,…) then the content is lost again:
Field Name: Body
Data Type: MIME Part
Data Length: 101 bytes
Seq Num: 1
Dup Item ID: 0
Field Flags: SIGN SEAL
"MIME-Version: 1.0
Content-Transfer-Encoding: binary
Content-Type: text/html
"
No content, no charset setting…
Subject: Strange!
Thanks for the fast help - wish I could get such prompt turnaround internally!!
The changes work for me - at least in IE and Firefox - and I can’t think of a good reason why the html formatting tags (, etc.) inserted into the rich text by the rich text editor would break the post and just plain text would not.
Perhaps clearing your browser cache might help - esp. if you are mixing web preview of any local database and accessing databases on a Domino server. (using Dojo source vs. Dojo layers, respectively)
You could always try sticking an alert() into the GetJSEditorData() code to confirm that the data did make it out of the rich text editor into the form variable. If the data does get there, perhaps the form is failing later validation, or being posted twice?
Subject: Works now in a fresh form - at least partly; some issues remain
Hi,created a fresh test form this morning, and now most of your enhanced code seems to be working as planned. A few issues are remaining, though:
each RT field content starts with a space
If I format characters to have maximum font size but don’t set a font-family they finally turn out to be a serif type font, whereas at editing time they appear to be sans-serif. Or, in other words: if the editor’s default appearance is sans-serif then this should be stored if not altered.
worst thing: if I start the RT field’s content with XXL-size characters the content is gone again after submitting
Hope this helps…
Edit:
everything above applies to Firefox 3; using MSIE7 it’s a bit different again:
if I set focus to the body field the “font” and “size” comboboxes are populated with their default values being “arial” in MSIE; this is not the case in Firefox, where both boxes remain empty. I however have to switch to a specified font-familiy other than Arial in both environments, otherwise the result will be formatted as a serif font
working in MSIE7 the body contents are stored correctly (apart from the font-family issue); in Firefox however it’s now broken again :-((
I identified that extra space in front of the first character as a space that obviously has been inserted upon creation of the body field: create a new doc with ?OpenForm, then look into the body field: the leading space is there already…
Subject: Good - Thanks!
We’ll tackle those new issues next. Some of them are already reported as bugs against Dojo, like that leading space, and we’re hoping they will be fixed with their next release!
Subject: Just for info: tested again in 8.5.1 CD5
Everythings appears to be working now in both FF and IE7 (haven’t installed IE8 on my test VM yet). Well, the leading space is still there, but that’s a true minor in my opinion…
Thanks all.