Forum OpenACS Improvement Proposals (TIPs): TIP #43 (Approved) Adding object_name to acs_objects

Collapse
1: TIP #43 (Approved) Adding object_name to acs_objects
Posted by Timo Hentschel on 01/28/04 06:28 PM

Proposal

Add object_name to acs_objects table. See here

Reason

Most of the objects are in some way displayable and named (except for some internal objects such as acs_rels). Services such as categories or search need to be able to display (potential) long lists of objects with their names and let the user sort by the name. Doing this by using the current acs_object.name interface in pl/sql is inefficient and unscalable for longer object-lists and does not solve the problem to order by that name.

Disadvantages

Some objects don't have a name and therefor will need to store null values. We will need to duplicate inserts and updates on the pretty names of the package-specific tables. We will only store the names in one locale, so multilinguality is not supported.

Solution

Add triggers or change pl/sql functions for every package with named objects. Add and change core functions. Add column "object_name" of type varchar2(200) (or something the like) to table acs_objects without a "not null" restriction.

Will do the changes of the core and the packages news, forums, blogger, file-storage, categories, mailing-list and someone else should change the other packages.

Collapse
2: Re: TIP #43 (Proposal) Adding object_name to acs_objects (response to 1)
Posted by Dave Bauer on 01/28/04 06:51 PM
First,

Lets make it clear what we are talking about. The attribute you need is the display name, or pretty_name as it is commonly called in most OpenACS tables. For the content repository its the cr_revision.title.

Collapse
3: Re: TIP #43 (Proposal) Adding object_name to acs_objects (response to 2)
Posted by Jeff Davis on 01/28/04 07:00 PM
I vote yes (although I like calling it pretty_name
better and I don't like making it not null since I think
for some things there is just not a meaningful pretty_name).
Collapse
4: Re: TIP #43 (Proposal) Adding object_name to acs_objects (response to 3)
Posted by Dirk Gomez on 01/28/04 07:30 PM
We have mapped out ways to support multilinguality. And do we really want to pull in non-localizable code after having i18nized the whole toolkit?

Where is package_id? Will that be a different TIP?

What about upgrade scripts or ways for a smooth migration? Do you have a tippable proposal for this?

Collapse
5: Re: TIP #43 (Proposal) Adding object_name to acs_objects (response to 4)
Posted by Lars Pind on 01/30/04 07:04 PM
I side with Jeff and Dirk on this:

1. pretty_name is better. UPDATE: title may actually be better, for consistency with CR, which we want to move to for these kinds of objects, anyway.

2. we need to handle i18n.

/Lars

Collapse
6: Re: TIP #43 (Proposal) Adding object_name to acs_objects (response to 5)
Posted by Timo Hentschel on 01/31/04 01:21 AM
I'm in no way insisting on naming it object_name - pretty_name or title would be equally ok for me.

The thing with i18n is that nobody could come up with a reasonable solution to cope with objects in multiple languages (this shouldn't happen too often anyway). Since the feature of having a pretty_name or title of an object at a central place would help solve some immediate problems (i.e. search and categories) i would still want to see this being implemented. If a reasonable i18n solution comes up later we can still update then.

Collapse
7: Re: TIP #43 (Proposal) Adding object_name to acs_objects (response to 1)
Posted by Dave Bauer on 02/02/04 03:18 PM
Is one solution for i18n a seperate table with one row for eac h object_id/locale? Should we consider this or defer to a later time and just implement as an attribute of acs_objects for now?
Collapse
8: Re: TIP #43 (Proposal) Adding object_name to acs_objects (response to 7)
Posted by Lars Pind on 02/02/04 04:48 PM
I think we should decouple this TIP from the i18n issue, because it is more involved than what this TIP is about. We need some discussion, then a separate TIP for the i18n issue.

I've started the discussion here:

https://openacs.org/forums/message-view?message_id=161009

/Lars

Collapse
9: Re: TIP #43 (Proposed) Adding object_name to acs_objects (response to 1)
Posted by Timo Hentschel on 02/09/04 12:28 AM
Can I assume this TIP got approved if I'll use title and disregard i18n for now? (please let's move the i18n issue to a seperate TIP)
Collapse
10: Re: TIP #43 (Proposed) Adding object_name to acs_objects (response to 9)
Posted by Joel Aufrecht on 02/09/04 09:59 AM
No, the TIP didn't actually get any Approved votes, or any Yes votes, only one "Yes with caveat" vote.  Please summarize the changes, if any, and re-TIP.  I know it seems like bureaucracy, but one purpose of TIPs is to leave a clear record of what we decided, and that means that the proposal text must be complete - if you have to read the TIP and ten comments and figure out which comments were definitive changes and which were opinions that may or may not have been accepted, then TIPs offer little advantage to forum discussion.
Collapse
11: Re: TIP #43 (Proposed) Adding object_name to acs_objects (approved by malte) (response to 9)
Posted by Malte Sussdorff on 02/09/04 10:16 AM
Can I assume this TIP got approved if I'll use title and disregard i18n for now? (please let's move the i18n issue to a seperate TIP)

