Yellow is the New Blog

Ever since Peter von Stöckel posted about using NotesDatabase.GetProfileDocCollection to quickly create an empty NotesDocumentCollection, I've been meaning to benchmark it against a database with hundreds of thousands of documents, but keep forgetting to. Earlier tonight I had a reason for needing an empty collection, was reminded of the benchmarks Nick Wall provided on Peter's post (tested on a Domino 6.5.3 server), and realized that my web server log would be an ideal candidate to see if the speeds are similar in the Notes 8 client... at the time, it contained 541,269 documents. Here's how it turned out:

	db.Search ({@False}, Nothing, 0)	db.Search ({@False}, datTomorrow, 0)	db.GetProfileDocCollection ( "EmptyCollection" )
1	3.074	0.191	0.04
2	3.295	0.201	0
3	3.104	0.201	0
4	3.125	0.2	0
5	3.054	0.201	0
6	3.205	0.19	0.01
7	3.084	0.2	0.01
8	3.115	0.2	0
9	3.094	0.2	0
10	3.225	0.2	0
Average (in seconds)	3.1375	0.1984	0.006
Per document (in nanoseconds)	5.9765	0.3665	0.011

Still scales pretty well. Let me know if you've done any benchmarking against a huge database that also contains a significant number of profiles... my DomLog only contains one.

A couple of disturbing observations:

First, in a 2006 post from Julian about animated favicons, the little animated banana dances at the exact same tempo as the song "Your Star" by the All-American Rejects. Try it... it's mesmerizing.

But secondly, to explain the title of this post, I noticed an odd behavior related to image resources in the Notes client: GIF support is incomplete. ICO files are actually stored in the same format as GIF, just with a different extension. So another approach to creating animated favicons is to simply rename an animated GIF to .ICO. That's how Dean Edwards created a favicon that periodically blinks. Theoretically, then, we should be able to download any site's favicon, rename it to .GIF, import it as a file resource, and then display it in the Notes client. No such luck.

Since real browsers (read: Firefox, Safari, and Opera... of course, as always, IE fails) don't distinguish between the two formats and simply trust the server-supplied MIME type, navigate to the same image resource via a URL and the image displays as expected. But try to reference the same image resource anywhere in the Notes client (or even just preview it in the image resource list), and you get nothin' but gray.

Sorry, Bruce, I tried...

Back when I was experimenting with XIDED,  I wrote a utility database to mitigate my primary annoyances when dealing with JavaScript - in Domino in particular, but also a few general pet peeves (you'll probably notice that the recently released beta of 8.5 addresses the first of these):

• The JavaScript editor in Domino Designer is an IDE pretending to be Windows Notepad, failing in that imitation only when it occasionally maintains the current indentation from one line to the next.
• As the complexity of a web application increases, so does the hassle of maintaining all of its application-specific JavaScript in a single source file... the ink was starting to rub off on my Ctrl and F keys.
• Conversely, if you split out your source into a bunch of smaller, more maintainable files, it's a pain to merge them all back into one, so the temptation is to just throw a script tag in for each one, which tends to negatively impact page load times (even if the browser is pulling each from the cache, it still has to check each one separately to see if it's in the cache, so it might not be downloading each again, but there's still a performance hit). But then you still have to refresh the file resource for each that has been updated.
  
• At one point, the combined uncompressed size of all of my source (including the frameworks I was using in addition to my application-specific code) was just over 1.5 MB, which is ridiculous. But minification and compression added two additional steps to my "build" process.

So out of pure old-fashioned laziness, I wrote what I now call "JSFactory": once I've defined a project version document (to allow multiple versions to be maintained in different directories), listing the location of the source files in the order that they should be combined, an output location for the combined file (and - optionally - compressed, and/or gzipped... since I've configured my server to deliver gzipped content), and a file resource element to update, I can refresh that element with a single click. So I can maintain lots of little source files, doing my coding in Aptana, and then update my application without even opening Designer. It works in Windows and Linux (and presumably Mac, though I don't have one to verify that).

So if I've had this for years, why am I just mentioning it now? Well, two reasons. The first is that Chris Toohey's SOTU Sidebar Widget Demo inspired me to add a similar widget to JSFactory, which I did yesterday:



The second is that I decided to try an experiment: in a singular (and possibly only) departure from my traditional "give everything away" approach, I'm offering this for sale. As its usefulness is restricted to a very specific niche task, and future versions of Domino may make it entirely obsolete (here's hoping, anyway), I'm only charging $9.99, and I didn't bother putting in a bunch of licensing restrictions; if you buy it, it's yours to use as you see fit: donate it to your whole team (assuming you have one), put it on as many workstations or servers as you wish, modify the source (yes, I left it open), etc. I realize this means that one person could buy it and just send it around to everyone else, but I'm not looking to "make my millions" with this... I've got a dream job. I just request that if you receive a copy without having purchased it and find it useful, consider buying your own license... it's the same price as most albums on iTunes.

