Chris Toohey | Domino Guru

Downloading and understanding what I needed to do to get an OpenNTF.org solution (I'll refrain from saying which one at this time) up and running was very easy. Download to "functional" configuration took well under 10 minutes. Not too shabby if you ask me; true RAD, and the price was just right.

Then, I started to try and do some pretty standard things. I say standard meaning "web" or "internet" standard and not Lotus Notes/Domino standard (if there are such things...). The first being a new goal of mine on a current project that I'm working on - functional, logical, and pretty (read: short) URLs.

The majority of us have done the following: you've configured your amazing application, worked out all the kinks and think it's the coolest thing in the world. Now, you deploy this web-based solution and send out an email or other like-electronic-correspondence with the following mess:

http://dominoservername.companydomain.net/_ applicationsdirectory/solutiondirectory/databasename.nsf

Now, even though this is fully functional yet unbelievably long and ugly, you're pretty much OK with this as long as the recipient/user either 1) bookmarks the email/correspondence or 2) bookmarks the URL post-load.

Now, if you were using a solution outside of Domino, and had control over the DNS server (or gave a cupcake to the network admin), your URL would more-than-likely look more like this:

http://solutionname.companydomain.net

MUCH nicer! It's clean, short, and easy for people to remember (as long as your "solution name" is logical enough - remember, your West Coast VP of Sales might not remember that http://aragon.companydomain.net will launch their SFA solution - while not as l33t as one might like, http://sales.companydomain.net is perfect here.

Along these lines, functional URLs are often just as ugly for Domino-based solutions.

Even if you've gone as far as setting up a subdomain and correlating redirect, when you grab the current URL for the document that you just-so-happen to want to share with a co-worker, http://sales.companydomain.net quickly becomes http://sales.companydomain.net/applicationdirectory/solutiondirectory/_ databasename.nsf/specificviewname/document?OpenDocument. Ugh!

Non-Domino, per se? http://sales.companydomain.net/permalink/document.ext

Now it may come across as me picking on Domino to the yellow-bleeding congregation, but truth is the every-day Lotus Notes admin/developer wouldn't think twice about sending a URL to someone that looked like a buffer overflow attack. I mean, it's not like we're getting such direction from the product vendor:

http://www-142.ibm.com/software/sw-lotus/products/_ product4.nsf/wdocs/noteshomepage?OpenDocument&cwesite=notes... which could easily be http://lotusnotes.ibm.com couldn't it?! But I digress...

So back to my original point of this rant 'blog: I downloaded something from OpenNTF.org, created a subdomain and a traffic/URL substitution rule... and watched the beautiful, functional solution take a dirt nap. I damned near broke everything there was in the solution. In fact (speaking of the Product Vendor), using this approach to a clean URL also breaks pretty much all out-of-the-box solutions for Domino, including the Domino Directory and Webmail implementations.

And since this approach doesn't seem to be supported by the Product Vendor (since it breaks basic functionality despite being a click-and-save configuration within the product), can you really fault people for 1) not coding for such an adoption and 2) (and more importantly) not adopting such a standard in the first place?!

The very simple and easy fix for the Open Source solution would be, from what I can see, to employ a base href tag in the header of all web-facing design elements. Can this be done easily? Of course! I'll make it a point to contact the Project Chef (who I admire and respect, truth be told). I do it with a few outside-the-box methods and a shared, embedded subform on my design elements.

Which reminds me... and possibly more fodder for a rant 'blog tomorrow: the usage of Computed Subforms on a Form element where the computation is something like "header". It's useless computing, reminding me of (IBM/Lotus bash #3, for those of you keeping count...) the following two computed subforms on the Memo form (at least in my mail template):

REM {This is a discussion Thread view. it is currently disabled and roped off throuhg an notes.ini variable. To turn it on, uncomment out the code below, and place $DiscThread=1 in it};
REM {@If(@IsAvailable($HideMailHeader);"";@TextToNumber(@Version) > 170 & @ClientType="Notes";"(DiscussionThread)";"")};
""

REM {Obsolete - Please uncomment out the code below if you are using this product};
REM {@If(@IsAvailable($HideMailHeader);"";_ @ClientType="Notes";"$LotusFaxMemoSubform";"")};
""

I'd be curious to the load-impact that a Computed Subform has on a particular form/document. Mind you, this is an improvement from previous gems as a Computed Subform that checked the local System Registry to see if a plug-in was installed, thus the Registry lookup would be performed every time you open a piece of mail or new memo!!!!!!!!

I could go on with this for hours....

---

Add a New Comment

Name
Email (Not Published/Public)
Website Remember my Information!

Anti-Spam (Enter the text from the image to proceed)

(Full markup allowed in the comment field below; play nice!)

Comments

Live Comments Preview

 

---

The content of this site carries no warranty.
All design and content © dominoguru.com 2003-2008 unless otherwise noted.
( designed and developed by Chris Toohey unless otherwise noted )