This is another email about plugins and philosophy. I’ve had a change of
I’ve gotten a lot of my plugin architecture to work. Changing the admin
interface through callbacks, adding callbacks to controllers for form
processing, behaviors and tags which already worked. I just want to take
a minute and beg the question, just because we can, should we?
Look at what is required:
Changing views (with our new forms)
Changing helpers (to display new forms)
Changing controllers (to process new form elements)
Changing models (to facilitate has_many of any new models we create)
Adding database tables through migrations
Adding new routes with routing
We want plugins that do that? What we’re creating is a /separate
application/ altogether. We’ve touched almost every piece of the
application. What we’ve done is spread additional logic to support the
plugins throughout the system, and then the logic inside the plugins
themselves. I can tell you from building this system that there is no
clean way to do it, and it will probably become unmaintainable. There is
no simple way to drop in a lot of complex functionality like comments
and have it work out.
I would put forth some combination of these options to choose from
instead of doing the plugin system like this.
Slow development of radiant where it is at 0.5.0 and call it the
radiant CMS base or core or framework or whatever. Then build very
domain specific extension from it and have those be placed over the core
as separate products. Extensions could be developed and added onto by
different people that all started from radiant CMS base. (more on how
this works afterward)
Put things like comments, trackbacks, tags, etc. into the system but
have them turned off by default and only turned on only through settings
menu (this only extends to blogs and must all be done by the core team)
I’m going to talk about #1, it’s a weird and I’m sure unpopular idea. If
we left a certain core functionality and called it radiant core, then we
could build out plugins as generators which overwrote pieces of the core
system. We could just completely overwrite certain views, controllers,
helpers, models, etc.
It would almost be as if we were patching over the core system with a
domain specific version of the system and allowing developers to go from
there. It would be easy to add migrations to the normal migrations
directory, and just overwrite and add other pieces to the system as
needed. We can even use the plugins and generator scripts that are
already in the system right now to achieve this.
This only works if we stabilize a build that is called radiant core and
attempt to keep it as stable as possible. I strongly believe this is a
really great thing to do and I will probably begin writing these
generators anyway so that people can see how they are created and start
creating some of their own.
There is a downside, which is that only one extension could be added at
a time, so extensions would have to come in many flavors but that is
what the community is really good at. I know that this is a system that
will work for everyone here who is struggling to implement radiant in
what they are doing. The system might look like:
$ radiant/: script/plugin install http://svn.radiantcms.org/radiant_blog
$ radiant/: script/generate radiant:blog
$ radiant/: rake migrate
I’m interested in what everyone thinks.