Bruce just pinged me with a dilemma: he wanted a way to to make URL's clickable when displayed in a view column from within the Notes client. I wracked my brain momentarily, and the only idea I could come up with was using the Inviewedit trick that I first saw Chris Blatnick allude to in his CoolMail demo (explained later in greater detail). This isn't ideal, of course, as that technique requires that you click an icon column - perhaps immediately adjacent to the URL - not the URL itself...

...or does it? One of the parameters included in the Inviewedit event is Continue, something we're typically used to toggling in other events to prevent that event from completing. For example, you might perform some validation in the QuerySave and toggle Continue to False if the validation fails, or toggle it to False in the QueryOpen if you want to load a DialogBox when the user tries to open the document using the standard form. So what happens if Continue is False in the Inviewedit? Even if the column in question is a standard text column (in other words, not displayed as an icon), if Continue is immediately toggled to False, the column never becomes editable! But the event has already been triggered, so you can still determine the row that was clicked (via Source.CaretNoteID), and can therefore get a handle on the document, retrieve the URL, and navigate to it. Voila:

Let Continue = False
Dim workspace As New NotesUIWorkspace
Dim session As New NotesSession
Dim dbCurrent As NotesDatabase
Dim docSelected As NotesDocument
    
Set dbCurrent = session.CurrentDatabase
Set docSelected = dbCurrent.GetDocumentByID(Source.CaretNoteID)
Call workspace.URLOpen(docSelected.GetItemValue("URL")(0))

Episode 3 was released earlier this evening. Just a quick one (by comparison) - only 36 minutes - but hopefully informative and mildly entertaining. Don't let the title throw you... all is explained in the Community News segment.

Back in December, Nathan asked me for a quick proof of concept of using Decepticon in conjunction with ExtJS to provide easy styling of Domino forms. It was even easier than I thought it would be, so a couple days later (actually, I think it was the same night... can't remember now) I sent him a link to an example implementation... and promptly forgot all about it until he mentioned recently that somebody else was interested in the same functionality. I figured I might as well clean it up a bit to allow it to be even more modular. The result is a subform that, when added to any form, automatically renders all fields in their Ext.Form equivalent. And... it works with or without Decepticon. It's just easier if you do use Decepticon.

To see this in action, this is how a fairly typical form might look when developed specifically for Notes client usage. Pretty standard, right? Two-column table, one column for field labels and another for the fields. This is what the same form looks like when the subform is included. The table still looks crappy, of course, so you'd want to do some additional cleanup to make the form itself look nice, but for the actual fields, here are a couple of the "easy wins":

• Date-only date fields get a date-picker... not 'cause you flagged them somehow, just because the subform knows it's a date field.
• Similarly, time-only fields get a time-picker. NOTE: if you've specified that the field should display date and time, this still gets confused and renders a boring text input.
• Dialog lists, comboboxes and listboxes get converted to the fancy Ext type-ahead combo thingy. Ironically, "Allow values not in list" currently has the same limitation as above: boring text input.
• If you populate the "Help Description" property for a text field, it renders it similarly to how the "Field Hint" property behaves in Notes: the description displays as a faded background to the field, but unlike in Notes, if you blur out of the field when it has no value (even if it used to), the hint returns. In retrospect, I probably should have pointed this to the "Field Hint" property instead, so feel free to tweak the XSL accordingly.
• Rich text fields get rendered as full-blown WYSIWYG HTML editors. The usefulness of this feature is the most questionable of the bunch, as you probably don't want your rich text fields stored as HTML. On the other hand, if you're already setting your rich text to "Store contents as HTML and MIME", this may be a perfect fit for you. In all honesty, I haven't used any of this in a real-world application yet, so I'm curious to hear what your results are if you do.
  

The example database can be downloaded here.

There's a software platform that I'm a huge fan of, as most people know, but sometimes it can be frustrating to use, for the following reasons:

• The usability and interface have come a long way over the last few years, but it's still not quite up to the standard set by Microsoft and Apple interfaces.
• It's more secure, reliable and powerful than anything else out there, but it seems like every fix I install breaks 3 other things that I need to just work.
• Most importantly, while awareness of the platform is gradually increasing, it's primarily still restricted to geeks who are passionate about the platform. So occasionally I see a piece of software or hardware device that integrates with it that didn't used to, but the implementation tends to be subpar in comparison to what is available for integration with Microsoft. But more often than not, it gets ignored entirely, and the software/device vendor just provides a Microsoft integration point.
  

So, obviously, I'm talking about Linux... wait, what did you think I was referring to? Oh.... Bummer.

It's always nice to find out that something I've written proved useful to a fellow Yellowbleeder. Back in '06, I described an approach to performing @DbLookup / @DbColumn operations in AJAX applications. Sasha Oros has now written an article for Lotus Advisor in which he explains how he has significantly expanded upon that technique. It's a fascinating article, and a great example of (in my opinion) well-written JavaScript, and the article includes a downloadable example database. Although a subscription is required to view the article, online subscription is free.