Opinions needed: CMS database & admin interface structure

Hi all freaks!

I have been thinking hard, what would be good solution for a
straight-forward content management. I want to forget polls and forms etc..
and concentrate first only on different kinds of pages.

I came up with this approach in "nightly vision", wich felt very flexible.

ADMIN FORMS
**************
- customised to different purposes: news, articles, contact information
pages etc...
- they all submit data to SAME table, calles NODES
- certain forms take anvantage of HTMLArea-solution in certain fields, which
degrades to textarea in older browsers

ABOUT DATABASE
*****************
NODES TABLE
- has enough fields to most of the purposes
- each node is connected to one author, 0..N..limitless number of editors,
o...n images and to 1 template.
- id, title, introtext, bodytext, author_id, template_id, publication_date,
etc...
- also couple of ordinary linkfields for those authors who dont write html.

AUTHORS TABLE
- stores author information

EDITORS TABLE
- connects editors, rights and nodes
- author can give rights to certain editors to edit certain mode that he has
created

IMAGES TABLE
- stores images

NODELINKS TABLE
- connects one node to another
- innodb -> links are always valid because when page disappears, links to it
disappear also!

IMAGELINKS TABLE
- connects images to nodes
- innodb -> links are always valid because when page disappears, links to it
disappear also

TEMPLATES TABLE
- html/php-templates: infopage, personnel info, news_page etc...

So, my idea is:
1) one basic table (nodes) with some other tables is enougfh for many kinds
of tables, because then templates make different kinds of pages to look and
feel different
2) node has user rights that nodes author gives to 0..n..limitless editors
in addition to himself. In this way node is useful to many kinds of
purposes, from company news-collection to public visitor book
3) this works both as text-based and wysyiwyg cms, depending on the authors
skills - and browser.

Is this idea as good as it look to me still? I feel that the number of
different applications is reduced by this solution. I hope I was able to
explain what I mean. If you dont' get my idea, please ask more.

- perttu pulkkinen, jkl

Go for it dude :)

Worst thing that could happen is that you'll learn from the experience.



Perttu Pulkkinen wrote:

> Hi all freaks!
>
> I have been thinking hard, what would be good solution for a
> straight-forward content management. I want to forget polls and forms etc..
> and concentrate first only on different kinds of pages.
>
> I came up with this approach in "nightly vision", wich felt very flexible.
>
> ADMIN FORMS
> **************
> - customised to different purposes: news, articles, contact information
> pages etc...
> - they all submit data to SAME table, calles NODES
> - certain forms take anvantage of HTMLArea-solution in certain fields, which
> degrades to textarea in older browsers
>
> ABOUT DATABASE
> *****************
> NODES TABLE
> - has enough fields to most of the purposes
> - each node is connected to one author, 0..N..limitless number of editors,
> o...n images and to 1 template.
> - id, title, introtext, bodytext, author_id, template_id, publication_date,
> etc...
> - also couple of ordinary linkfields for those authors who dont write html.
>
> AUTHORS TABLE
> - stores author information
>
> EDITORS TABLE
> - connects editors, rights and nodes
> - author can give rights to certain editors to edit certain mode that he has
> created
>
> IMAGES TABLE
> - stores images
>
> NODELINKS TABLE
> - connects one node to another
> - innodb -> links are always valid because when page disappears, links to it
> disappear also!
>
> IMAGELINKS TABLE
> - connects images to nodes
> - innodb -> links are always valid because when page disappears, links to it
> disappear also
>
> TEMPLATES TABLE
> - html/php-templates: infopage, personnel info, news_page etc...
>
> So, my idea is:
> 1) one basic table (nodes) with some other tables is enougfh for many kinds
> of tables, because then templates make different kinds of pages to look and
> feel different
> 2) node has user rights that nodes author gives to 0..n..limitless editors
> in addition to himself. In this way node is useful to many kinds of
> purposes, from company news-collection to public visitor book
> 3) this works both as text-based and wysyiwyg cms, depending on the authors
> skills - and browser.
>
> Is this idea as good as it look to me still? I feel that the number of
> different applications is reduced by this solution. I hope I was able to
> explain what I mean. If you dont' get my idea, please ask more.
>
> - perttu pulkkinen, jkl
>
>
>
>
>
>
>