Home
The Toolkit for Online Communities
17239 Community Members, 0 members online, 1879 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Development : persons tcl api

Forum OpenACS Development: persons tcl api

Icon of envelope Request notifications

Collapse
Posted by Dan Chak on
I noticed there is no tcl api for the acs_object 'person'.  To
facilitate using the persons table, I'm going to write a simple tcl
api around the plsql procs that already exist.

If anyone has any suggestions for things they'd like to see in the
api, please let me know.

Collapse
Posted by Jim Lynch on
Other than the basic constructors and selectors, I'd like to be able to get ordered lists of person_ids, where the persons are ordered by first or last name; also, I want to be able to find a person by name, find all persons who have a given last_name or persons who have a given first name in their first_names column.

I'd like for a person to be able to have a list of secondary emails, each having a send-to radio button flag: any message which would be sent to the user would be sent to the selected email address, either instead of, or in addition to, the primary address. The person should have the option of showing any, all or -none- of his/her email addresses. If none, then the only emails sent by the server to the person's primary email address and/or selected secondary address would be alerts and admin. Hence, the person can still participate in collaborative activities as facilitated by the site without getting spammed by anyone.

Finally, bboard postings should appear to originate from the original poster, NOT the server (as is the case with openacs.org). The subject line of the email should be the item to identify to the mail recipient that the email came from a particular thread of a particular forum. Perhaps this should be optional: an email sender should be able to say to the server "cloak my address" or "bboard notifications of messages I post should appear to originate from me". In any case, openacs.org doesn't tell me who the poster is (maybe I want to filter spam on the basis of email address), which thread this is part of (maybe I want to try to form a threadded offline list to read) or what forum the message comes from (maybe I want to put messages from certain forums into a local folder).

Yes, OK, so I went a little off the "persons tcl api" track... however, if any of this more-general preferences statement leaks into the persons api, and if said api becomes better for it, that's good enough for me :)

Collapse
Posted by Jon Griffin on
I am almost done with the new acs-persons package, and should have a first cut done today. This can be standalone or integrated with the myopic support for persons that exists already.

This follows the HR-XML standard, see other posts for more info.

Collapse
Posted by Dan Chak on
John & others, All I was looking for here was a simple api so that person's could be modified via tcl rather than having to use the plsql calls directly. Here is the simple starting point:
namespace eval person {
    
    ad_proc -public new {
        {-first_names:required}
        {-last_name:required}
    } {
        create a new person
    } {
       
        set extra_vars [ns_set create]
        ns_set put $extra_vars first_names $first_names
        ns_set put $extra_vars last_name $last_name

        set object_type "person"
        return [package_instantiate_object -extra_vars $extra_vars $object_type]
    }

    ad_proc -public delete {
        {-person_id:required}
    } {
        delete a person
    } {
        db_exec_plsql delete_person {}
    }

    ad_proc -public get {
        {-person_id:required} 
    } {
        get info for a person as a tcl array in list form
    } {
        db_1row get_person {}
        
        set person(person_id) $person_id
        set person(first_names) $first_names
        set person(last_name) $last_names

        return [array get person]
    }

    ad_proc -public name {
        {-person_id:required}
    } {
        get the name of a person
    } {
        db_1row get_person_name {}
        return $person_name
    }

    ad_proc -public update {
        {-person_id:required}
        {-first_names:required}
        {-last_name:required}
    } {
        update the name of a person
    } {
        db_dml update_person {}
    }
}

Jim, I like some of your ideas relating to searching the first/last names of persons.

John, does your hr-xml implementation take care of these simple things as well?

Collapse
Posted by Jon Griffin on
I haven't written a tcl-api only because I haven't finished everything, but yes.

It will do all that and more. Names will actually be correct (both politically and technically) and it will have export capabilities also.

Collapse
Posted by Ben Adida on
Jon: given that this API doesn't add any features, only convenience wrappers
that makes other code really clean, it seems okay to commit this and use it as
is, then eventually merge into your more complete scheme, right?
Collapse
Posted by Jon Griffin on
Definitly, the new package won't really change anything in the core as it can be used as a standalone entity.

It will have a foreign key to the person table for extending the data in the core.

Collapse
Posted by Dan Chak on
Ok, I have commited that snippet of code (above).  This adds the following wrappers to the person plsql stuff:  person::new, person::delete, person::update, and person::get.

please use at will.

-dan

Collapse
Posted by Jim Lynch on
Yes, I forgot about the export capabilities... I'm glad you mentioned them.

Recently, I wanted to move a bunch of users from one oacs to a newer one, so I wrote some stuff (note: this link might go dead; apologies in advance) to export and then later import users. I wanted them to feel at home as much as they did before, so I wanted to preserve the creation ip and creation date, as well as their password. All this worked well, but it seems to me that this capability could be built into (or built with) the persons api.

Would xml be a better way to encode the data?

Collapse
Posted by Lars Pind on
Dan,

There's an option -column_array to the db_ procs that means you can rewrite your ::get function like this:

ad_proc -public get {
    {-person_id:required} 
} {
    get info for a person as a tcl array in list form
} {
    db_1row get_person {} -column_array person
    return [array get person]
}
Not terribly important, just a little FYI.

/Lars

Collapse
Posted by Dan Chak on
Lars,

that's very good info to know.  thanks!

-dan

Collapse
Posted by Roberto Mello on
The -column_array option wasn't documented in some places of the db api documentation. I fixed that in my db api documentation walk-through (can't say it was a revamp) a couple weeks ago. The changes will be in the next openacs release.