Ideas for approach to infinite levels system
Posted: Thu Jan 08, 2009 8:44 pm
Ok, just wanted to share a project I'm working on, and see if you guys had any ideas for how to approach it. Basically, I'm revamping my company's CMS. We want to have infinite levels of content. We currently have two levels, tabs + pages.
Basically what we want is:
The really tricky part is what to do from here. Using the url, I can locate a final handler for the location. This handler needs content to work on-- if the user added a page, then a single page needs to be attached to that handler. I may want more content though-- for example, a list of Posts from a blog. The user should be able to specify what blog these posts come from, and how many posts. In that case, I wouldn't want to attach every post to the handler, I'd want to attach the blog. This content can get multileveled, too.
Say, for example, I want to feature some articles on my home page. I'd have a location, with a page attached to it. Attached to the page would be a featurebox, with any number of content attached to it. The way I'm thinking right now, I will limit each location/Document to 1 item of content to be attached to it. If it's only one, the handler will know what type of content that refers to, and fetch it. if it's 1, and the handler is a PageController, it fetches a page with id 1. If it's 1, and the handler is a BlogController, it fetches a blog with id 1. That means I need relations between content.
Originally I was going to have an EAV system to deal with all these content relations, but I've moved away from that in the last 6 months. That means I need a relation table that not only tracks ids, but which table they are from, to have type-agnostic relations such as with a featurebox. I feel like aggregate items, such as a blog view or featurebox, deserve their own handlers even if they aren't the only thing on the page. Does that mean I need another table for content => handler pairs?
I'd really like some feedback about this. Am I approaching it right? I'd like to hone in on the domain and really define these classes well, so any of you DDD aficionados out there, speak up!
Cory
Edit: Thanks pickle!
Basically what we want is:
- A clean urls system where each section of a URL corresponds to a handler/resource. (ie, REST or Konstrukt)
- Content-specific handlers that know how to get the content they need and what to do with it.
- A tree of content that can be organized according to each client's specific needs.
- "Pages" that can be constructed from many different parts, using many different content types.
- Capability for unique meta data to be kept for every page.
- Separation of content and location, so the same content can be used in many different places.
The really tricky part is what to do from here. Using the url, I can locate a final handler for the location. This handler needs content to work on-- if the user added a page, then a single page needs to be attached to that handler. I may want more content though-- for example, a list of Posts from a blog. The user should be able to specify what blog these posts come from, and how many posts. In that case, I wouldn't want to attach every post to the handler, I'd want to attach the blog. This content can get multileveled, too.
Say, for example, I want to feature some articles on my home page. I'd have a location, with a page attached to it. Attached to the page would be a featurebox, with any number of content attached to it. The way I'm thinking right now, I will limit each location/Document to 1 item of content to be attached to it. If it's only one, the handler will know what type of content that refers to, and fetch it. if it's 1, and the handler is a PageController, it fetches a page with id 1. If it's 1, and the handler is a BlogController, it fetches a blog with id 1. That means I need relations between content.
Originally I was going to have an EAV system to deal with all these content relations, but I've moved away from that in the last 6 months. That means I need a relation table that not only tracks ids, but which table they are from, to have type-agnostic relations such as with a featurebox. I feel like aggregate items, such as a blog view or featurebox, deserve their own handlers even if they aren't the only thing on the page. Does that mean I need another table for content => handler pairs?
I'd really like some feedback about this. Am I approaching it right? I'd like to hone in on the domain and really define these classes well, so any of you DDD aficionados out there, speak up!
Cory
Edit: Thanks pickle!