Re: Ruby's Killer App - every language has one

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 :parent, :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
-- 
Sascha Ebach