[geeklog-devtalk] geeklog-devel digest, Vol 1 #454 - 8 msgs
geeklog-devel-request at lists.geeklog.net
geeklog-devel-request at lists.geeklog.net
Thu Dec 16 12:05:01 EST 2004
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 (Tony Bibbs)
2. Re: Custom user attributes in GL2 (Vincent Furia)
3. Re: Custom user attributes in GL2 (Tony Bibbs)
4. Re: Custom user attributes in GL2 (Vincent Furia)
5. Re: Blocks in GL2 as Plugin? (Blaine Lang)
6. Re: Custom user attributes in GL2 (Blaine Lang)
7. Re: Blocks in GL2 as Plugin? (Tony Bibbs)
8. Re: Draft of schema for GL2 (Tony Bibbs)
--__--__--
Message: 1
Date: Wed, 15 Dec 2004 22:22:10 -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
Vincent Furia wrote:
>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.
>
>
Yeah, so the only issue I have is some plugins may require others, no?
If so how do we handle such dependencies? Similarly, plugins may
optionally support features from other plugins.
This whole plugin architecture is really sexy. I really get excited
thinking about the possibilities.
Yumm, drugs ;-)
--Tony
--__--__--
Message: 2
Date: Wed, 15 Dec 2004 23:38:14 -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
I think plugin dependencies should be evaluated (and "asserted") at
install/upgrade/uninstall time. That way we won't have to keep
anything in the DB. And we'll be operating fairly safely. Plugins of
course will have to figure out for themselves what dependencies they
require.
-Vinny
On Wed, 15 Dec 2004 22:22:10 -0600, Tony Bibbs <tony at tonybibbs.com> wrote:
> Vincent Furia wrote:
>
> >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.
> >
> >
> Yeah, so the only issue I have is some plugins may require others, no?
> If so how do we handle such dependencies? Similarly, plugins may
> optionally support features from other plugins.
>
> This whole plugin architecture is really sexy. I really get excited
> thinking about the possibilities.
>
> Yumm, drugs ;-)
>
> --Tony
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
>
--__--__--
Message: 3
Date: Wed, 15 Dec 2004 22:47:06 -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
Sounds good. I'd say the plugin API should reflect the support of
dependency checking, no?
--Tony
Vincent Furia wrote:
>I think plugin dependencies should be evaluated (and "asserted") at
>install/upgrade/uninstall time. That way we won't have to keep
>anything in the DB. And we'll be operating fairly safely. Plugins of
>course will have to figure out for themselves what dependencies they
>require.
>
>-Vinny
>
>
>On Wed, 15 Dec 2004 22:22:10 -0600, Tony Bibbs <tony at tonybibbs.com> wrote:
>
>
>>Vincent Furia wrote:
>>
>>
>>
>>>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.
>>>
>>>
>>>
>>>
>>Yeah, so the only issue I have is some plugins may require others, no?
>>If so how do we handle such dependencies? Similarly, plugins may
>>optionally support features from other plugins.
>>
>>This whole plugin architecture is really sexy. I really get excited
>>thinking about the possibilities.
>>
>>Yumm, drugs ;-)
>>
>>--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
>
>
--__--__--
Message: 4
Date: Wed, 15 Dec 2004 23:52:40 -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
Definitely. The plugin should tell the core what dependencies it has,
then the core should automagically determine if its okay for the
plugin to install.
-Vinny
On Wed, 15 Dec 2004 22:47:06 -0600, Tony Bibbs <tony at tonybibbs.com> wrote:
> Sounds good. I'd say the plugin API should reflect the support of
> dependency checking, no?
>
> --Tony
>
> Vincent Furia wrote:
>
> >I think plugin dependencies should be evaluated (and "asserted") at
> >install/upgrade/uninstall time. That way we won't have to keep
> >anything in the DB. And we'll be operating fairly safely. Plugins of
> >course will have to figure out for themselves what dependencies they
> >require.
> >
> >-Vinny
> >
> >
> >On Wed, 15 Dec 2004 22:22:10 -0600, Tony Bibbs <tony at tonybibbs.com> wrote:
> >
> >
> >>Vincent Furia wrote:
> >>
> >>
> >>
> >>>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.
> >>>
> >>>
> >>>
> >>>
> >>Yeah, so the only issue I have is some plugins may require others, no?
> >>If so how do we handle such dependencies? Similarly, plugins may
> >>optionally support features from other plugins.
> >>
> >>This whole plugin architecture is really sexy. I really get excited
> >>thinking about the possibilities.
> >>
> >>Yumm, drugs ;-)
> >>
> >>--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
>
--__--__--
Message: 5
From: "Blaine Lang" <geeklog at langfamily.ca>
To: <geeklog-devel at lists.geeklog.net>
Subject: Re: [geeklog-devel] Blocks in GL2 as Plugin?
Date: Thu, 16 Dec 2004 01:18:12 -0500
Reply-To: geeklog-devel at lists.geeklog.net
I may be out of sync but let me ask these questions:
Will the core not have a fundamental underlying layout control facility for
formatting common site components ?
Does there not need to be some core component or set of operations that
control the site layout?
- header, footer, blocks which are the basic building blocks of the site.
Plugin's essentially today call and need to call the common functions to
wrap the site layout around their content.
You may be referring to the Block Editor and for that I think we need to
explore what the ideal set of features need to be.
It may be a replaceable component but the underlying table structure to
support a basic editor or advanced editor need to be in place.
If we agree that blocks are the basic building blocks of the site content we
can explore what additional attributes are needed.
Are blocks just an item in GL2 or do they need to be identified and stand on
their own ?
Blaine
----- Original Message -----
From: "Vincent Furia" <vfuria at gmail.com>
To: <geeklog-devel at lists.geeklog.net>
Sent: Wednesday, December 15, 2004 10:53 PM
Subject: Re: [geeklog-devel] Blocks in GL2 as Plugin?
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
>
_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://lists.geeklog.net/listinfo/geeklog-devel
--__--__--
Message: 6
From: "Blaine Lang" <geeklog at langfamily.ca>
To: <geeklog-devel at lists.geeklog.net>
Subject: Re: [geeklog-devel] Custom user attributes in GL2
Date: Thu, 16 Dec 2004 01:30:24 -0500
Reply-To: geeklog-devel at lists.geeklog.net
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
--__--__--
Message: 7
Date: Thu, 16 Dec 2004 08:59:25 -0600
From: Tony Bibbs <tony at tonybibbs.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
Blaine Lang wrote:
>I may be out of sync but let me ask these questions:
>
>Will the core not have a fundamental underlying layout control facility for
>formatting common site components ?
>
>
Yes it will
>Does there not need to be some core component or set of operations that
>control the site layout?
> - header, footer, blocks which are the basic building blocks of the site.
>
>
I think the question is more a logistical one. Just how atomic do we
want the kernel to be? There are two scenarios I seen playing out with
respect to blocks. The first is that blocks aren't implemented as
plugins and all related code exist in files within the kernel. That's
essentially no different than 1.3.x today. The other school of thought
would be to move it to a plugin and and leave it up to the other plugins
to mark it as a dependency.
I don't think philosophically I have an opinion. However,
architecturally, I think the plugin route makes things harder. For
example, take the sample application I wrote. The abstract class in
BaseViewFlexy.php exposes the showHeader() and showFooter() methods
allowing all children to reuse that code. So if we applied this same
technique to blocks, there maybe a getBlock() method in this abstract
class which is a part of the kernel source. Now assume the block
features are implemented in a plugin. Immediately you can't have the
equivalent of the getBlock() method on the BaseViewFlexy class because
we can't assume the block plugin is installed. So in this case any
plugin wishing to use blocks would probably end up creating their own
abstract class that extends the BaseViewFlexy class and would add the
getBlock() method. Then all their views would use that new class.
While that is feasible, the problem is that I think you'll have nearly
every plugin in GL2 wanting to use blocks and so you'll have a copy of
this sort of new abstact class in each plugin implementation which seems
like a duplication of code.
So I think I am back with Blaine in that the block code needs to be in
the kernel. The beauty of this is plugins still have the option of
overriding anything in our classes because of the new OO-design so the
plugins still maintain ultimate control over their use of blocks.
>Are blocks just an item in GL2 or do they need to be identified and stand on
>their own ?
>
>
Uh, how about both. I'm not sure what you are asking but let me give my
two cents to see if this answers this question. I do see a record for
every block in GL2 in the gl2_item table. This is because the item
table includes some already important things a block will want to track
(ACL's, owner, creation date, etc). Then you'll have a gl2_block
table that has all the block specific data.
--Tony
--__--__--
Message: 8
Date: Thu, 16 Dec 2004 11:04:34 -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
This is a multi-part message in MIME format.
--------------040204080108050506050103
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
New schema is attached. I added the gl2_block table...this may have
been a bit premature since we are still discussing it. You can choose
to ignore it pending the outcome of that discussion.
Here's what I did:
1) Any referenct to 'event' was changed to 'action'
2) I added a plugin_id to the action table, only outstanding issue is
how are we representing kernel events?
3) Versions can't be floats if they have two decimal points can they? I
think the validation on this needs to happen via the save's validation
logic and I think we need to standardize that all version numbers are in
the format x.y.z
4) I didn't do anything with count fields...that's pending further
discussion
5) The supplemental user stuff was added to the gl2_user table
6) gl2_ban table was removed. I agree this can be doing via a plugin
7) I didn't see any datastructures related to preoder traversal stuff in
categories. I looked in the latest mysql_tables_and_data.php file on
the comments table and didn't see a field that looked like what I was
expecting. What am I missing, Vinny?
8) Added enabled flag to gl2_item
9) removed the security related fields form the category stuff, then
changed category_id to be item_id so we don't have to worry about
category_id/item_id collisions on ACL table.
10) added gl2_item_category which is an association table between items
and categories.
Please review the outstanding issues in my previous email and get back
to me ASAP. NOTE, this still won't import into MySQL yet. I'll work on
that tonight.
--Tony
Tony Bibbs wrote:
> 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
--------------040204080108050506050103
Content-Type: text/plain;
name="create.sql"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="create.sql"
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;
CREATE TABLE gl2_action (
action_id int unsigned NOT NULL auto_increment,
plugin_id int unsigned,
action_name varchar(40) NOT NULL,
description varchar (255) NOT NULL,
PRIMARY KEY(action_id),
FOREIGN KEY (plugin_id) REFERENCES gl2_plugin(plugin_id)
INDEX(action_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;
CREATE TABLE gl2_actionListener (
action_id int unsigned NOT NULL,
plugin_id int unsigned NOT NULL,
PRIMARY KEY(action_id, plugin_id),
FOREIGN KEY (action_id) REFERENCES gl2_action(action_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,
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,
signature varchar(128),
biography text,
first_name varchar(30),
last_name varchar(30),
homepage varchar(50),
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;
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;
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_catalog (
catalog_id mediumint unsigned NOT NULL auto_increment,
catalog_name varchar(50) NOT NULL
PRIMARY KEY(catalog_id),
INDEX(catalog_name)
) TYPE=INNODB;
CREATE TABLE gl2_item (
item_id int unsigned NOT NULL auto_increment,
type_id int unsigned NOT NULL,
user_id int unsigned NOT NULL,
enabled tinytint unsigned NOT NULL DEFAULT 1,
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,
num_ratings mediumint unsigned NOT NULL DEFAULT 0,
rating_sum int unsigned NOT NULL DEFAULT 0,
expiration_date int unsigned DEFAULT NULL,
parent_item_id int unsigned DEFAULT NULL,
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(state_id) REFERENCES gl2_item_type_state(state_id),
FOREIGN KEY(parent_item_id) REFERENCES gl2_item(item_id)
) TYPE=INNODB;
CREATE TABLE gl2_category (
item_id int unsigned NOT NULL,
catalog_id mediumint unsigned NOT NULL,
category_name varchar NOT NULL,
parent_category_id int unsigned NOT NULL,
image_url VARCHAR(128) DEFAULT 'NULL',
sort_num tinyint unsigned DEFAULT NULL,
enabled tinyint unsigned NOT NULL DEFAULT 1,
PRIMARY KEY(item_id),
FOREIGN KEY(item_id) REFERENCES gl2_item(item_id),
FOREIGN KEY (catalog_id) REFERENCES gl2_catalog(catalog_id),
INDEX (enabled)
) TYPE=INNODB;
CREATE TABLE gl2_item_category (
item_id int unsigned NOT NULL,
category_id int unsigned NOT NULL,
PRIMARY KEY (item_id,category_id),
FOREIGN KEY(item_id) REFERENCES gl2_item(item_id),
FOREIGN KEY(category_id) REFERENCES gl2_category(category_id)
) TYPE=INNODB;
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;
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;
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;
CREATE TABLE gl2_block (
item_id int unsigned NOT NULL,
name varchar(30) NOT NULL,
title varchar(50) NOT NULL,
is_configurable tinyint unsigned NOT NULL DEFAULT 0,
is_collapsable tinyint unsigned NOT NULL DEFAULT 0,
is_undockable tinyint unsigned NOT NULL DEFAULT 0,
type_id int unsigned NOT NULL,
location_id int unsigned,
rdf_url varchar(128),
last_rdf_update int unsigned,
function_name varchar(50),
content text,
sort_num tinyint unsigned,
PRIMARY KEY(item_id),
FOREIGN KEY(item_id) REFERENCES gl2_item(item_id),
FOREIGN KEY(location_id) REFERENCES gl2_list_of_values(lov_id),
FOREIGN KEY(type_id) REFERENCES gl2_list_of_values(lov_id),
INDEX(sort_num)
) TYPE=INNODB;
--------------040204080108050506050103--
--__--__--
_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://lists.geeklog.net/listinfo/geeklog-devel
End of geeklog-devel Digest
More information about the geeklog-devtalk
mailing list