History of ContentInheritance
Version 4 | Current version | |
---|---|---|
Inspired by the EXP-WIKI-FARM ideas, I thought I would jot down some of my concepts for a more general solution for this valuable concept. The idea i would pursue (and probably will for bitweaver) is a more generic one. I would like to use an inheritance concept such that there was a "base content" table, and other tables would inherit off of it to do specialized functionality. TABLE "public.base_content" Holds all the generic data for any content type (wiki, article, blog post) contentId | bigint | primary key title | character varying(200) | title or pageName description | character varying(200) | brief description data | text | content data created | bigint | lastModif | bigint | user | character varying(200) | size | bigint | TABLE "public.namespace" A simple description for a grouping of content. namespaceId | bigint | primary key namespaceName | character varying(200) | theme | bigint | primary key ... many more fields here TABLE "public.content_namespace_map" Holds a mapping of which content exists in which content group contentId | bigint | foreign key to base_content namespaceId | bigint | foreign key to namespace All existing tables & lib.php's work as before, but have their common data elements moved into base_content. All existing primary keys are converted to a single contentId. Search would be much simpler. Simple, powerful permissioning could be done with this mechanism as well. This is a major step towards a real content management system. For example: Table "public.tiki_pages" contentId | bigint | foreign key to base_content comment | character varying(200) | version | integer | not null default '0' ip | character varying(15) | flag | character(1) | points | integer | hits | integer | votes | integer | cache | text | wiki_cache | bigint | default 0 cache_timestamp | bigint | pageRank | numeric(4,3) | creator | character varying(200) | page_size | bigint | default 0 Table "public.tiki_blog_posts" contentId | integer | foreign key to base_content blogId | integer | parent blog trackbacks_to | text | trackbacks_from | text | Table "public.tiki_articles" contentId | integer | foreign key to base_content state | character(1) | default 's' author | character varying(200) | authorName | character varying(60) | topicId | bigint | topicName | character varying(40) | useImage | character(1) | image_name | character varying(80) | image_type | character varying(80) | image_size | bigint | image_x | smallint | image_y | smallint | image_data | bytea | publishDate | bigint | expireDate | bigint | hash | character varying(32) | reads | bigint | votes | integer | points | bigint | type | character varying(50) | rating | numeric(3,2) | isfloat | character(1) | | {{Exterminate| |date=13-November-2008 }} Inspired by the EXP-WIKI-FARM ideas, I thought I would jot down some of my concepts for a more general solution for this valuable concept. The idea i would pursue (and probably will for bitweaver) is a more generic one. I would like to use an inheritance concept such that there was a "base content" table, and other tables would inherit off of it to do specialized functionality. TABLE "public.base_content" Holds all the generic data for any content type (wiki, article, blog post) contentId | bigint | primary key title | character varying(200) | title or pageName description | character varying(200) | brief description data | text | content data created | bigint | lastModif | bigint | user | character varying(200) | size | bigint | TABLE "public.namespace" A simple description for a grouping of content. namespaceId | bigint | primary key namespaceName | character varying(200) | theme | bigint | primary key ... many more fields here TABLE "public.content_namespace_map" Holds a mapping of which content exists in which content group contentId | bigint | foreign key to base_content namespaceId | bigint | foreign key to namespace All existing tables & lib.php's work as before, but have their common data elements moved into base_content. All existing primary keys are converted to a single contentId. Search would be much simpler. Simple, powerful permissioning could be done with this mechanism as well. This is a major step towards a real content management system. For example: Table "public.tiki_pages" contentId | bigint | foreign key to base_content comment | character varying(200) | version | integer | not null default '0' ip | character varying(15) | flag | character(1) | points | integer | hits | integer | votes | integer | cache | text | wiki_cache | bigint | default 0 cache_timestamp | bigint | pageRank | numeric(4,3) | creator | character varying(200) | page_size | bigint | default 0 Table "public.tiki_blog_posts" contentId | integer | foreign key to base_content blogId | integer | parent blog trackbacks_to | text | trackbacks_from | text | Table "public.tiki_articles" contentId | integer | foreign key to base_content state | character(1) | default 's' author | character varying(200) | authorName | character varying(60) | topicId | bigint | topicName | character varying(40) | useImage | character(1) | image_name | character varying(80) | image_type | character varying(80) | image_size | bigint | image_x | smallint | image_y | smallint | image_data | bytea | publishDate | bigint | expireDate | bigint | hash | character varying(32) | reads | bigint | votes | integer | points | bigint | type | character varying(50) | rating | numeric(3,2) | isfloat | character(1) | |