logo

Testing for JavaScript Support in WQS Agents

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.

Another requirement of the system was that it worked in browsers with no JavaScript support. This is where I hit a snag.

The Problem:

What if the user has no JavaScript? Well, most obviously, the editor itself won't load. We can simulate this using the IE Developer Bar. In the shot below I have disabled Script. As you can see the message field is now a plain textarea element.

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.

The Solution:

What I needed was a way to tell if the browser had JavaScript enabled or not. If the browser supports script the code goes ahread and marks the whole Body field as Passthru. If JavaScript isn't enabled the code doesn't run and the field is stored as standard Rich Text format.

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.

The noscript tag only shows its content to browsers that don't support JavaScript. For example, the following HTML would tell users of non-JavaScript browser what they probably already know:

<noscript>
 <p>Your browser does <strong>not</strong> support script.</p>
</noscript>

Users of more up-to-date browsers will see nothing.

So, on my form I added a hidden CFD field called "JavaScript" which computed to itself (a "temp" field, if you will), like the one below:

Then I added the following PassThru HTML directly to the form.

<noscript>
 <input type="hidden" name="JavaScript" value="Off" />
</noscript>

Can you see what it does?

This "JavaScript" field is hidden on two levels. Firstly it's hidden from the reader - always - who will never see anything. Secondly it's hidden from the actual Form depending on the browser's capabilities. When JavaScript is enabled the field is not sent to the server. If JavaScript is disabled the <noscript> element makes its content available to the Form and, when it's posted, the server receives a value of "Off". This is illustrated below (using HTTPWatch).

First, here's the data POSTed to the server when JavaScript is enabled:

Look at the bottom pane. There you'll see the Parameter/Value pairs for each field being sent. In this case only two fields are sent - Title and Body (we'll ignore Query). Now, here's the data POSTed to the server when JavaScript is disabled:

Notice the extra field called JavaScript, which has a value of "off"? The fact that this name/value pair is being sent to the server is our signal that JavaScript is not supported.

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:

If vWebDocument.JavaScript(0)="" Then 'script enabled
 Call ConvertRTtoHTML( vWebDocument, "Body" )   
End If

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.

Summary:

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.

Feedback

  1. A nice idea

    Hy Jake,

    it s a very nice trick, thanks for that :-)

    But, would it be "notes nativer" if we use @Browserinfo for that?

      • avatar
      • Jake
      • Sun 19 Feb 2006

      Re: A nice idea

      @Browserinfo("JavaScript")?!

      I honestly had no idea about that. I've never used the @Browserinfo function. Is it reliable?

      This would still need a field to store the result and pass it to the server though. Horses for courses I guess.

      Jake

      Hide the rest of this thread

      1. Re: A nice idea

        @BrowserInfo does evaluate the User Agent String. So it will report (for known browsers) what they can support, but not what is actually enabled. Jake's noScript Tag approach works better. :-) stw

          • avatar
          • Jake
          • Mon 20 Feb 2006

          Re: A nice idea

          That's what I'd have thought. I was thinking about it last night and couldn't figure out how the server could compute this without the browser passing it some extra information.

          I'm glad this isn't the case as it took a couple of hours to write that article and there's nothing worse than having it nullified by one simple line of code.

          I just tested @BrowserInfo("JavaScript") and it still equates to "true" (1) when JS is disabled, which makes it pretty useless really.

    • avatar
    • Kapali
    • Mon 27 Feb 2006

    no script tag

    This link also talks about no script tag for the same purpose. The article appears to be old (2001), so not sure if better methods exist to solve the same problem:

    http://www.jamesshuggins.com/h/rng1/wdc-non-javascript.htm

  2. ConvertRTtoHTML

    I'm not familiar with this call, is it part of Domino 6.5 or 7 ??? I'm currently moving a Domino 5 server to Domino 6.5 and the customer has a corporate policy database that has alot of Rich Text Fields. I'd love to convert them to HTML and store in text fields and use the HTMLArea you spoke of in a previous article..

      • avatar
      • Jake
      • Tue 28 Mar 2006

      Re: ConvertRTtoHTML

      Brad. That call is just to a sub routine where I put the code from the other article.

Your Comments

Name:
E-mail:
(optional)
Website:
(optional)
Comment:


Navigate other articles in the category "Forms"

« Previous Article Next Article »
Appending Rich Text Edits   Drag-n-Drop Sorting of Documents

About This Article

Author: Jake Howlett
Category: Forms
Keywords: JavaScript; noscript; rich text;

Options

Feedback
Print Friendly

Let's Get Social


About This Website

CodeStore is all about web development. Concentrating on Lotus Domino, ASP.NET, Flex, SharePoint and all things internet.

Your host is Jake Howlett who runs his own web development company called Rockall Design and is always on the lookout for new and interesting work to do.

You can find me on Twitter and on Linked In.

Read more about this site »