Taking a Swing at the URL Problem
Sun Nov 04 19:20:03 EST 2012
In the new portfolio web site I'm setting up for myself, I've decided to see what I can do about Domino's, and XPages' specifically, tendency towards ungainly URLs. An XPage URL, particularly an auto-generated one from, say, a view panel, can quickly become filled with undesirable elements - namely, ".nsf", ".xsp", "$$OpenDocument", "action=", and "documentId=". They all make sense and serve important purposes for the server, and to a certain extent URLs other than the main one don't matter, but I want a clean address bar, dang it.
The approach I'm trying now involves creating a managed bean named "url" that implements Map<String, String>. Its get() method takes a normal URL of the kind that you would usually write for a page and returns a cleaned-up version if it can find it, and the original URL otherwise. So a link to, say, the contact page looks like this:
<xp:link text="Contact" value="${url['/Contact.xsp']}"/>
I also set up a "link" custom control to act as a drop-in replacement so I don't have to do that EL bit everywhere. The code itself generates an internal map based on a view of simple From/To "Alias" documents in the DB, though I'm considering having it peek into names.nsf to find any applicable Web Rules more dynamically. The net effect is that I can use that bit of EL or the custom control and hand it a "normal"-style database-relative XPage URL and it'll clean it up if it can or, worst case, pass it through directly.
I can imagine some improvements, beyond the switch to looking at names.nsf instead. For one, I should make it handle "partial" replacements, so that I could map, say "/whatever.nsf/Posts/postid" to just "/posts/postid". I could go beyond that, too, making it do regular expressions to allow it to translate arbitrarily-complex routes beyond what just checking Web Rules could do.
I'm not certain that this is necessarily the best way (the REALLY best way would be to hook into whatever code handles all URL generation in the app), but it has a nice simplicity to it and I figure it's worth a shot.
Thimo Jansen - Mon Nov 05 07:33:01 EST 2012
If I'm correct you rely on Web Rules to do the translation from the pretty URL to the .xsp URL. Would it make sense to create a servlet to do the redirecting? In a classic Domino (web based) CMS I built I had a Lotusscript agent for this task. Direct requests for forms/documents/views were not affected, but everything else went through the agent. The big advantage is that it's easy to add your own logic.
Jesse Gallagher - Mon Nov 05 07:43:18 EST 2012
I've wondered about that. I do indeed use Web Rules, mostly because it's the "native" way to do it, but they're certainly very limited. What I'd really love would be something similar to Rails routing, where you have extensive control over mapping URL patterns to specific actions in your app. That'd take quite a bit of fiddling, but I wonder if it'd be possible to have a servlet that loads up XPages itself, as the web server does normally.
In the past, I've done things like a poor man's router via a $$ReturnGeneralError form, but that was terribly ugly (hey, it was pre-XPages) and the URLs didn't "stick", since it was just redirecting the browser to another page.
I think I'm going to stick with the "adapt to Domino's standard faculties" route for this specific one, but down the line the servlet route has much more potential.
Fredrik Stöckel - Mon Nov 05 18:51:53 EST 2012
Nice post. I've been invesigating different ways to do this also. And I think a gloal web rule that points to a specific nsf - combined with something like PrettyFaces (http://ocpsoft.org/prettyfaces/) might be a nice solution If one figures out how to configure it. I have't tried it myself but it's on my todo list.
Another way (at least in theory) might be to give servlet filters a try - but I'm not sure if the current XPages/JSF spec supports filters.