[geeklog-devel] Geeklog Topics and Blocks

Wed Sep 14 14:52:03 EDT 2011

Opps . my mistake.

From: geeklog-devel-bounces at lists.geeklog.net
[mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Vincent Furia
Sent: September-14-11 1:17 PM
To: Geeklog Development
Subject: Re: [geeklog-devel] Geeklog Topics and Blocks

Tom,

I think you misunderstood, what I meant was:

CREATE TABLE `gl_topic_assignments` (

  `tid` varchar(20) NOT NULL,

  `type` varchar(30) NOT NULL,

  `id` varchar(40) NOT NULL,

  PRIMARY KEY  (`tid`,`type`,`id`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE {$_TABLES['topics']} (
   tid varchar(20) NOT NULL default '',
   topic varchar(48) default NULL,
   imageurl varchar(255) default NULL,
   meta_description TEXT NULL,
   meta_keywords TEXT NULL,
   sortnum smallint(3) default NULL,
   limitnews tinyint(3) default NULL,

   featured varchar(40) default NULL,
   is_default tinyint(1) unsigned NOT NULL DEFAULT '0',
   archive_flag tinyint(1) unsigned NOT NULL DEFAULT '0',
   owner_id mediumint(8) unsigned NOT NULL default '1',
   group_id mediumint(8) unsigned NOT NULL default '1',
   perm_owner tinyint(1) unsigned NOT NULL default '3',
   perm_group tinyint(1) unsigned NOT NULL default '3',
   perm_members tinyint(1) unsigned NOT NULL default '2',
   perm_anon tinyint(1) unsigned NOT NULL default '2',
   PRIMARY KEY (tid)
) ENGINE=MyISAM

We only allow one featured article per topic, so why not keep it in the
topic? We have to grab data from the topic table anyway when displaying the
topic page. The homepage can be a special case (of which there are any
number of ways to handle).

-Vinny

On Wed, Sep 14, 2011 at 09:43, Tom <websitemaster at cogeco.net> wrote:

>> Or add a column to the topic table, at least for featured stories . You
could also have special values for tid to represent all topics or homepage
only

That was what I was originally going to do. Have a featured column used by
articles and the column tid would contain either the topic id or "all" or
"homeonly" (currently how blocks work). When a user creates a topic I will
just have to add a few topic ids that are not allowed.

CREATE TABLE `gl_topic_assignments` (

  `tid` varchar(20) NOT NULL,

  `type` varchar(30) NOT NULL,

  `id` varchar(40) NOT NULL,

  `featured`  tinyint(1) NOT NULL DEFAULT 0,

  PRIMARY KEY  (`tid`,`type`,`id`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Tom

From: geeklog-devel-bounces at lists.geeklog.net
[mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Vincent Furia
Sent: September-14-11 3:15 AM
To: Geeklog Development

Subject: Re: [geeklog-devel] Geeklog Topics and Blocks

What about a separate table to track what you want to store in value? Or add
a column to the topic table, at least for featured stories (I never
understood why this was in the story table and not the topic table). You
could also have special values for tid to represent all topics or homepage
only (I'd suggest numerics, but you could use NULL).

Since you're likely going to be using this table for joins, I'd suggest
keeping it as simply as possible (e.g. removing the "value" column
completely and moving the information you'd keep in there elsewhere).

-Vinny

On Tue, Sep 13, 2011 at 10:33, Tom <websitemaster at cogeco.net> wrote:

Yeah I know it is not an ideal solution (that's why I started the
conversation) but I believe it is better than adding single use columns on a
table that will only be used by certain types. Unless someone else can point
to a better solution I think I will stick with it.

Tom

From: geeklog-devel-bounces at lists.geeklog.net
[mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Joe Mucchiello
Sent: September-12-11 6:19 PM
To: geeklog-devel at lists.geeklog.net

Subject: Re: [geeklog-devel] Geeklog Topics and Blocks

> I have dropped the feature column (for articles) in favour of a multi-use

> column called value. This way articles can use the column to signify a
> featured story and blocks can use it to signify all or homepage only (this
> would leave the tid field blank). Plus it could be used by other plugins
> if needed.

Value is a weak sol ution. While I realize that type mitigates "fights" over
what goes into value (the owner of type decides what goes in value),
filtering on value is going to be a pain if you need to store more than one
logical "field" in value. No, I don't have a better solution. But I just
wanted to point out the pitfalls of the opaque "value" field.

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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20110914/ef761509/attachment.html>