Back in April '06 I talked about the bug in Domino whereby it inserts "random paragraph breaks". When using one of the many WYSIWYG HTML editors to edit documents there was a potential problem in that Domino could insert its own carriage returns at any point in your HTML. If this happens to be inside an HTML tag then you're likely to get some garbled, badly-formatted output.

The solution at the time seemed to be an upgrade to 6.5.5. It worked for me and I've not suffered the same problem since. Until yesterday that is. This time the server was 7.0.2 and the same "regression bug" appears to be back. Although I'm not 100% certain it's the exact same bug it's still a problem and so a solution is needed regardless of what the actual cause is.

In my case the editor in question was TinyMCE and the problem was Domino breaking the HTML in the wrong place. The trouble seems to be that TinyMCE sends the whole of the HTML you've written to the server as one long unbroken string. Domino doesn't like this and so breaks it in to chunks after every 16,000th character or so.

To stop this happening we need to stop TinyMCE sending one long line of text and break it up in a sensible manner before Domino gets the chance to.

The solution was suggested in the comments to that original post by, amongst others, Patrick Niland. His idea was to use the save_callback method of the editor to alter the HTML before it gets posted. The solution is worthy of its own posting instead of being hidden in the comments back there.

Here's an example of the JavaScript needed on a form that uses the editor and demonstrates how you can use regular expressions to split the HTML:

tinyMCE.init({ mode: "exact", elements: "Body", //Lots of other options here save_callback: "addNewLinesForDomino"
}) function addNewLinesForDomino(element_id, html, body){ return html.replace(/(\<\/(div|h[1-6]{1}|p|ol|ul|pre)\>)/gi, "$1\n");
}

What this does is tell the TinyMCE editor to call the function "addNewLinesForDomino" before the form is submitted to the server. When the function runs it adds a new line after all the common block-level elements that might appear in the HTML. Not only does this prevent problems at the server it also lends itself to much tidier looking code in the source.

If nothing else it's a nice example of the power of Regular Expressions. Does that part make sense? Hands up if not and I'll explain.

If you use TinyMCE with Domino add this fix now.

I bet that title got your attention. You weirdo.

I'm sure we've all got words we seem to type consistently wrongly. For me it's the word busy (a word I've been using in emails more and more of late), which I always seem to type busty (maybe because of the proximity of the T to the Y on the keyboard). The result is emails that start something like:

Sorry about the late reply. I am very busty at the moment.

Luckily I manage to trap most of the typos as I very rarely send an email without re-reading it first (especially those of a business nature). Whenever I correct this typo I always chuckle to myself at the mental picture of having breasts so large it's hard to send emails.

Out of curiosity I just did a search on my sent items folder for "busty" and it's worrying how many times I've let the typo slip through. I just hope the people who received the email saw the funny side and/or knew it was a typo.

Another typo I seem to keep making is leaving the C out of onclick when adding JavaScript to HTML elements. Wondering why the event doesn't fire I return the HTML to see I've added an onlick event. That too makes me laugh to myself as I imagine somebody licking their screen (you have to find amusement somewhere when working alone for so long in an office).

onlick="alert('Stop licking the screen you weirdo!')"

Any of you lot have any funny typos you keep making?

A large amount of any developer's time is spent testing. Well, hopefully that's the case. It's true for me at least.

Testing is tedious and boring. Anything that can make it less of a hassle is a godsend. Hopefully this tip will help you out if you do a lot of testing where you need to continuously login and out as different users. I know it's helped me no end since I started doing it.

I don't know how I managed to remain sane before I switched to this technique.

The Problem

When you setup a new Domino server, enable session-based authentication and then create the domcfg.nsf database you will see this screen when you're required to login:

Apart from looking butt-ugly there's not much wrong with this per se. It works. I wouldn't ever use it on a live site but it normally suffices for the development server.

The problem is when you're doing intensive testing and logging in/out every couple of minutes. You soon get tired of having to type in the name/password of the test user every time.

This is made all the worse by the fact that the default login form that comes with domcfg.nsf has autocomplete="off" in the username and password fields. The means that b won't offer to remember passwords for the form.

You're forced to type the name and password of the user every time even if you use a browser which is able to store them.

The Solution

One solution is to remove the autocomplete attribute from the fields on the $$LoginUserForm and let your browser store the passwords.

However, even with the browser auto-completing the fields it still requires keyboard use and takes longer than it needs to. What I'm after is the quickest way possible to switch from one user to another.

Before I describe my solution let's make the following assumptions:

1. You test on a machine given over primarily to development and testing alone.
2. You "own" the server and can make any changes you like to its configuration.
3. It's not generally accessed by "normal" users.
4. The NAB on the sever contains a set of test users, all of whom have the same HTTP password.
5. These test users' credentials can't be used to access any sensitive date elsewhere.

If most of the above are true then why not hard code the usernames and password in to the login form?! Here's what the form could look like:

All you need to do here is change the dropdown to the user you want to login as and press "sign in" (password has already been pre-filled at the server).

Although I lived with this for a couple of days and it was a massive improvement over the original form I still felt it could be simpler and quicker to use. What I came up with is possibly as simple as a multi-user login form could get:

