Re^2: Moose, Metadata and the Everything CMS

Thank you for this great, thought-provoking reply. It has certainly got me thinking about how to group the data and operations that need to be performed on the data.

In relation to specific issue of the data that have been classified class data, the data can be classified like this:

the name of the class into which the object data should be blessed.
data that allow a user object to perform an operation on another object(these operations are currently only insert, update, delete and execute)
data that determine whether additional operations should be performed on a data node when it is inserted or updated in the back end database.

These data are hierarchical so that data related to objects in a sub-class may override the defaults set in the superclass. These data follow the class structure of the objects to which they relate.

What your post made me realise is that data such as access data don't necessarily have to follow the class structure of objects themselves. So, for example, whilst objects of class Node have access data of type Access::Node. Its subclass Node::HTMLData doesn't have to inherit its access data from Access::Node (although it could), perhaps its access data could come from Access::HTMLObjects.

I'm going to give this some further thought and tweak some of the code - (first step will be to move the access methods into roles, I think).

Thanks for your help.

Comment on Re^2: Moose, Metadata and the Everything CMS

Replies are listed 'Best First'.
Re^3: Moose, Metadata and the Everything CMS by stvn (Monsignor) on Feb 27, 2009 at 15:38 UTC
What your post made me realise is that data such as access data don't necessarily have to follow the class structure of objects themselves. So, for example, whilst objects of class Node have access data of type Access::Node. Its subclass Node::HTMLData doesn't have to inherit its access data from Access::Node (although it could), perhaps its access data could come from Access::HTMLObjects. Perhaps you should look into Roles for this. They make it very easy to address cross-cutting concerns like this by using their more horizontal composition style. This approach also tends to help prevent the typical OO explosion of subclass trees where you need to subclass an entire section of your class hierarchy to just extend one node of it, sometimes called the Expression Problem. -stvn	[reply]

Replies are listed 'Best First'.

Re^3: Moose, Metadata and the Everything CMS
by stvn (Monsignor) on Feb 27, 2009 at 15:38 UTC

What your post made me realise is that data such as access data don't necessarily have to follow the class structure of objects themselves. So, for example, whilst objects of class Node have access data of type Access::Node. Its subclass Node::HTMLData doesn't have to inherit its access data from Access::Node (although it could), perhaps its access data could come from Access::HTMLObjects.

Perhaps you should look into Roles for this. They make it very easy to address cross-cutting concerns like this by using their more horizontal composition style. This approach also tends to help prevent the typical OO explosion of subclass trees where you need to subclass an entire section of your class hierarchy to just extend one node of it, sometimes called the Expression Problem.

-stvn

[reply]