[Radiant] Radiant Plugins and Philosophy

[Josh Ferguson]

If it doesn't modify anything then how do you route to it? Or administer 
it from the interface that looks like the rest of the site? It adds 
functionality that's true, but only for developers who are willing to 
take the time to integrate some type of management it into their admin 
interface. If that's the case (which I assume it would be) I have to go 
in and modify your controllers, views, and models to get it to fit into 
the system I'm already using.

What we're really after is a strong integrated look, feel, and 
philosophy between all pieces of the application. This is one thing that 
helps makes applications usable, and what makes the other CMS systems 
suck. By making things over modularized you doom yourself to a system 
that becomes ugly and unusable. I don't want to repeat the mistakes of 
every CMS that has tried this approach for the past decade.

Imagine a world where there are several Radiant extension projects which 
different people contribute to. The bloggers contribute to the radiant 
blog extension, the community sites contribute to the radiant community 
extension, etc. All the while radiant core continues to be stable and 
grows feature rich, but its focus is on features that can be used by all 
extensions to improve them in their specific problem domains. And all of 
it would be easily packaged, shipped and dropped on top of the core.

I'm not saying we can't use an engine style plugin for the packaging and 
shipping, although we'd have to modify the engine behavior in some ways. 
I'm just saying that the philosophy of what seems on the outside to be 
nice like dropping in a gallery, comments, and maybe 2 or 3 other 
vertical plugins on top of a system just turns it into a huge giant mess 
with application logic spread out into 3 or 4 different app directories 
not to mention the main one.

If we are to use an engine like system for this I think that what should 
happen is that groups should get together and build massive pieces of 
functionality instead of many small ones. Individuals can still build 
small pieces, but it would be for a particular project/extension. A 
group might build a blog with every blog feature they want and make it 
look, feel, and work really well together, then package it as a radiant 
engine. This means we could have several blog extensions that each take 
advantage of the great behavior, tagging, and administrative strengths 
of radiant, while each taking a different approach to how they integrate 
their blogging features. This represents a change in how this community 
would be structured, but I think it is an important one, and one that 
could make radiant one of the best content management systems out there.

This will be my final post on this topic of this length. I hope my ideas 
had some impact to someone somewhere. :)

Josh @ besquared

Al Evans wrote:
> Josh Ferguson wrote:
>
>   
>> Core's objection to engines is that the pieces are too big. Engines
>> encapsulate essentially an entire application, whole vertical slices of
>> functionality. The view of core on this is that if you want an
>> application then build an application, you most likely aren't going to
>> drop in more than one engine at a time ever since the slices are so big
>> and most likely won't work with one another without some major
>> modification on your part so what's the point in having them pluggable?
>> It makes more sense to just download a complete application and go from
>> there. Adding mroe than one large vertical slices of functionality most
>> often leads to collisions where two plugins are overwriting the some
>> pieces of the same classes or views, that is why it's useless to have a
>> system where you can install more than one.
>>
>> That being said the other thing I dislike about engines is that engines
>> start out with the philosophy of 'the engine is your application' and
>> then you can override views in your application. This is completely
>> opposite of what makes sense in our situation, where your application is
>> your application and the views you already have get overridden by the
>> plugins in the engine.
>>     
>
> I don't know that much about what other people are doing with engines, 
> but I offer my own psitsNOT as a counter-example. It simply adds 
> image-editing to any Rails app. To do this, it needs its own views, but 
> it doesn't impinge on the other functionality of the app in any way. All 
> the app needs to do is override the PictureController, and all it has to 
> do there is provide a source of images.
>
> I'm not trying to be difficult, but plug-in functionality of this sort 
> CAN be desirable. Image editing could be useful in a wide variety of 
> apps, even ones in which it is completely beside the point of the app 
> (blogs, catalogs, ...). psitsNOT doesn't interfere in any way with any 
> other functionality of the application; it doesn't even use the 
> database.
>
> (Demo: http://psitsnot.alevans.com
>  svn: http://svn.openprofile.net/plugins/p_sitsnot_engine )
>
> I don't really think this is a unique case, and I apologize for being a 
> bit off-topic:-)
>
> --Al Evans
>
>