When required to login all you have to do is press the button with the name of the required user on it. Couldn't get much simpler than that. No need to worry about the password as it's pre-filled and hidden using type="hidden".

How Does It Work

This technique makes use of the fact that the humble submit button is nothing more than an input field, which you can give a name and which is submitted with the form as a name/value pair, just like an ordinary field. In this case I've called the button "Username" and removed the actual "username" field from the login form.

The other trick used is that you can have multiple inputs of the same name. When there are lotus of submit buttons with the same name it's the one pressed which sends its value (the text displayed on the button) to the server as the field value. Make sense? The HTML looks something like this:

<td><input type="submit" name="UserName" value="Jordan Quinones"></td>
<td><input type="submit" name="UserName" value="Keith Moore"></td>
<td><input type="submit" name="UserName" value="Margarito Yarbrough"></td>

Simple! To create the HTML for these buttons all we need is a simple Computed Value on the form. The formula for which is along the lines of:

names:=@Trim(@Sort(
"Administrator":"Deandre Hoyt":"Caitlin Hudson":"Allie Jarrett":"Charlie Jacobson":
"Reyna McCarthy":"Eliza Mayo":"Dick Mayfield":"Keith Moore":
"Jordan Quinones":"Alexander Welch":"Margarito Yarbrough":"":""
)); @Implode("<input type=\"submit\" name=\"UserName\" value=\""+names+"\">"; @NewLine);

In the form I showed you I've used a formula to put them in a nicely-laid-out table though. Download the demo database to see how.

As you can see I've used a hard-coded set of usernames taken at random from the "fakenames" NAB, which I use on most test servers and which contains 40,000 users all with the password of "password".

If your test server's NAB is more normal and just has a handful of "Test One", "Test Two" users then you could even have the formula above do a lookup to get all the usernames for you. For me a handful of users normally suffices.

Download

If you want to use this method in your dev environment then download the modified version of domcfg.nsf now and copy the $$LoginForm over. What will you do with al the time you save...

If I do a rough poll in my head of all of my customers - both past and present  - they all run their Domino servers on Windows. Every application I've developed has been deployed on Windows. None (that I can think of right now) have ever ended up on Linux or any other OS for that matter.

I'm guessing the same can be said of most companies? Whereas hosted Domino servers, such as this one, primarily run on Linux I'm guessing that servers owned, hosted and maintained by the company whose applications it runs are more often than not Windows-based.

Maybe I'm wrong? Let's see. Here's a quick survey to find out what most Domino servers run on:

What does the company you work for run their Domino servers on?

Why am I asking? More on that tomorrow.

Yesterday I asked what server you run Domino on. The result, which is still coming in but unlikely to change significantly, was that an unsurprising majority of you use Windows.

Look again at the chart above. Notice the chart is embedded in a PDF? Look now at the URL. It's a PDF document attached to a Notes document. Both the PDF and the chart within it are generated on-the-fly by a Java WQS agent. Here's the actual PDF generated, which weighs in at a mere 3kb!

The idea is that the survey document has a button on it which you press to have a PDF snapshot of the survey results sent to your email address. The button is hidden at the moment!

This brings me rather nicely to the point of the question itself. The Java code I've written to generate the PDF only runs on Windows. Well, hang on, that's not exactly true. Because the agent generates images it will only run on servers with a "graphics environment". It can run on Linux et al but only if X11 or a similar graphics library is available.