Approved

Collapse
12: Re: TIP #43: Approved (response to 11)
Posted by Lars Pind on 02/09/04 10:32 AM
/Lars
Collapse
13: Re: TIP #43 (Proposed) Adding object_name to acs_objects (response to 1)
Posted by Peter Marklund on 02/09/04 11:05 AM
Approved
Collapse
14: Re: TIP #43: Approved by Dave Bauer (response to 1)
Posted by Dave Bauer on 02/09/04 02:52 PM
Approved.
Collapse
15: Re: TIP #43 (Proposed) Adding object_name to acs_objects (response to 1)
Posted by Caroline Meeks on 02/09/04 03:13 PM
Approved
Collapse
16: Re: TIP #43 (Proposed) Adding object_name to acs_objects (response to 1)
Posted by Don Baccus on 02/09/04 03:28 PM
I approve, too.  I would like this and the package_id TIP to both include notices that package-specific table package_ids and pretty_names - including the CR's title - will disappear eventually to encourage package authors and maintainers to start migrating to the use of the base object title (which I prefer over pretty_name) and package_id.

I realize we won't be able to ALTER TABLE CONTENT_ITEM DROP TITLE until, say, late fall or winter but I would like to see us put folks on notice that this is the direction we're moving in and that they should consider migrating sooner rather than later.

Collapse
17: Re: TIP #43 Approved by rbm (response to 1)
Posted by Roberto Mello on 02/09/04 08:34 PM
Approved. I agree with Don's remarks on this TIP.

-Roberto

Collapse
18: Re: TIP #43 (Proposed) Adding object_name to acs_objects (response to 1)
Posted by Mark Aufflick on 02/10/04 08:25 PM
Don, can you clarify your comments please? (Maybe in the developer forum) - what you are saying sounds scary, but I'm sure it's not!

PS: Are non-oct members allowed to make comments here?

Collapse
19: Re: TIP #43 (Proposed) Adding object_name to acs_objects (response to 1)
Posted by Don Baccus on 02/10/04 09:09 PM
OK, to clarify ... if we're going to ratinonalize the object structure, for instance adding the "title" field to objects, at some point we'll want to remove the redundant title field from CR objects and rely on the title field of the base acs_object type.

We can't do this right away and need to think about upgrade scripts.  Code that uses the special views created for content_types can perhaps remain unchanged because our upgrade scripts can rewrite the views to use the proper title field.

Timo ... better make sure the new title field is at least as large as the one in CR objects.

But Mark, don't worry, we won't take any steps that can't be solved in an upgrade process.  I just want folks to understand that our goal is to simplify and unify the object/content item issue, not to further divorce the two by maintaining redundant fields!

Collapse
20: Re: TIP #43 (Proposed) Adding object_name to acs_objects (response to 1)
Posted by Joel Aufrecht on 02/11/04 09:39 AM
marked approved