Forum OpenACS Development: Porting Notes - Take 2

Collapse
1: Porting Notes - Take 2
Posted by Jon Griffin on 05/23/01 07:12 AM
In porting and debugging I have come across 2 things that bug the #$% ^ out of me.

  • Email for login - I know that I am not the only one who has had requests for not using email as a means of identifying a member. In fact most sites I surveyed don't require email and instead use a handle or username. This is fixable in Classic but a major pain if you want to upgrade. It is actually more legacy cruff leftover from long ago
  • Hardcoded values - My personal pet peeve is seeing reference data or lookups that have hardcoded (either by pl/sql or tcl) values. It is lazy programming at its worst. I can't think of many cases (booleans, y/n, etc, and even y/n could turn to maybe!) where a simple table lookup wouldn't be infinitly more flexible.
In regards to #1 I have taken some steps on a friends site to eliminate this crappy need for using email for a login. (His site demands privacy and people won't readily signup if they feel you are asking for something personal. Or, worse, they just put bill@msn.com). I will put up my notes when I get them in shape.

As for #2, Porters please keep this in mind when you port and think of the fixes for the bad data modelling we need to fix.

Collapse
2: Response to Porting Notes - Take 2 (response to 1)
Posted by Tom Jackson on 05/23/01 08:42 AM

Actually all you need to do to not use the email as the user identifier is to not check to see if the format of the input is an email address, and label your login field accordingly. Of course then you need another place for the email, if you still need one.

One problem with using the email as the login_id is that it is in the parties table. Parties are a parent object of registered users / acs users etc. So whatever is used to log people in should probably be in the table that includes only registered users. Probably a login_id field in the users table, that could accommodate an email address or any other string. It would be nice to have a config switch: LoginIsEmailP, to include the proper checks in the /register/* pages. It is still going to take a lot of hacking on those pages to make it work.

Collapse
3: Response to Porting Notes - Take 2 (response to 1)
Posted by Don Baccus on 05/23/01 04:14 PM
The use of an e-mail address should be configurable by the site owner.  Of course, if the site's configured to require e-mail confirmation of  registration then we need to either require a valid e-mail address as the user name or make a separate e-mail address mandantory if we allow  arbitrary user names.

On your second point, yes, hardcoded values shouldn't be used unless one knows they won't change.  "deleted/not deleted" makes sense as a boolean, but those of us who've been around awhile have seen the evolution from "approved_p" to "users_state", i.e. a multi-state approval policy.  Many other former booleans have evolved in the same way.  We should avoid falling into the simple trap of mapping state values onto boolean unless we can really convince ourselves that only two states will suffice forever.

Collapse
4: Response to Porting Notes - Take 2 (response to 1)
Posted by Michael Feldstein on 05/26/01 12:50 AM
I'm not sure if I'm understanding this discussion correctly, but it
seems to me that the issue of email-as-login is also a problem
for folks who want to change their email address in the system.
My understanding is that in current ACS email is the "primary
key" (hope I'm using that term correctly), so all other user info is
tied to it. In this world of ever-changing email addresses, this
strikes me as a stupid way of doing things.
Collapse
5: Response to Porting Notes - Take 2 (response to 1)
Posted by Tom Jackson on 05/26/01 01:25 AM

The email is not a primary key in the parties table, but it does have a uniqueness constraint. The primary key is party_id and is used as an identifier throughout the system and doesn't need to change.

Note also that all objects in ACS 4 reference an acs_object(object_id). I think the hierarchy for a acs_user is: 

acs_objects
 parties
  persons
   users
    acs_users