Simple function to trim JS string arrays

Update, 08.05.08:
A better trimming-function:

function trimArray( array ){
    var trimmedArray = [];
     
    var item;
    for( var i = 0, len=array.length ; i < len ; i++ ){
        item = array[i];

        if( item !== '' ){
            trimmedArray.push( item );
        }
    }

    return trimmedArray; 
}

Had a case at work where I needed to make a breadcrumb-like thingy.

The breadcrumb consisted of either two or three elements, and got it's values from form-fields. Instead of checking the fields for values, I put the values in an array, trim the empty values, and join the array with a separator.

The trimming-function:

/* Trim empty strings from JS string-Arrays */
function trimStringArray( array ){
return array.join( ',' ).replace( /,{2,}/g, ',').split( ',' );
}



Testcode for the Firebug-console.

Result (in Firebug):

Improved HttpRequest class - Handles request_content above 64k

For those of you that haven't heard, in Domino 7.01, IBM implemented a workaround for (HTTP POST) request-content above 64k.

I've updated the HttpRequest class, so that it handles requests above 64k automagically.

>> My testbed for the class
The test-app has a page that posts ~260k of data to an agent. This results in 4 request_content fields. The agent prints a report of the request ( [HtppRequest].printHtmlReport ).

The class (txt-file)

Let me know if there are errors.

Simple function to test if a list is empty

I needed a function to test if a list is empty today. This is of course something IBM doesn't think we developers have to test for, so it's not in the LS API.

Here is what I came up with.
Function listIsEmpty( listToTest As Variant ) As Boolean
If Not Islist( listToTest ) Then_
Error 1001, "The variable tested is not a list"

Forall item In listToTest
'If there is one or more items, the Forall-loop runs
' -> The list is not empty
listIsEmpty = False
Exit Function
End Forall

listIsEmpty = True
End Function

Notes 8 Classic - working undercover?

I just started using Notes 8.0.1 this week. Some things I love, and some things annoy me.

Like this one:


I was working on a calendar-entry, when suddenly the classic client popped up. I can't close it by itself. When I close the standard client, this closes as well.

Don't know if this means that the classic client is used as a go-between for Domino Designer/old Notes apps and Notes 8 Standard Client?

Internet Explorer 8 beta out

Looks like we don't have to wait another 5-6 year for IE.Next.

IE8 Beta here

Information about the beta

Gzipping/serving gzipped static content (JS/CSS)

Bandwidth is still a concern for a big part of the web users. To save bandwidth, the simplest job is to compress the content that "never" changes. For instance JS-frameworks.

There are a couple of approaches to this, "packing" utilities like Dean Edward's packer. This compresses the JS in such a way that it's still "compilable" in it's raw form. Another way is to gzip the file. This requires that the browser unpacks the file before it is sendt to the JS "compiler".

I prefer to use both packed and gzipped JS frameworks in production. This guide will hopefully help you serve gzipped JS-files without too much hassle.

The JS-lib I use in the accompanying demo, MooTools is 72KB "unzipped" (the version that is packed using JsMin). Gzipped, it's just shy of 20KB.

Preparing the Domino server

To enable gzipped content on the server, create a web site rule (requires restart of the HTTP-task).

Example of rule:

The above rule works like this: For all files in a subfolder named gz, the domino-server will add a HTTP-header, Content-Encoding, with the value of gzip. This tells the browser that the content it is downloading is compressed.

At Compendia, where I currently work, we've set this as a global rule, as it doesn't affect any other content.

Compressing files

To compress files on your machine, you need an application that can gzip files. I use gzip for DOS.

Download gzip for DOS:
32-bit (doesn't work on 64-bit Vista)
64-bit

Extract the downloaded utility to a folder of your choice. At work, I have it on c:\gzip.

Copy the file(s) you want to compress into the folder you extracted the gzip-utility.
Open command-line. cd into the folder you've extracted the gzipping-utility.

For the 64-bit utility: minigz64 name_of_file.js
For the 32-bit utility: gzip name_of_file.js

Be aware of that the dos application overwrites the original file by default.

Adding the files to a DB

Add the uncompressed/compressed file (New File Resource) to the DB of your choice. Rename the uncompressed file to lib\[filename].js, and the compressed to gz\[filename].js

With the aforementioned web site rule in place, browsers opening the gzipped file will get the correct HTTP-header, indicating gzipped content.

What about users that doesn't have gzip-enabled browsers/etc?

Some proxies/browsers/thin clients doesn't support/allow gzipped content. It's easy to identify if a browser supports gzipped content:

supportsGzip := ( @Contains( @GetHTTPHeader( "Accept-Encoding" ) ; "gzip" ) );



In the index-page of the simple demo-app, I compute the folder in a script-tag by the presence of Accept-Encoding: gzip header.

"<script src=\"/" + @WebDbName + "/" +
@If( supportsGzip ; "gz" ; "lib" ) + "/mootools-release-1.11.js\"></script>"



>> Download demo-app with gzip for Dos/mootools compressed/uncompressed.

PS! The index-page needs to run on a server with gzipping enabled, like in the picture at the top of this post. Either that, or you can run the browser in HTTP 1.0-mode. HTTP 1.0 doesn't have the Accept-Encoding header.

Good luck!

"Advanced" usage of the Print statement

I discovered this a couple of months ago, by coincidence (I actually read the documentation, instead of jumping to the example).

Punctuation character	Print statement behavior
Semicolon or space in exprList	The next data item is printed with no spaces between it and the previous data item.
Semicolon at end of exprList	The next Print statement continues printing on the same line, with no spaces or carriage returns inserted.
Comma in exprList	The next data item is printed beginning at the next tab stop. (Tab stops are at every 14 characters.)
Comma at end of exprList	The next Print statement continues printing on the same line, beginning at the next tab stop. (Tab stops are at every 14 characters.)

In most of my previous code, when debugging, I wrote something like this:
Print "Field contents: " + doc.stringField(0) + ", " & doc.numberField(0)

Using the comma separated syntax, you can get away with:
Print "Field contents:", doc.stringField(0), doc.stringField(0)

I've started using the comma-separated syntax, when debugging, simply because it's less verbose/faster to write.

I did a little test to see how the different "methods" of using Print worked. It seems like the semicolon/comma a the end of the line doesn't work (see picture below). Either that, or I've misunderstood the documentation.