[geeklog-devel] Geeklog Topics and Blocks

[Vincent Furia]

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/e53bf4c7/attachment.html>