Home
The Toolkit for Online Communities
17204 Community Members, 0 members online, 2018 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Improvement Proposals (TIPs) : TIP #44 (Approved) Service Contract to resolve the url from an object_id

Forum OpenACS Improvement Proposals (TIPs): TIP #44 (Approved) Service Contract to resolve the url from an object_id

Icon of envelope Request notifications

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.

I would like to see a solution that can show the full URL in a list of objects.

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.

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)

Currently on search you need to make a service contract to make the url.  Will this be replaced by this?
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

Mmm... Interesting points, Lars. Yes, i do think something like EditURL or DeleteURL could be of use. Any other ideas?
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.

... or

http://example.com/object/view/123

http://example.com/object/edit/123

http://example.com/object/delete/123

etc.

with a central registry of object types, actions you can perform on them, and the privilege required to do so.

Starts to sound like OO, huh? :)

/Lars

I prefer the urls to have the action after the id, but maybe thats just me. ie. http://example.com/object/123/edit
As long as the request is served by a VUH, it doesn't really matter.
Can i assume this TIP got approved if i'll do it like Lars suggested (/object/1234/edit, /object/1234/view, /object/1234/delete) ?
No, the TIP didn't actually get any Approved votes, or any Yes votes, or even any Yes but votes.  Please summarize the changes, if any, and re-TIP, or if you think that the original TIP is fine as-is but simply didn't get any votes one way or the other, ask for a full vote.
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.

Collapse
14: Approved (response to 13)
Posted by Lars Pind on
/Lars
Collapse
15: Re: TIP #44 Approved (response to 1)
Posted by Dave Bauer on
Approved
Approved
I approve.
Approved
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.
I agree with Jeff...

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

Collapse
Posted by Roberto Mello on
Approved. Seems like we have more than enough votes to approve. I'll change the header to reflect this.

-Roberto

Collapse
Posted by Joel Aufrecht on
Marked approved