[geeklog-devel] Custom user attributes in GL2

Blaine Lang geeklog at langfamily.ca
Thu Dec 16 01:30:24 EST 2004


I like the idea of a flexible table driven set of site-defined userprofile 
fields that could be used for registration or for extending the user 
profile.
This could be a plugin as it could be a plugin today in 1.3.X

I recently developed a formEditor plugin that allows you to create a form 
that has any number of fields from a wide array of field types.
I used one table to define the fields for all forms where fieldtype is just 
a varchar that is one of the plugin defined types.
When I display the form, I either use a default layout or a custom template 
if assigned.

We can do the same and it's pretty flexible.
Fields would need to include:
- id
- field_type  (varchar 32)
- field_attributes   - if we are using a default layout, you need this
- field_order
- label   (or linked to language independant feature)
- required_for_registration
- is_manditory


----- Original Message ----- 
From: "Tony Bibbs" <tony at tonybibbs.com>
To: <geeklog-devel at lists.geeklog.net>
Sent: Wednesday, December 15, 2004 5:41 PM
Subject: Re: [geeklog-devel] Custom user attributes in GL2


Your saying the same thing I am.  I was bit confused by Vinny's response
which sounded a bit like (put everything in there) which I am guessing
he didn't mean but I wanted to be perfectly clear on.  I think your
table will be more complicated...you'll probably want things like
min/max values, required indicators, etc.  That's in addition to the
ability to choose from a finite set of values.

The more I think about it, the more I think we might want to delay doing
anything with customer user attributes until we get to a point where the
kernel is up and plugins are being written.  Thoughts?

--Tony

dwight at trumbower.com wrote:

>Ok, I'm confused. I don't see username and password as custom attributes.
>
>Custom attributes are usually used to enhance the base package and allow
>customers to add a few fields of data to customize a screen. The old days,
>you just created 5-10 fields, called user1, user2,...user10. So every
>table had 10 extra fields.
>
>The new way puts only the fields you want in a combined table, just like
>your List Of Values(LOV) table.
>
>The hard part is displaying these fields. The easiest way is to have them
>all grouped together at the end of a screen. Know when people want to move
>them around in different places, it gets tricky.
>
>Also if you need to handle select option fields, radio fields and check
>box fields there will need some more supporting tables.
>
>
>Dwight
>
>
>
>
>
>>I'm fine with data driving the custom user stuff..l
>>
>>I would still say, though, you'd want real columns in the GL2 user table
>>for thing we know we need (i.e. username, password, etc) for performance
>>reasons alone, right?  Regardless, going this route will make the use of
>>Propel a little bit messy as the user class generated by propel won't
>>know anything about the custom attributes in the database.
>>
>>Also, for clarity, are you suggesting we do this for all plugin specific
>>user attributes?  I don't think you are and if you are we probably want
>>to discuss the pros/cons between that and having a plugins specific user
>>table with a one-to-one relationship with the kernel user table.
>>
>>--Tony
>>
>>Vincent Furia wrote:
>>
>>
>>
>>>I'm with Dwight.  This way all user data is in one place (and the
>>>plugins can put user data there as well).
>>>
>>>-Vinny
>>>
>>>
>>>On Wed, 15 Dec 2004 16:16:44 -0500 (EST), dwight at trumbower.com
>>><dwight at trumbower.com> wrote:
>>>
>>>
>>>
>>>
>>>>The easiest way I know of, one table.
>>>>
>>>>column name - String
>>>>column type - specifies, long, int, string ect
>>>>column data - data as a string
>>>>
>>>>Might need xref table to show where it is used. At least this is how
>>>>would
>>>>start.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Anybody have any input on how to best address providing the community
>>>>>with fairly easy way to add custom attributes for users in GL2?
>>>>>
>>>>>I don't I have a good idea on how to do this.  My hopes are that
>>>>>plugins
>>>>>would have their own one-to-one mapping from the core user table to
>>>>>their own user table with addition information.  Assuming that is OK,
>>>>>how do we handle things the site admin simply wants to add (e.g. msn
>>>>>id,
>>>>>pgp key, etc).
>>>>>
>>>>>--Tony
>>>>>_______________________________________________
>>>>>geeklog-devel mailing list
>>>>>geeklog-devel at lists.geeklog.net
>>>>>http://lists.geeklog.net/listinfo/geeklog-devel
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>_______________________________________________
>>>>geeklog-devel mailing list
>>>>geeklog-devel at lists.geeklog.net
>>>>http://lists.geeklog.net/listinfo/geeklog-devel
>>>>
>>>>
>>>>
>>>>
>>>>
>>>_______________________________________________
>>>geeklog-devel mailing list
>>>geeklog-devel at lists.geeklog.net
>>>http://lists.geeklog.net/listinfo/geeklog-devel
>>>
>>>
>>>
>>>
>>_______________________________________________
>>geeklog-devel mailing list
>>geeklog-devel at lists.geeklog.net
>>http://lists.geeklog.net/listinfo/geeklog-devel
>>
>>
>>
>
>_______________________________________________
>geeklog-devel mailing list
>geeklog-devel at lists.geeklog.net
>http://lists.geeklog.net/listinfo/geeklog-devel
>
>

_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://lists.geeklog.net/listinfo/geeklog-devel 




More information about the geeklog-devel mailing list