This is the first time in codestore's history that I've produced a demo (a nice one at that, which I'm keen to show off and make available) that I can't actually demo to you. This is because codestore runs on Linux in "headless" mode. There's no graphical interface to the server. The Java code can't create graphics.

At the point I realised this I set about trying to find a way to work round the fact I was being restricted by the OS on the server. What followed was a painful exercise and I ended up giving in after wasting what must amount to days of effort on it.

In looking for a solution I managed to enlist the help of quite a few people. To name a few - Bo Frederiksen, the amazingly kind Simon Delicata (who I tracked down via Google after seeing this posting about the same issue on LDD) and the ever-helpful chaps at Prominic.NET who did everything they could to get it working. In the end none of us could. I thank them all for trying though!

What to do? What I don't want to do is have the hosted version of DEXT be anything less than the fully functional database I want it to be.

The only avenue I have left to explore is to try and use the PJA Toolkit to draw graphics. How much time do I want to invest in learning and re-coding what I've done though? Especially as it will already work for almost 3/4 of you without needing more work. I just don't have that much spare time. Using PJA would make the code more complicated than it really needs to be. It would make more sense to leave it to the minority of you who this wouldn't work for to find your own solution.

So, should I have Prominic.NET move this server to Windows or should I have them run the Domino server from within the X11 environment? I'd asked about the latter but they were hesitant to do so as it eats up extra resources unnecessarily. Right now though that doesn't bother me much. I just want things to work with the simplest form of code possible. I don't like feeling restricted by the environment.

If anybody has an example of using PJA to draw graphics with a Domino server on Linux (with no X11 library code) then I'd be grateful if they'd share it. Or any other advice for that matter. As long as it's not to set "headless=true". That doesn't work. Trust me.

The other day I got asked:

This might seem like a silly question, but can we use google analytics on a private (login access only) site? The way I've seen it work so far is only on public facing sites.

Not a silly question at all. Well, maybe it is, but I didn't know the answer either. In reply I said that I couldn't see any reason why not and that I'd take a look.

From the way I understood it to work you just need to load the external Google-hosted JavaScript file in to your page and that's all it takes. Although there is one step in the sign-up process which limits where you can use Analytics. Before Google will start tracking a site it takes a look at the site in question to make sure you've added your unique tracking code to the bottom of the page found at the domain you want to track. For this reason the site must be Internet-facing.

If you want to track hits to a site not available on the Intranet using the Analytics code this answer from the Google site might help:

If you have content behind a security firewall or on an intranet or internal network that prevents you from using the Google Analytics service, Urchin 5 software is for you.

Now, assuming the site is accessible from the Internet, what happens if you require a login to access the site? Well, Google will only ever see the login form, so you just need to make sure your tracking code is on the bottom of the login form. When Google "pings" the site you're trying to setup to see if it can find the tracking code it gets a login form. This doesn't matter though. As long as the code is in the HTML returned.

To test the theory I tried if on a site of my own. If you look at clients.rockalldesign.com you'll see a login page for my home-made CRM package. Look at the bottom of the source and you'll see the Google tracking code. It all works as expected and I can now see how much use the CRM is getting -- even though Google itself can't get past the login form and/or see any of the actual content beyond it.

If you host lots of sites and want to track them in different Anayltics accounts then you'll need to either use multiple custom Login forms or have the code which displays at the bottom of the login form compute itself based on the Server_Name field and the site being accessed when the login form appears.

Hope that helps.

I know this is one of those things I really probably ought to know, but, after 10 years as a Notes developer I've never given the matter of name changes much thought. This is most likely as, until now, it's never been something I've had to deal with. Now that the topic has cropped up I'm wondering how it's best dealt with.

A user of an application I've developed has got married and is requesting their name be changed in all the places it appears.

Like most applications the database in question stores the canonical @UserName in various places and uses it as the primary key that ties together all the documents which belong to that user. If the user's name is changed directly in the Domino Directory then, next time they log in, it will appear there's no content which belongs to them.

What to do?

Do I need to write some code to find all documents in which @UserName is stored and update them all one by one? I don't mind doing this but I can't believe this isn't something that crops up all the time.

Surely there's an easier way? Doesn't AdminP handle all of this somehow?

It leaves me wondering about an @UserID function which returns a never-changing unique number for each user in the NAB. You can change the user's name as much as you like. The user's ID will never change and, if that's what's stored in the document, this isn't a problem. That's how it would work in LAMP ;o)

Anybody who has left a comment on this site recently might have noticed the form for doing so has changed ever so slightly. In line with the recent spate of changes I've made to this site I tweaked the comment form a little. Mainly I made the "body" field bigger, which I've been meaning to do for ages now.

While I was at it I added some padding to the fields. Here's the form before adding padding:

And here's the form with some padding:

It's a subtle change but I hope you agree it has a beneficial effect? To me it just seems much nicer. You wouldn't have the text of the page butted right up next to the edge of the screen would you? Most text deserves a little white-space around it to make it easier to read. Input fields never have any padding though, which seems a shame.

Adding the padding is so simple I'm not even sure I need to say how, but here goes. Add the following to your master stylesheet:

input{

 padding: 2px;

}

textarea{

 padding: 5px;

}

From now on I think I'll make it a part of the global CSS of all sites I work on.

In March this year I talked about using a scheduled nightly agent to update the selection formulas of views which show documents based on dates.

It's a tip I've come to rely on in all databases I've created since. The one drawback is that I sometimes forget the view's selection formula is controlled by an agent and change them directly, only to find the change is lost the next day. Doh. To avoid confusion I modified the view-updating code to add an obvious warning about this.

Here's the new code:

Dim TodayDateTime As New NotesDateTime(Now) warning = |REM "WARNING: THIS FORMULA IS UPDATED EACH NIGHT BY AN AGENT. 
ALL CHANGES WILL BE LOST!";
| Set view = db.GetView("FutureEvents")
selection={SELECT Form="Event" & EventDate>[}+ TodayDateTime.DateOnly+{]}
view.SelectionFormula = warning + selection
Call view.Refresh Set view = db.GetView("FutureMeetings")
selection={SELECT Form="Meeting" & MeetingDate>[}+ TodayDateTime.DateOnly+{]}
view.SelectionFormula = warning + selection
Call view.Refresh

The result is a view that looks something like this:

Hopefully this will prevent accidentally making the change that and forgetting it actually needs to be done in the agent itself. Well, I say agent, the change should ideally be made in the Script Library called from the agent -- see the second tip in the blog I linked to above.

Notice that the code in the first entry I wrote about this didn't include the SELECT keyword in the selection formula, but that this code does. It's inclusion appears to be optional and Notes will add it if you don't If, like here, you're adding code that's not part of the selection (the REM) then you need to add the SELECT otherwise the REM gets wrapped inside it.