Forum OpenACS Q&A: Re: url abstraction

Collapse
19: Re: url abstraction (response to 15)
Posted by bill kellerman on
argh...  i wrote this once already...  here we go again.

search engines are becoming more comfortable with querystrings, so that alone would not be enough of a motivation for abstract urls.  however, i see it as expanding on the logic of removing file extensions from filenames.

the issues seem to be:

- defining a standard structure:  what is the safest, most portable method?  vignette's storyserver has done this for years with the 0,283,1687_1919_304,1.html name format, allowing a cheap and easy way to cache files on the filesystem.  maybe that idea could be moved into a directory name.  you'd just have to take into account future changes in the definition.

- where to perform the actual translation from url to variables:  i'm getting more familiar with the oacs, but i'm still way retarded on the code.  i'd hope a preprocessing filter could be defined which translates everything to the right of the location using the definition from #1 -- which is i think what you said don.  existing code couldn't take advantage of it because of direct calls to ns_conn headers -- they'd have to be modified (which is a big deal).  once  it's modified to call some get_querystring_vars proc, it shouldn't care if the proc had to retrieve them from a regular or abstracted url.

- is it worth the complexity, and does anybody care?  abstract urls could make transitions between backends easier, make static site mirroring easier (running "dynamic" content without actually needing the database, especially in failover emergencies), make prettier and more easily remembered urls for users.

i read the forum at http://foo.org/forums/message-view?message_id=75763 in regards to magic numbers.  unless someone can come up with a good solution, there seems to be too much complexity.

i do like tom's "tinyurl" suggestion.  the key point is that a system handling abstract urls should still be able to handle regular urls.  resources can be mapped to abstractions, and within pages you could call a proc like make_appropriate_hyperlink.  if abstraction is turned on, the proc generates the defined url format otherwise regular.

really, i need to get more comfortable with how the system works so i can actually have more useful input.  thanks for indulging me on this.

Collapse
22: Re: url abstraction (response to 19)
Posted by bill kellerman on
"...if abstraction is turned on, the proc generates the defined url format otherwise regular."

didn't explain what i'm talking about very clearly.

in order to try and manage internal links between resources and what type of url to use:

the site i work has internal links that change often.  i'd like a way to store internal and external links with a map to the content itself.  so, if i call a proc make_appropriate_hyperlink $pageid (or whatever identifying scheme and structure), it would return http://foo.org/mydirectory/mypage?myid=666.  if the url changes, i change it in the map, don't need to edit any html pages and don't have to set up redirects (except for user bookmarks).

so, the make_appr_hyperlink can check if abstraction for that subsite is on.  if so, it would instead return http://foo.org/mydirectory/mypage/666.

the content mapping would be handled anyway, the abstraction is just an addition, and the pages don't know how or where they got their querystring values from -- just that they got them.