Forum OpenACS Development: Re: new vers of acs_object__name(object_id)

Posted by Jim Lynch on
If you want justification for at least trying it, I'll contend that my addition isn't all that intrusive... the only way it "wakes up" is if acs_objects.title is non blank, and only then if the title follows the form "#pkg_key.msg_key#".

If the query after that finds there IS something in the message, that text is used as the object name, so I'm letting the original developer finish his work... or not, and either way, aca_object__name() (well, my version) tries a little harder to come up with a nonblank object name. If someone changes group__new() so that it puts the group name in the lang_messages table, my code will use that name.

The only way acs_object__name() can lose now, is if there does not exist a name method for the object type (or for any supertypes), or the name method itself returns blank.


Posted by Gustaf Neumann on
i am still confused, what the intention of your posting is: are you reporting a bug or do you want to discuss some extensions? What does "Recently, someone altered acs_group__new() so that it would add a row to the lang_messages table" refer to? Please be more precise.

If "title" in acs_objects is not specified, it should be NULL, if it is specified as the empty string, then it should be ''.

Posted by Jim Lynch on

This is a bug report with a suggested fix. The bug is, acs_object__name() returns a string from acs_objecs.title that looks like (pound sign)acs-translations.group_title_2702(pound sign), which gets looked up. The value it returns (from the table lang_messages) is blank, so that's what the old version of acs_object__name() returns. The "Recently..." comment refers to that change, which may not be complete.

To shed light on the problem, try this:

  • Create an application_group,
  • Find its object_id,
  • In psql, run: select title from acs_objects where object_id = theGroupId;
  • Still in psql, run: select acs_object__name(theGroupID);
  • Still psql, run select message from lang_messages where psckage_key = 'acs-translations' and message_key = 'group_title_(theGroupID)';
  • You should notice that the result of this query is either blank or null, and is why blank is displayed when group names are displayed.
My intent for my change to acs_object__name() is to fix the blank-group-name problem and be sufficiently nonintrusive so that (1) I'm avoiding interfering with the developer who started this change, and (2) acs_object__name() should work whether he completes his work or not.


Posted by Gustaf Neumann on

the best place for bug reports is the bug tracker. The result below looks ok to me.

Do you get different results for acs_object__name()? I still don't see the connection with acs-translations.

-g select object_id, title from acs_objects where object_type = 'application_group';
 object_id |           title            
      3830 | Main Site Parties
     44322 | OpenACS Parties
     46079 | demo Parties
     46194 | Test Subsite Parties
     46238 | Projects Parties
     46273 | OpenACS Subsite Parties
     47519 | dotWRK Parties
     57366 | dotLRN Parties
    128847 | OpenACS Governance Parties
    179469 | CVS Committers
(10 rows) select acs_object__name(3830);
 Main Site Parties
(1 row) select message from lang_messages where package_key = 'acs-translations';
(0 rows)

Posted by Jim Lynch on

You're right, the titles look good, and, those groups have been around on ro maybe 10 or 20 years.

What do you find on a group created today or so?


Posted by Gustaf Neumann on
Applications groups created today don't look different. Today in ds/shell:
application_group::new -group_name foo
in psql select object_id, title, creation_date from acs_objects where object_type = 'application_group';
 object_id |           title            |         creation_date         
      3830 | Main Site Parties          | 2002-07-11 22:08:20+02
     44322 | OpenACS Parties            | 2002-08-12 21:20:32+02
     46079 | demo Parties               | 2002-08-13 20:47:17+02
     46194 | Test Subsite Parties       | 2002-08-20 21:44:29+02
     46238 | Projects Parties           | 2002-08-20 21:48:27+02
     46273 | OpenACS Subsite Parties    | 2002-08-20 21:52:09+02
     47519 | dotWRK Parties             | 2002-09-23 23:10:55+02
     57366 | dotLRN Parties             | 2002-10-31 17:21:02+01
    128847 | OpenACS Governance Parties | 2003-09-28 20:15:03.255242+02
    179469 | CVS Committers             | 2004-05-04 10:52:55.872763+02
   4216650 | foo                        | 2015-01-02 09:06:42.58954+01
(11 rows) select acs_object__name(4216650);
(1 row)
Do you get different results?


Posted by Jim Lynch on
sorry for delay... I have some results to show you, but first do you happen to know the &#...; for #?


Posted by Benjamin Brink on
Posted by Jim Lynch on

Hi, here are the results...

using this query:

            acs_objects o,
            lang_messages m,
            (select object_id, regexp_matches(title, '#([^.#]*).([^.#]*)#') as matcha from acs_objects) r
            o.object_id = r.object_id
            r.matcha[1] = m.package_key
            r.matcha[2] = m.message_key
            (m.message is null or m.message = '')
        order by 
I get:

    object_type    | creation_date |                title                
 application_group | 2014-02-05    | #acs-translations.group_title_1727#
 application_group | 2014-02-23    | #acs-translations.group_title_1958#
 application_group | 2014-12-22    | #acs-translations.group_title_2702#
(3 rows)
without the \ char at the start of the title field.

Posted by Jim Lynch on
without the r and lang_message NULL or '', I get 70 rows.
Posted by Jim Lynch on
As far as intent for posting, yes, this is a bug report (with suggested fix), and I'm also totally willing to discuss this way potentially other ways to solve it.