Inmagic Webpublisher canned query URLs can be very very long, so I wrote a .NET HttpHandler that shortens them and bolsters their persistence into the bargain.
Here's an example of a very long Webpublisher query string that displays a single record from the sample cars database.
See? Looooooooong. Not at all memorable, and difficult to display or pass around. But with the handler in play, I can now shorten it:
Both get the same result:
A classic best-seller, the Porsche 911's anodized aluminum tub chassis has a strong front brace for extra support. A steel mount holds the engine snugly in place. Mounted on 25-degree caster blocks, the A-arms are longer than most and can be adjusted for low-speed steering or short tracks. The upper links have coated turnbuckles which can also be adjusted for different terrains. The rear suspension uses extra-long arms and variable shocks. The engine is side mounted and sits lower than many models. The clutch, which happens to double as the brake drum, is mounted on the crankshaft.
In the case of the short URL, the original query remains valid, but is held in the application's web.config:
The original query is called upon with an alias: qn=mycarquery. The id parameter is appended to focus the query to a single record, or, if no id parameter, the base query is run as-is.
The short URL path is /shorturl.ashx, but this is completely imaginary. And configurable in web.config:
Using the examples above, any one of the following would be valid.
None of the paths exist on disk, which is what an HttpHandler is all about. The handler hijacks the request to any path bound to it, whether the path exists on disk or not.
Mapping entire queries to simple aliases has some immediate and obvious advantages:
- Short URLs.
- URLs are friendlier, more memorable, and hackable. (If you are trying to make your information available this is a *good* thing.)
- You can map almost any URL path you want to the handler, in order to organize query paths into pleasing hierarchies of your own devising:
- e.g. /catalog/queries?qn=mycatalogquery
- You can define and update queries in one central location.
- URLs become more persistent. Modifications to queries will not break URLs already in the wild:
- Switch from Dbtext to Content Server without breaking any canned queries
- Switch display forms or any parameter
- Switch hostname, even