CMS Made Simple Forums

0.9 is going to bring about a module API reorganization. I actually want to do an object oriented API, instead of the callback one that's currently in place. An idea of what I have in mind is similar to how Nucleus CMS does their plugin API. It's documented here: http://nucleuscms.org/documentation/dev ... ugins.html

This is really what I wanted to do originally, but I didn't know enough about the internals of PHP to do it correctly. Now that the content is organized in this fashion and I have all the quirks worked out, it's actually very easy to do.

There is actually a lot of good things in their API, however, some things (like the event system) are a little too much for what we probably want to accomplish.

Akrabat and I originally talked about this in IRC and we have most of the ideas worked out. A class called CMSModule that a module will extend and then override the functions that it wants to use. We talked about the idea of having diffrerent classes for different things, but I think that may complicate matters.

We also need to have some kind of way to doing intermodule communication like we have in 0.8. I'm not sure if that would be part of the class as well, or if there would be some kind of global ModuleFunctions class that would handle this...

Anyway, if anyone has ideas on the matter, please bring them up here or on IRC. I'd like to start this this week, though it will probably be in a separate branch in svn, since it's going to break A LOT of stuff.

Maybe 0.9 should be able to handle both types of modules? I'll have to look into that and see if it would make it harder or easier. Right now, we only have a few modules, so it probably wouldn't be a huge deal to just make 0.9 require the new type. I guess we can handle that when we get to it.

Thanks for your input!

You could use an MVC. Sorry you'll have to excuse me I'm a newbie at PHP.

design patterns for people who want a simple life

So what I'm thinking is:

VIEW
A view which is pretty much like nucleus cms's plugins API. All it actually does is send the controller requests for stuff. You don't even need to extend CMSModule because all modules (see MODELS) take the same commands. All you do is tell the VIEW which module to run and then feed it a bunch of actions, it gets the controller to do the rest.

MODELS
New style modules
Old style modules
The next generation of modules when we decide that the new modules are just not good enough etc.

CONTROLLERS
Now this is the tricky bit. For new modules there will be a "ModuleController" which would be a null adapter since we will be using the new modules specification for the new modules. Basically since new modules are new modules, they will work in the new modules way.

But for old modules there will need to be specific OldModuleControllers for each module OR (and this is the bit I'm not sure about) if php supports some sort of reflection then that can be used to investigate old modules to see if appropriate method calls exist.

All OldModuleControllers would extend OldModuleController which is a dispatching adapter (aka a work around for the callback functionality currently in use).

This may look complicated to develop but it might make building modules very easy since all users need to do is build a simple class with the appropriate methods in there and the MVC does the rest.

I like the ideas, but not totally sure about how it would all fit together. MVC is definatly not something I know a ton about, only basic concepts. If you know anything about the current architecture of CMS, do you see how/where it would fit in?

And, yes, php does support reflection. That's how the content types work. I can get a list of all classes currently loaded that extend CMSContent...

tee hee I know very little about CMS's current architecture. After a quick look on Source Forge I've found a php documentor which I will install to have a look at what's there. I'll probably get back to you in a couple of days.

A note on reflection I recall being told it was a bad idea. It encourages disorganised programming (guilty as charged) and is resource intensive. A more efficient method is to register classes on instantiation and get them to return their legal method calls, holding them in the controller.

Ok, I think I understand now. Not totally conviced about the module not extending a class, but the rest makes sense. Not totally sure it's worth the trouble to develop, because of the fact that we're not expecting the API to change again (knock on wood), and we don't really have a lot of modules in exsistence at this point... I'll have to think about that a little bit and really weigh in how important supporting old modules is.

having had a cursory glance at the source code for CMS I agree. It's too simple (=elegant) to be complicated in that way