Proposal

Add 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.

Reason

Services 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.

Solution

Need 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.

More open questions

* 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)

1. I agree we need something like this.

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?

/Lars

I think the point of this is to redirect after the fact. In that case, you only need the URL for this service contract. Doing the calculation before presenting a list of objects will not scale, so a service contract for presentation won't really work.

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.

I prefer the urls to have the action after the id, but maybe thats just me. ie. http://example.com/object/123/edit

Can i assume this TIP got approved if i'll do it like Lars suggested (/object/1234/edit, /object/1234/view, /object/1234/delete) ?

Can i assume this TIP got approved if i'll do it like Lars suggested (/object/1234/edit, /object/1234/view, /object/1234/delete) ?

Approved.

Approved

I approve.

If this does get implemented we should make sure that it's coordinated with the existing service contract in search that
generates urls).  I actually think using the search one
is a reasonable answer though.

Approved. Seems like we have more than enough votes to approve. I'll change the header to reflect this.

-Roberto