Hi,
By architecture I meant the framework that mambo developers use to
create new extensions to it. It is really easy to write a new "mambot"
that changes content. As an example, in mambo, if you place a php file
under the mabots directory, it automatically loaded and executed. A
content object is passed to it so that you can modify it before it
gets sent to browser. So for me it was very easy to write a content
"wikifier" because I didn't have to worry about anything else other
than writing the wikifier itself and of course, following their code
template to write a mambot. This is what I mean by architecture:
extensibility and cleanliness.
Architecture can mean a lot of things. I my view the architecture is
more than just extensibility and cleanliness. It is how everything works
together. But, architecture is a very big word...
Here is something that I think mambo guys could have done better, and
it might be of your interest too. Some of the non-core
components/extensions that individuals write manage their content
their own way: with no framework hooking ability and in separate DB
tables. Then when somebody else like me writes a wikifier or a textile
markup we have no way of intercepting the content from their
components. As a result there are some wiki-enabled sections and
others that are not; there are sections of content like forums where
the markup syntax is different from the one of News; and when you
search with one search engine it only searches within one section. My
point is that a single abstraction/object that represents text content
could be used for any section and it could be stored in the same
location so that content modifers like wikifiers and markups can
change all content in the site (from news and forums and whatnot) by
using the same framework hook, and search engines could find any text
in the site by just querying one table (or one file).
That is kinda what I mean by tree based contentobjects. Imagine a file
system in a db. Only that every object can have children. Products can
have subproducts, forum threads can have children, articles, folders,
images, in fact: everything is a folder which is able to hold content
and all these contentobjects are in one table - contentobjects. It is
amazing how easy Rails makes this. Here is the model for my contentnodes
table which is the table that holds references to the contentobjects.
class Contentnode < ActiveRecord::Base
# see the recursive definition
# the table has fields: id, name, parent_id (recursive structure)
# Rails makes defining this ridiculously easy
belongs_to :contentobject
belongs_to
arent, :class_name => 'Contentnode', :foreign_key => 'id'
has_many :children, :class_name => 'Contentnode', :foreign_key =>
'parent_id'
# can be called to find out where you are (to build
# breadcrumb navigtaion)
def self.path(id)
path = []
return path unless id.to_i > 0
loop do
node = find(id)
id = node.parent_id
path.unshift(node)
break if id == 0
end
path
end
end
# the contentobjects table has lots of generic fields (like text1,
# text2, text3, blob1, blob2, ..., float1, float2, int1, int2, ...)
class Contentobject < ActiveRecord::Base
has_many :contentnodes
has_one :contenttype
# i.e. can be a Folder, Article, Image, or what not
end
This is the basic architecture of the cms which should allow a lot of
flexibility and reduce duplication you would probably get when using a
table per object type (images, articles, links, forms, threads, posts,
...) You can see this approach in some of the popular cmss. I don't know
about Mambo, have to look at the db-structure first.
Furthermore,
this object needs to be fairly complete so taht indivdual developers
like me don't feel the need to hack DD tables or someone else's code
in order to add our functionality in it. Basically every operation to
retrieve and save (manage) any text content needs to be clearly
available through the object and proper framework hooks/callbacks.
This generic approach should be a solution to this problem, but it also
brings another level of abstraction into play which complicates things.
We will just have to see how it goes. I am confident that it is doable.
Well, that's all.
Good luck with your projects and have fun with CMS in Ruby. Do you
have a name for it yet?
I do, and I already have a logo, too, but this is all still top secret.
It will be revealed some day soon. But maybe you can guess the full
name. The acronym will be MCMS (I dont think the last 3 letters will be
hard to guess. The name should appeal to all users of the cms, not only
the developers. Otherwise I could just called it RubyCMS.
Cheers
