[geeklog-devtalk] geeklog-devel digest, Vol 1 #453 - 6 msgs

[geeklog-devel-request at lists.geeklog.net]

Send geeklog-devel mailing list submissions to
	geeklog-devel at lists.geeklog.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.geeklog.net/listinfo/geeklog-devel
or, via email, send a message with subject or body 'help' to
	geeklog-devel-request at lists.geeklog.net

You can reach the person managing the list at
	geeklog-devel-admin at lists.geeklog.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of geeklog-devel digest..."


Today's Topics:

   1. Re: Custom user attributes in GL2 (Vincent Furia)
   2. Re: Draft of schema for GL2 (Vincent Furia)
   3. Re: Custom user attributes in GL2 (Tony Bibbs)
   4. Re: Blocks in GL2 as Plugin? (Vincent Furia)
   5. Re: Custom user attributes in GL2 (Vincent Furia)
   6. Re: Draft of schema for GL2 (Tony Bibbs)

--__--__--

Message: 1
Date: Wed, 15 Dec 2004 21:00:42 -0500
From: Vincent Furia <vfuria at gmail.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Custom user attributes in GL2
Reply-To: geeklog-devel at lists.geeklog.net

How about this: do the absolute minimum and create a plugin to handle
custom user info.  That fits more with our paradigm, right?

-Vinny

On Wed, 15 Dec 2004 16:41:15 -0600, Tony Bibbs <tony at tonybibbs.com> wrote:

> 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

>


--__--__--

Message: 2
Date: Wed, 15 Dec 2004 22:49:19 -0500
From: Vincent Furia <vfuria at gmail.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Draft of schema for GL2
Reply-To: geeklog-devel at lists.geeklog.net

Comments in line, hopefully this method of commenting will work...

On Wed, 15 Dec 2004 16:38:22 -0600, Tony Bibbs <tony at tonybibbs.com> wrote:

> CREATE TABLE gl2_list_of_values (

>   lov_id int unsigned NOT NULL auto_increment,

>   group_name varchar(30) NOT NULL,

>   short_name varchar(40) NOT NULL,

>   description varchar(128),

>   enabled tinyint NOT NULL DEFAULT 1,

>   sort_order mediumint NOT NULL DEFAULT '0',

>   PRIMARY KEY (lov_id),

>   INDEX (group_name),

>   INDEX (short_name),

>   INDEX (enabled)

> ) TYPE=INNODB;

I just don't like the name, but I can't come up with anything better
(how is that for useless input?).


> CREATE TABLE gl2_event (

Another name issue, this one with a suggestion and a valid reason:
What about "action" instead of "event" the problem here is a language
domain collision between our idea of gl2 events vs. calendar events. 
"action" is a possible replacement, so is "act" or any synonym that
makes sense.  I'm open to suggestions, but I think "event" needs to
change.  (And I know, I'm the one who called them "events" to begin
with).


>   event_id int unsigned NOT NULL auto_increment,

>   event_name varchar(40) NOT NULL,

NEW COLUMN: event_plugin_id int unsigned NOT NULL DESC force events to
be associated with a specific plugin


>   description varchar (255) NOT NULL,

>   PRIMARY KEY(event_id),

>   INDEX(event_name)

> ) TYPE=INNODB;

> 

> CREATE TABLE gl2_plugin (

>   plugin_id int unsigned NOT NULL auto_increment,

>   plugin_name varchar(128) NOT NULL,

>   version varchar(20) NOT NULL,

>   homepage varchar(128) NOT NULL,

>   enabled tinyint unsigned NOT NULL DEFAULT 1,

>   PRIMARY KEY(plugin_id),

>   INDEX(plugin_name),

>   INDEX(enabled)

> ) TYPE=INNODB;

We might want to require that version be a float (or int?) so that we
can do version dependency checking with some reasonable results. 
(i.e. check for version of forum >= 2.3).


> 

> CREATE TABLE gl2_eventListener (

>   event_id int unsigned NOT NULL,

>   plugin_id int unsigned NOT NULL,

>   PRIMARY KEY(event_id, plugin_id),

>   FOREIGN KEY (event_id) REFERENCES gl2_event(event_id),

>   FOREIGN KEY (plugin_id) REFERENCES gl2_plugin(plugin_id)

> ) TYPE=INNODB;

> 

