Development

Posted by Gustavo Muslera 21 Aug 2003 21:03 GMT-0000 posts: 49 ☆ ☆ ☆

For fixing ideas, lets separate code from presentation from content. Code are the php scripts, presentation are the templates for smarty, and what I will discuss here is about core data for the content. There are more core data to be represented, like users, groups, security, etc, but I will start from the inner core of generic data for content.

Of course that this is not thinked as an implementation way to do things, just modeling, performance, data representation and querying in sql databases and things like that are for other moment.

My proposal is to have an inventory of content objects, each one having the following attributes:

• id
• name
• kind (a wiki text, an file, an image gallery, a forum post, an entire blog, etc)
• list of attached objects (ids/names/etc of objects attached to this)
• owner (as in user owner or creator of this object)
• category (could be also list of categories)
• father (the object from where this comes from/is attached to)
• security scheme (list of permissions of this object in special related to users, or groups)

Of course, this are not just a table columns in a database, is just a conceptual level, the lists in here could mean more tables, or a field with special separators.

Note that under this structure, is perfectly valid to have a forum attached to a forum post (forum management software could enable or disable certain attachs, but the structure is open to such things) or to have the same object as attach of himself (also, the software could control that this not happen)

The "kind" of object, is, of course, something very open, an internal or external modules can define its own "kinds" of informations, with its own tables to help interpretation of objects.

Such table could be similar to:

• kind
• description
• handlers for
  • creating
  • destroying
  • editing
  • showing stand alone
  • showing attach
  • showing module

Of course, there is some kind of inheritance between levels of objects. If i.e. you delete a forum, it call the handler for deleting each one of the posts, which in its own time call de handler for deleting the texts and the attached objects, and so on, and then call the handler for deleting itself.

Now, how this kind of structure could relate to "actual" tikiwiki? How we can represent with this kind of things i.e. Wiki pages? Well, we have a generic object, of kind i.e. "text" or "wiki", and in a table for texts, where we have as fields the text itself, and logical values "contains wiki", "contains html". The wiki display program should check for that name or name+wiki, display the text of the texts table (rendering wiki and/or html depending on the logical fields), and for each of the attachment, call the appropiate handler to show as attachment the related objects. I could even put a table specifically for wiki in the middle, so a component of the new table could be the id of the text in the texts table, and have more related attributes, like the list of objects that is the history, or a list of special content that have this page inside, like a list of links or used plugins, if someone finds that this could be useful.