dominoGuru.com
Your Development & Design Resource
I had the best intentions...
01/02/2006 11:33 PM by Chris Toohey
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....