Today, I was trying to make a simple content management system, and one part of a CMS is to be able to put that content onto a menu so you can have it easily show up and look like it's part of your website. Well, I have a menu system that seems to work. So, do I build capability into the content management system to be able to use my menuing system or do I build the menu system to be able to add content to itself???

Well, keeping to my philosophy as of late (besides just reading Plato), I like the second option. Sure, why not have a way for a menu to add a content page to itself? Of course you ask, isn't that stupid? Well, yeah, unless you make it completely reusable. In other words, the menu system can add anything to itself, as long as it's a menu-able something or other. And to define something as menu-able, you basically have to say, ok, what things are needed in order to add something to a menu. Well, in my system, all you need are a page, some text to display, and maybe you want to be able to supply parameters, which are built into the menu system. Ok great.

So, in a file called menu-objects.xml, I can define menu-able objects and supply parameters for them.

There are a few more things needed for the database. You want to have a list of things that are menu-able that you already have in the database. So, the screen can popup and say "what do you want to add a menu item for?" and you pick, say "content", and then a list of the content will show up and you can select it, type in a menu title, pick the menu, pick where on the menu you want to put it, and it's done. These are all simple mouse clicks.

Why can't content add itself to a menu, you might ask? Well, what if I want to add a ton more stuff that can be menu-able. What if I want to make news menu-able? I don't want to have to rebuild news... content isn't the only thing that's potentially menu-able. Also, I built the menu to be swappable later if I wanted to make another one, or add new features, I can just inherit the previous menu, add new features if I want, and without too much work, there's a new menu up there. Plus, I just don't like things depending on other things. Why have content depend on a menu system? Why have news depend on a calendar? Just have each thing be self contained, that's what I always say.

This philosophy I realized when I built the calendar. Do I want to add code to each object that is "calendar-able"? Code that, as it is, already works for the most part? No way. The only thing is, should the calendar be able to exist without this notion of calendar-able objects? Absolutely. And besides just not having any objects listed. This calls for the notion of a very advanced mechanism. One that brings joy to my once joyless heart. Interfaces and abstraction.

So, I want a calendar to be just a calendar at one time, but later transform into this amazing thing that can get events from your database, plot them onto itself, and have it clickable so you can see those events. Well, the fact is that it can't. At compile time, it should know that it might have to deal with calendar-able objects. That's pretty much the nature of programming. The best solution though, is to have an interface for something called a CalendarableObject and another interface to supply these items, called CalendarEventSupplier. The beautiful thing is, you can create a NullCalendarEventSupplier, set it as the supplier in an xml file somewhere, and your calendar is now just a plain old calendar with no mapped events. However, create a DatabaseCalendarEventSupplier, and it's now transformed into something that makes calls to your database, gets events, and plots them onto the calendar.

I love programming.