> CREATE TABLE gl2_user (

>   user_id int unsigned NOT NULL auto_increment,

>   registration_date int unsigned NOT NULL,

>   profile_views mediumint unsigned NOT NULL DEFAULT 0,

we should consider keeping counts in a separate table, hopefully this
will prevent the locking issues previously experienced with article
view counts.  We could recommend that plugins use the same table as
needed.


>   items_per_page tinyint unsigned NOT NULL DEFAULT 10,

>   language_id int unsigned NOT NULL,

>   user_name varchar(25) NOT NULL,

>   password varchar(35) NOT NULL,

>   enabled tinyint unsigned NOT NULL,

>   email VARCHAR(128) NOT NULL,

>   comment_mode_id int unsigned NOT NULL,

>   comment_order_id int unsigned NOT NULL,

>   comment_limit tinyint unsigned NOT NULL default '0',

>   cookie_timeout int unsigned NOT NULL,

>   locale varchar(3),

>   date_format_id int unsigned NOT NULL,

>   blocks_enabled tinyint unsigned DEFAULT 1,

>   PRIMARY KEY(user_id),

>   INDEX (user_name),

>   INDEX (enabled),

>   INDEX (email),

>   FOREIGN KEY (comment_mode_id) REFERENCES gl2_list_of_values(lov_id),

>   FOREIGN KEY (comment_order_id) REFERENCES gl2_list_of_values(lov_id),

>   FOREIGN KEY (date_format_id) REFERENCES gl2_list_of_values(lov_id)

> ) TYPE=INNODB;

> 

> CREATE TABLE gl2_user_supp (

>   user_id int unsigned NOT NULL,

>   signature varchar(128),

>   biography text,

>   first_name varchar(30),

>   last_name varchar(30),

>   homepage varchar(50),

>   PRIMARY KEY(user_id),

>   FOREIGN KEY(user_id) REFERENCES gl2_user(user_id),

> ) TYPE=INNODB;

I think this table should be combined with the gl2_user.  I like the
idea of having a plugin that will handle supplemental user
information.


> 

> CREATE TABLE gl2_group (

>   group_id int unsigned NOT NULL auto_increment,

>   logical_name varchar(30) NOT NULL,

>   display_name varchar(50) NOT NULL,

>   description varchar(255) NOT NULL,

> ) TYPE=INNODB;

What is the difference between a "logical name" and a "display name"? 
Is differentiating them necessary?


> 

> CREATE TABLE gl2_privilege (

>   code varchar(30) NOT NULL,

>   description varchar(255) NOT NULL,

>   PRIMARY KEY(code)

> ) TYPE=INNODB;

> 

> CREATE TABLE gl2_privilege_access (

>   code varchar(30) NOT NULL,

>   user_id int unsigned,

>   group_id int unsigned,

>   INDEX(code),

>   FOREIGN KEY(user_id) REFERENCES gl2_user(user_id),

>   FOREIGN KEY(group_id) REFERENCES gl2_group(group_id)

> ) TYPE=INNODB;

> 

> CREATE TABLE gl2_group_assignment (

>   main_group_id int unsigned NOT NULL,

>   assigned_user_id int unsigned,

>   assigned_group_id int unsigned,

>   FOREIGN KEY(main_group_id) REFERENCES gl2_group(group_id),

>   FOREIGN KEY(assigned_user_id) REFERENCES gl2_user(user_id),

>   FOREIGN KEY(assigned_group_id) REFERENCES gl2_group(group_id)

> ) TYPE=INNODB;

> 

> CREATE TABLE gl2_ban (

>   ban_id int unsigned NOT NULL auto_increment,

>   user_id int unsigned,

>   ip_address varchar(11),

>   start_date int unsigned NOT NULL,

>   end_date int unsigned NOT NULL,

>   reason_id int unsigned NOT NULL,

>   PRIMARY KEY(ban_id),

>   FOREIGN KEY(user_id) REFERENCES gl2_user(user_id),

>   FOREIGN KEY(reason_id) REFERENCES gl2_list_of_values(lov_id)

> ) TYPE=INNODB;

I think ban should be a plugin...


> 

> CREATE TABLE gl2_catalog (

>   catalog_id mediumint unsigned NOT NULL auto_increment,

>   catalog_name varchar(50) NOT NULL

>   date_created int unsigned NOT NULL

> ) TYPE=INNODB;

A catalog is just a set of categories correct?  Why not keep that info
in the gl2_category table?  (i.e. what's the justification for a
separate table).  Alternatively should it just go in the
list_of_values table?  Why keep the date created?


