Problems of X2
XOOPS2 is good core, because module developers are promised freedom on programing. This freedom means that programers don't need to consider connectivity with the core. The core manages only an existence of modules. The core doesn't know what a content is. And each module defines each content.
But, it's a problem that the core doesn't know what a content is. Site owners can assign modules to the site, but can't assign pages to the site. For example, it's impossible to make a child pical page under a pico page. That is a spec and a limitation.
eZp's merits & demerits
Personally I call a style like eZp "Tree Style". That's just CMS. Site Owners can make a new node of the site tree as a content under the root node. Also the owners can add a new nodes under the existing node. This issimilar to file system, 'intuitive' and flexible structure.
A node is an object that the eZp core defines. It's possible that each nodes use each template, total access control, multi-language layer and the general management. The general management means that site owners can edit, move and delete node, even if the node is a special node that human being should not control directly.
Any contents should be controled as an object that eZp defines. That's a merit and a demerit. When you get that you can assign static pages freely, you are surprised at possibility of the Node Style. But, when you try to install forum or blog like XOOPS, you encounter issues.
eZp handles a content as an object. A static page is an object and a node. Also a comment of forum is an object. A topic is a child node of the forum node. And, a responce is a child node of the topic node. Also a entry is a child node of the blog node. And a comment and a trackback are a child node of the entry node.
If your site have 344 messages of the forum, 36 entries and 2056 SPAM comments for the entries, the tree of your site has many node and complex structure. I don't agree that a grain size of my profile page equals a grain size of a SPAM comment that recommends Viagra.
You can handle all contents as a node and an object of eZp, so it's possible to move a comment node from the blog to the forum, make a multi-language layer to a comment node. But, there is no point.
eZp is very very excellent professional CMS. So it is not best way for all XOOPS owners. "Node Style" that handles all content as an object that the core defines is not perfect solution.
RapidWeaver
RapidWeaver is home page creation tool at Mac OS X. Basically, the RapidWeaver is similar to eZp. You add sibling pages and child pages to the existing page. RapidWeaver recognizes a page. So it's possible to move, edit and delete each page.
But, Blog, Photos and Download type page are handled as a one page. Blog has many entries. These entries are data that Blog page manages. RapidWeaver doesn't handle each entry as a page. You can move blog page to other page, but can not fetch a entry from the blog and move the entry to other page. That's right. Nobody wants to do it. Of course, you can edit and delete entries at the blog management. See the following screenshot for more informations.
RapidWeaver gives many hint to us, so check 30 days free trial version if you have Mac OS X.
3 comments:
Reading this post I first though about Netcommons interface...
But i can say that XOOPS Cube Legacy can achieve such goal with some modules and the advantage of user permissions and extendability.
It is most a question of user experience and user interface, sure, due to we lack of examples.
But the possibilities of XCL are amazing. And it should be easy to show how to improve such user interaction on content management/publishing ^^
Hi,
My poor English may have gave misunderstanding. The problem I think is that XCL is not tree-structure. For example, you can not put download page under pico page. D3 architecture make it possible to copy modules. But,
URL/mod/pical0
URL/mod/pical1
URL/mod/pical2
We can not put moduels with the following:
URL/mod/pical0
URL/mod/pical0/pical1
URL/mod/pical0/pical2
This is the limitation of XOOPS2. And, XCL can not solve this limitation. So our next new BASE module should solve take good solution from other software like RapidWeaver.
You're right! My comment was not clear, sorry. Recently I ask my brother to help me on a new project built on XCL. He runs pico as example with one more deep level. (I'll blog about it ^^)
Aware of the interesting features of XOOPS Cube, I wonder how to bridge and extend fields to manage data (alike the netcommon module to create db tables). Something really "cubic", multi-tables, multi-arrays, multi-render. My Data Module, released with an editable language catalog (ala d3 style) could be used (renaming and editing catalog) for 'myDownloads', 'myLinks', 'myBooks', 'myMusic', 'myVideo'...
Post a Comment