Roger thanks for the excellent critique. Referring to URL's or URI's (assumed to mean Unique Resource Identifier as opposed to Unique Resource Locator) as unique identifiers (or primary Key) is just what I needed to hear to broaden how I was conceptualizing the problem. Your critique helps me think about the problem much better. Thanks.
>>Just out of curiosity, but why is the URL "awful"?
>
>Bearing in mind that I create ugly URIs as often as anyone, that I am simply answering a question, and that I don't want to pick on someone else's work:
>
>(1) URIs should describe the resource they identify, not the technology used to create it. (Data persists, but technology changes.) So ideally, .cfm and .html file extensions are no-nos.
>
>(2) Similarly, the URI in question spends most of its length describing the internal functions of the application, not the data itself.
>
>(3) Speaking of length... that's a long URI, which will all-too-often be mangled when passed around in email.
>
>(4) The query names that matter to the user are either opaque (Gindex, Pindex) or tightly coupled to the nature of the request (ID_FIRM_ABOUT). All other things being equal, you're better off with the far simpler "group", "person", and "firm". (Chances are gindex and pindex don't translate to "group" and "person", of course, but the URI design encourages such bad guesses.)
>
>(5) In a broader sense, query-string URIs are troublesome in and of themselves. A good URI can be used as a unique, unchanging identifier... a primary key for the Web, in other words. Since query name/value pairs can appear in any order, it's very easy to have the same application linking to ?foo=bar&bar=foo in one place and ?bar=foo&foo=bar in another. Will the application still work? Sure. But the Web thinks you're pointing to different pages, which is only a good thing if you're trying to spam Google.
>
>Having said all of that, thre are valid reasons to dispense with any of the above principles in a given situation, and no one is a Bad Person for doing so. But it's all worth bearing in mind as you develop.
>
>--
>Roger
>JournURL
>site: http://journurl.com/
>blog: http://admin.support.journurl.com/
>
[Todays Threads]
[This Message]
[Subscription]
[Fast Unsubscribe]
[User Settings]
- Re: CMS Solutions (Friendly URL's) John Quarto-vonTivadar
- Re:CMS Solutions (Friendly UR... Mauricio Giraldo
- RE: CMS Solutions (Friend... Matt Robertson
- Re:CMS Solutions (Friendl... Mauricio Giraldo
- Re:CMS Solutions (Friendly URL's) Roger Benningfield
- RE: CMS Solutions (Friendly URL's) Dwayne Cole
- RE: CMS Solutions (Friendly URL's) Raymond Camden
- RE: CMS Solutions (Friendly URL's) Raymond Camden
- Re: CMS Solutions (Friendly URL's) Matt Robertson
- RE: CMS Solutions (Friendly URL's) Peter Tilbrook
- Re:CMS Solutions (Friendly URL's) Dwayne Cole
- Re:CMS Solutions (Friendly URL's) Roger Benningfield
- SOT: National Do Not Call Duane Boudreau
- Re:CMS Solutions (Friendly URL's) S . Isaac Dealey
- Re:CMS Solutions (Friendly URL's) Roger Benningfield
- Re: CMS Solutions (Friendly URL's) Matt Robertson
- RE: CMS Solutions (Friendly URL's) Kola Oyedeji
- Re:CMS Solutions (Friendly URL's) Mauricio Giraldo
- RE: CMS Solutions (Friendly URL's) Barney Boisvert
- Re:CMS Solutions (Friendly URL's) Roger Benningfield
- Re:CMS Solutions (Friendly UR... Jack Dalaa