[Radiant] Radiant Plugins and Philosophy

Josh Ferguson josh at besquared.net
Thu Jul 13 08:51:23 CDT 2006


Following this theme I have spent the night creating a script called 
build_extension which I will be releasing later today that will allow 
developers to easily create these extensions.

The idea is this

1) Check out the core version of radiant that the extension will be 
built upon.
2) Develop in this directory just like you were developing a normal app, 
changing things wherever.
3) Export a fresh copy of the core version you are building upon into a 
directory inside your development root (somewhere like radiant_core)
4) run 'script/build_extension PluginName PathToFreshRadiantCore (ex: 
./script/build_extension radiant_blog radiant_core)
This will check each of the files in your development directory against 
the fresh core version, create the plugin structure, copy those files 
which you have changed and create the generators for overwriting those 
files.
5) Distribute the plugin

Your users then just do

$ script/plugin install http://path.to/your_plugin
$ script/generate your_plugin --force
$ rake migrate

which will then overwrite and/or add any models, views, controllers, 
helpers, libraries, and tests that there were packaged in the plugin. It 
also adds the proper numbered migrations to the db/migrate directory so 
that 'rake migrate' works correctly.

This should make it very easy for developers to simply check out the 
core version and then write and package very large pieces of 
functionality as extensions. They could essentially create a system that 
looked nothing like the original system if that's what they wanted. All 
the generators and plugin structure is written for them making it easy 
to just continue developing and release newer versions on a regular basis.

When new version of the radiant core are released developers will have 
to migrate their extension over to the new version and run 
create_extension again to build a plugin against the newer version. This 
should only be a problem for larger versions.

The door will soon be wide open for developers to use all of their 
skills without having to worry about learning a new plugin system, I 
can't wait to see what you guys come up with.

Josh

Josh Ferguson wrote:
> This is another email about plugins and philosophy. I've had a change of 
> heart.
>
> 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.
>
> 1) 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)
>
> 2) 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.
>
> Josh
> _______________________________________________
> Radiant mailing list
> Radiant at lists.radiantcms.org
> http://lists.radiantcms.org/mailman/listinfo/radiant
>
>   




More information about the Radiant mailing list