Forum OpenACS Q&A: Re: Augmenting acs_objects - Add package_id, name, overview, etc. to it

I don't understand why you need package_id and object_type to generate the show-me-this-object url? I remember having seen something like this /object-by-id/1234 where 1234 is simply the object_id. Clicking on this URL will generate a redirect to the matching object, so the computation of the url will only be done when the url is clicked on and only for one object (instead of for many objects when displaying a list). That's what you intend to provide (among other things), right?

The get_url service contract that Dave is talking about is part of the notifications service contract. I would like to move that out and make it a stand alone service contract, so that every package can publish the url's of it's objects without having to implement notifications. The only client of this service contract would then be a yet to write /object-by-id/ page, while listings, notifications etc. can just link to that page. It would make most sense to do this when tcl service contracts are available I think.

Dirk, can you expand a bit more on which columns of acs_objects should be duplicated in your opinion in the package data tables and how the automatic synchronization in both directions would work? E.g. do you propose to have a package_id column both in acs_objects _and_ the package's table? Will there be a trigger on both - if yes wouldn't they fire each other infinitely?

Right, show-me-this-object only needs the object_id in the URL, but: you need the package_id to create the URL for the object e.g. you may want to apply a specific template set for a particular subsite.

The automatic synchronization never went beyond being a proposal, but of course the triggers shouldn't fire infinitely. The basic idea was/is that site-wide packages work on site-wide tables and don't know about package-specific tables whereas packages don't work with acs_objects directly.

A site-wide package here is e.g. site-wide search or a linking service something that is mostly (always?) read-only. It's quite likely that those services don't insert or update at all - and if then in a package context.