How many of you Domino Developers have even touched Internet Site documents? How many of you who mentally (and let's not hope physically) raised your hands have used Internet Site Rules?

... and don't feel bad if you didn't raise your hand. I'm going to bet that more than half of the people who actually read this site don't play around with them. And there's some pretty good reasons why:

1. "I don't control my DNS, and the network admin is..."
2. "I don't want to break current applications."
3. "I don't have access in Domino to create them, and the Domino admin is..."

Now, while I can't help you with #3, I think we can pretty easily address excuses concerns #1 & #2.

Your computer maintains it's own built-in DNS, via a (for Windows-based OS users at least) hosts file - typically located in C:\WINDOWS\system32\dirvers\etc\hosts. This is the authoratative source that tells the OS that localhost points to 127.0.0.1.

If you edit that file - via Notepad or your preferred text editor - you can add a fake domain or even (if you don't prefer to use somefakedomain.org) a cname for your company domain. You'll even see that the first non-commented line (comments are marked by a #) is the 127.0.0.1=localhost setting!

So you can use this to create your fake domain or cname for your company domain. How this plays into Domino, you can setup an Internet Site document to play with and tackle those awesome-when-used-right Rules!

So have at it - don't worry about having to bug your network admin to create a DNS entry for you just so you can play around and learn something that can be truly beneficial!

I use, for example, substitution rules all of the time - and not only so you don't see the folder hierarchy or .nsf in this website's URL! I just recently updated a Domino-based application that required that I do all development out-of-template (long story). Instead of replacing this application with my new one, I simply took my time migrating and tweaking the data from the source (v1) database until I was ready to "go live" with the next release.

The cut-over was seemless, outside of the users seeing a new UI and the advanced/enhanced functionality and capabilities that they had just received training on! A simple Substitution Rule taking incoming requests for /v1db.nsf to translate directly to /applications/subdirectory2/v2db.nsf.

Internet Site Documents and Substitution Rules also really come in handy when architecting a website. No longer do I need to create a <base href> tag, unless I want to - I simply let the server (and not the design, kinda like seperating content from UI huh?) tell you where you're at!

Oh, and about #3 - explain the control and architecture leverage benefits using these built-in options within Domino, and I have a feeling that you'll both want to start playing around with Internet Site and Rules documents!

Quick tip here... dealing with <base href>, and Internet Site Substitution Rules.

I'm currently, for www.dominoguru.com or dominoguru.com redirecting all traffic to the database as root-level. As such, I've set my shared basehref field (a Shared Field which is present in all that you see: More Site Mods - non-Domino-branded URLs for the backstory and What to base your links on for more information on the <base href> tag...) to simply the domain, as I'm letting Domino do the rest via the Internet Site Substitution Rules (ISSR for short).

My basehref field has the following formula:

"http://" + @GetHTTPHeader("Host") + "/"

And this is fine, as long as my ISSR do their job... but what if I hit this database with a domain that isn't configured with ISSR to substitute everything after the domain relative to the database? I get errors - 404s all day! Not good - as I might have another domain that could access a particular application or such as part of a suite, and therefore would not particularly be bound to any individual database - read: no ISSRs gang!

To alleviate such issues, I've modified my basehref field formula as appropriate:

hn := @GetHTTPHeader("Host");
@If(hn = "subdomain.serverdomain.net";"http://" + hn + "/"; "http://" + hn + "/" + @WebDbName + "/")

subdomain.serverdomain.net, in this case, is my domain, or other ISSR-configured domain, and thus I can use the domain in the <base href> tag - otherwise, I defer to using the entire non-ISSR, @WebDBName-ified pathing!

This is a simple example mind you, and you can modify the above formula to include multiple ISSR-maintained domains/subdomains to ensure that your web applications are accessible via multiple domains and keep those 404s at bay!