By now you are probably all familiar with using rich text editors with Domino. It's almost 2 years since I first talked about it, so I'm guessing you've all seen them used with Notes Rich Text fields by now and are aware of the methods involved. It's a technique I've used more than a few times on projects since I discovered these handy little editor plugins. I almost take them for granted. Until recently that is.
Not long back I was working on a "feedback" form for a website. The clients wanted a basic rich text editor for the Message/Body field. Simple enough. Something like this:
The message field is a a standard Notes Rich Text field and saved as Passthru HTML in the backend document.
All is not lost. The form still works, but the user has a limited experience (something they are probably used to having such a backward browser).
However, there's more to it than this. If you studied the LotusScript code involved in my approach to using these editors with Domino you'll have noticed it works by marking the whole content of the field as Passthru HTML. This works fine when the editor is running as it renders news lines using P elements. However, without the editor new lines get stored in the field, but, as it's marked as Passthru HTML they don't render back to the browser in read mode. Therein lies the problem. For a normal Rich Text field with line breaks Domino will render BR tags in their place when sending the field contents to the browser. When we mark the whole field as Passthru Domino doesn't bother with the BR tags and it doesn't look like the user intended it to.
At first I'd thought this would be straight-forward and expected there'd be a CGI variable or something to tell me if JS was supported. After some quick searching I couldn't find anything. While I'm still sure there must be an easier way I came up with the following simple solution using nothing but the <noscript> tag.
<noscript> <p>Your browser does <strong>not</strong> support script.</p> </noscript>
Users of more up-to-date browsers will see nothing.
Then I added the following PassThru HTML directly to the form.
Can you see what it does?
In our WQS Agent it's then a simple case of testing the field's value. If it has any value at all then it must of "Off" and we know the browser has JS disabled. On the flip side we know that no value means the field is missing and that we can go ahead and assume support for script. The code looks something like:
In this case the field is marked as PassThru only if scripting is supported. Otherwise the WQS agent does nothing and the field is stored as normal RT format.
It's odd that I've been a developer for so long and never considered how I would check for browser script support in an Agent. Now that I have I find myself thinking of other ways it might be useful. E.g: A browser with no script probably can't validate form input, so we'd know to try and do it server-side instead.
Hopefully you'll find some use in this and I'm not going to feel stupid when somebody tells me there's an even simpler alternative. If nothing else it's food for thought and shows yet another trick we can use as developers.