> 

> CREATE TABLE gl2_category (

>   category_id mediumint unsigned NOT NULL,

>   catalog_id mediumint unsigned NOT NULL,

>   category_name varchar NOT NULL,

>   parent_category_id mediumint unsigned NOT NULL,

>   image_url VARCHAR(128) DEFAULT 'NULL',

>   sort_num tinyint unsigned DEFAULT NULL,

>   enabled tinyint unsigned NOT NULL DEFAULT 1,

>   owner_id int unsigned NOT NULL,

>   group_id mediumint unsigned NOT NULL,

>   owner_permissions tinyint unsigned NOT NULL,

>   anon_permissions tinyint unsigned NOT NULL,

>   member_permissions tinyint NOT NULL,

>   group_permissions tinyint NOT NULL,

>   FOREIGN KEY (catalog_id) REFERENCES gl2_catalog(catalog_id),

>   INDEX (enabled)

> ) TYPE=INNODB;

Should we use the modified preorder traversal numbering to store the
hierarchical structure of the categories within a catalog (i.e. like
comments in 1.3.10)?  All the owner/group id and permissions stuff
should be removed...just use the acl table.  We don't want to deal
with two different systems for determining permissions.  In fact, why
not make categories "items"?  (then categories can be in categories,
won't that be cool?)


> 

> CREATE TABLE gl2_item (

>   item_id int unsigned NOT NULL auto_increment,

>   type_id int unsigned NOT NULL,

>   user_id int unsigned NOT NULL,

>   category_id INT unsigned NOT NULL,

>   date_created int unsigned NOT NULL,

>   num_views mediumint unsigned NOT NULL DEFAULT 0,

>   state_id int unsigned NOT NULL,

>   num_emails mediumint unsigned NOT NULL DEFAULT 0,

I think the num_views and num_emails should be moved to a separate
table (see gl2_user table above).


>   num_ratings mediumint unsigned NOT NULL DEFAULT 0,

>   rating_sum int unsigned NOT NULL DEFAULT 0,

I think ratings should be handled by a plugin.


>   expiration_date int unsigned DEFAULT NULL,

>   parent_item_id int unsigned DEFAULT NULL,

NEW COLUMN: enabled tinyint DEFAULT 1 DESC have the ability to "switch
off" items.


>   PRIMARY KEY(item_id),

>   FOREIGN KEY(type_id) REFERENCES gl2_list_of_values(lov_id),

>   FOREIGN KEY(user_id) REFERENCES gl2_user(user_id),

>   FOREIGN KEY(category_id) REFERENCES gl2_catgory(category_id),

>   FOREIGN KEY(state_id) REFERENCES gl2_item_type_state(state_id),

>   FOREIGN KEY(parent_item_id) REFERENCES gl2_item(item_id)

> ) TYPE=INNODB;

Do we want an association table between items and categories so items
can be in multiple categories?


> 

> CREATE TABLE gl2_item_acl (

>   acl_id int unsigned NOT NULL auto_increment,

>   item_id int unsigned NOT NULL,

>   user_id int unsigned,

>   group_id int unsigned,

>   rights smallint unsigned NOT NULL,

>   PRIMARY KEY(acl_id),

>   FOREIGN KEY(item_id) REFERENCES gl2_item(item_id),

>   FOREIGN KEY(user_id) REFERENCES gl2_user(user_id),

>   FOREIGN KEY(group_id) REFERENCES gl2_group(group_id)

> ) TYPE=INNODB;

Looks good


> 

> CREATE TABLE gl2_comment (

>   comment_id int unsigned NOT NULL auto_increment,

>   item_id int unsigned NOT NULL,

>   subject varchar(50) NOT NULL,

>   comment_text text NOT NULL,

>   parent_id int unsigned,

>   ip_address varchar(11) NOT NULL

>   PRIMARY KEY(comment_id),

>   FOREIGN KEY(item_id) REFERENCES gl2_item(item_id),

>   FOREIGN KEY(parent_id) REFERENCES gl2_comment(comment_id)

> ) TYPE=INNODB;

Should comments be a plugin?  That way if you want a "forum like"
comment vs traditional system you can just switch out the plugin?  If
you really (REALLY) want this do you want to keep the hierarchical
comment structure we added to 1.3.10 (modified preorder traversal)


> 

> CREATE TABLE gl2_item_type_state (

>   state_id int unsigned NOT NULL auto_increment,

>   type_id int unsigned NOT NULL,

>   state_name varchar(30) NOT NULL,

>   description varchar(255),

>   PRIMARY KEY(state_id),

>   FOREIGN KEY(type_id) REFERENCES gl2_list_of_values(lov_id)

> ) TYPE=INNODB;

If these are going to be different for different items, shouldn't it
be kept by the individual plugin managing the item?

--__--__--

Message: 3
Date: Wed, 15 Dec 2004 21:49:08 -0600
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Custom user attributes in GL2
Reply-To: geeklog-devel at lists.geeklog.net

DIng, ding, ding I think we have a winner.

Only thing is how you would customize the content based on the existence 
(or lack thereof) of such a plugin.

--Tony

Vincent Furia wrote:


>How about this: do the absolute minimum and create a plugin to handle

>custom user info.  That fits more with our paradigm, right?

>

>-Vinny

>

>On Wed, 15 Dec 2004 16:41:15 -0600, Tony Bibbs <tony at tonybibbs.com> wrote:

>  

>

>>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

>>

>>    

>>

>_______________________________________________

>geeklog-devel mailing list

>geeklog-devel at lists.geeklog.net

>http://lists.geeklog.net/listinfo/geeklog-devel

>  

>



--__--__--

Message: 4
Date: Wed, 15 Dec 2004 22:53:18 -0500
From: Vincent Furia <vfuria at gmail.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Blocks in GL2 as Plugin?
Reply-To: geeklog-devel at lists.geeklog.net

Instead of a "block plugin" how about individual plugins be able to
generate blocks as they want (and how the admin configures).  This can
even include "center block" stuff.  We could have a generic plugin
that is available for adding random blocks.  Also we could have a
totally separate plugin to handle RDF/RSS blocks.  More complicated
blocks, say a weather block, could be their own plugin.

-Vinny

On Wed, 15 Dec 2004 13:55:58 -0600, Tony Bibbs <tony at tonybibbs.com> wrote:

> Were any of you thinking blocks would be part of the actual GL2 kernel

> or should they exist, instead, as a plugin?  The more I think of it, the

> more I think they are simply a plugin...though, they will probably be

> used to render content served up by nearly every other plugin that would

> be installed.

> 

> --Tony

> _______________________________________________

> geeklog-devel mailing list

> geeklog-devel at lists.geeklog.net

> http://lists.geeklog.net/listinfo/geeklog-devel

>


--__--__--

Message: 5
Date: Wed, 15 Dec 2004 23:00:06 -0500
From: Vincent Furia <vfuria at gmail.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Custom user attributes in GL2
Reply-To: geeklog-devel at lists.geeklog.net

On Wed, 15 Dec 2004 21:49:08 -0600, Tony Bibbs <tony at tonybibbs.com> wrote:

> DIng, ding, ding I think we have a winner.

> 

> Only thing is how you would customize the content based on the existence

> (or lack thereof) of such a plugin.

That is the entire idea behind the 'event' architecture.  When
displaying a profile page, core GL2 just triggers an event, if any
plugin is listening it can respond...  Think 1.3.x plugin hooks on
drugs.

-Vinny

--__--__--

Message: 6
Date: Wed, 15 Dec 2004 22:19:05 -0600
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Draft of schema for GL2
Reply-To: geeklog-devel at lists.geeklog.net

Great feedback.  My comments below

Vincent Furia wrote:


>I just don't like the name, but I can't come up with anything better

>(how is that for useless input?).

>  

>

Lol, yeah, pretty useless.  I'm open to suggestions should one hit you.


>Another name issue, this one with a suggestion and a valid reason:

>What about "action" instead of "event" the problem here is a language

>domain collision between our idea of gl2 events vs. calendar events. 

>"action" is a possible replacement, so is "act" or any synonym that

>makes sense.  I'm open to suggestions, but I think "event" needs to

>change.  (And I know, I'm the one who called them "events" to begin

>with).

>  

>

gl2_action is fine by me.  However, just as we have namespace issues in 
the code with class names we could have similar issues with table names 
between plugins. I think we should try to address this with some sort of 
standard, if possible.


>NEW COLUMN: event_plugin_id int unsigned NOT NULL DESC force events to

>be associated with a specific plugin

>  

>

I thought the same thing.  Only question I have is what about 
kernel-based actions?


>We might want to require that version be a float (or int?) so that we

>can do version dependency checking with some reasonable results. 

>(i.e. check for version of forum >= 2.3).

>  

>

Yeah, makes sense.


>we should consider keeping counts in a separate table, hopefully this

>will prevent the locking issues previously experienced with article

>view counts.  We could recommend that plugins use the same table as

>needed.

>  

>

Where's the DBMS trigger feature when you need it?  Are the locking 
issues still an issue with INNODB table types?  Does moving them to a 
separate table really get rid of the problem?  Seem you'd still have a 
problem with locking, though, not as much.


>I think this table should be combined with the gl2_user.  I like the

>idea of having a plugin that will handle supplemental user

>information.

>  

>

I'm OK with this.  I don't like all the different user tables in 1.3.x. 


>What is the difference between a "logical name" and a "display name"? 

>Is differentiating them necessary?

>  

>

Logical name would be what you use in security checks.  Something like 
today's SEC_inGroup('story_admin').  story_admin would be the logical 
name.  However when you show the name of the group, say, on a group 
administration page you would see Story Admin.  By splitting the two you 
could, in theory, change the name of the group without breaking your 
code granted you keep the logical name the smae.


>I think ban should be a plugin...

>  

>

Hrm, never really thought of that.  Any implications against doing this?


>A catalog is just a set of categories correct?  Why not keep that info

>in the gl2_category table?  (i.e. what's the justification for a

>separate table).  Alternatively should it just go in the

>list_of_values table?  Why keep the date created?

>  

>

The idea here is that plugins can quickly reuse these structures should 
they have a need to categorize some amount of data.  Thus, the links 
plugin would have it's own catalog different form the story plugin's 
categories.  Putting the catalogs in the list of values makes sense.


>Should we use the modified preorder traversal numbering to store the

>hierarchical structure of the categories within a catalog (i.e. like

>comments in 1.3.10)? 

>

Hrm, haven't even looked at the .10 code.  If I hear you what you are 
saying is we essentially cache the hierarchy instead of having expensive 
recursive method calls to build it in real time.  I'd be fine with that. 
I'll look at the .10 schema and make needed changes.


>All the owner/group id and permissions stuff

>should be removed...just use the acl table.  We don't want to deal

>with two different systems for determining permissions.  In fact, why

>not make categories "items"?  (then categories can be in categories,

>won't that be cool?)

>  

>

Yeah, not sure how that snuck in there.


>I think the num_views and num_emails should be moved to a separate

>table (see gl2_user table above).

>  

>

I agree we should handle counts in a consistent manner.  The locking 
issues are all I'm interested in figuring out before we decide on a 
direction.


>I think ratings should be handled by a plugin.

>  

>

Could, but I think this is a basic need for almost all plugins.  In 
fact, this could even be expanded to users.  I could be convinced 
otherwise.  We all want the GL2 kernel to be as lean and mean as 
possible but I think we also want to ensure that anything in the kernel 
is truly a resource that will be needed other plugins. 


>NEW COLUMN: enabled tinyint DEFAULT 1 DESC have the ability to "switch

>off" items.

>  

>

Agreed.


>Do we want an association table between items and categories so items

>can be in multiple categories?

>  

>

Good question. It gives more flexibility...a tad bit more complexity.  
Any objections?


>Looks good

>  

>

Should be, you created th ACL table ;-)


>Should comments be a plugin?  That way if you want a "forum like"

>comment vs traditional system you can just switch out the plugin?  If

>you really (REALLY) want this do you want to keep the hierarchical

>comment structure we added to 1.3.10 (modified preorder traversal)

>

>  

>

I lump this in with the same issue with the ban plugin.  It's a basic 
decision as to what should be considered part of the kernel versus 
something that isn't.  I think this begs the need for a basic set of 
criteria that we agree on that should help us determine if something 
should be a plugin or in the kernel code.


>If these are going to be different for different items, shouldn't it

>be kept by the individual plugin managing the item?

>  

>

What I was trying to achieve here is a plugin would insert a new set of 
item types (1 or more).  Each type can have their own set of states as 
this allows for customized work-ish tasks that are item-type specific.  
So to answer your question, yes, the plugin would insert their data, we 
are simply providing the structures.

Thanks for the input.  Are there any table that are missing.  I feel 
good about the dialog on what was there but I'm a bit worried I may be 
missing something that may be a critical need for the kernel.

--Tony


--__--__--

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


End of geeklog-devel Digest