Forum OpenACS Improvement Proposals (TIPs): TIP #44 (Approved) Service Contract to resolve the url from an object_id
ProposalAdd a service contract AcsObject.Url accepting an object_id and returning the url to display that object.
Write a redirecting page (i.e. at /www/o/index.vuh) that accepts an object_id, tries to get the url by invoking the appropriate service contract implementation for that object-type and redirects to the found url or displays a page to inform the user that the url could not be resolved for that object_id.
ReasonServices like categories or search need to display lists of objects without knowing anything about the package that's responsible for them. The user then certainly wants to see some of the found objects so he needs to be directed to a url that can display that object. Since these services do not know anything about other packages we need a central way to resolve the url. Please note that we should not resolve all urls at the display time of objects-lists since that would be quite time-consuming, but defer this task to when we actually need the url because the user really wants to see an object - therefore the need for a redirecting page. Another benefit would be to have a stable url for objects that'll always work - regardless if the name, the site-node or the package of the object has changed.
SolutionNeed to write a service contract AcsObject.Url and need to implement this contract in every package that stores displayable objects. Need to write the redirecting page. Also, need to implement this contract to return urls for some core object-types such as groups, users, packages.
Will do the core changes and implementations for the packages news, forums, blogger, file-storage, categories and mailing-lists and someone else should do the changes for the other packages.
This is possible using the content repository right now. One limitation is the need to calculate the full path. There is a suggestion to merge site_nodes and cr_folders so that the path of a folder would be the site_node url, making calculation of urls trivial.
I think it would make sense to see if this could be implemented for any object that has to be addressed by URL.
* What do search engines think of loads of redirections?
* Where do we intend to stop using speaking URLs and start using computer-geekish URLs?
* I'd rather use a proper name than a perl-ish construct for the redirect page. URLs like object/1234 are better than o/1234. And object itself is a geekish term too...
A tcl function on the site-node cache that gets passed in a package_id could return a full url with the proper stub and be an efficiently implemented solution as well - if done on the tcl layer. (Dave's idea)
2. Which other things would this service contract include? Presentation, as mentioned in the TIP on package_id? Delete? EditURL? Other things we want to be able to do in a centralized fashion?
For EditURL etc, I suspect another redirect would be required if we want to generate edit links for lists of various object types.
One solution is something like http://example.com/object_url?edit. This way the URL for the object stays the same, and the parameters define which mode to use.
generates urls). I actually think using the search one
is a reasonable answer though.
Also, how about http://foo.com/object/1234 to "view", appended by "edit" etc for actions other than "view"? After all, an http: request is expected to display *something*, so "view" seems a bit redundant to me ...