[Radiant] Radiant Plugins and Philosophy

Thu Jul 13 21:13:13 CDT 2006

On 13-Jul-2006 21:11 -0500, Josh Ferguson was heard to say:
> 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 you want plugins to be fine-grained you will not get around of having
application logic spread over all of them. Our task is to make it as easy
as possible for people to write this application logic and more importantly
keep it small in size.

> 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 puts Radiant more into the category of a CMS framework: Radiant as the
core system and one large extension that implements all-you-need for a
particular scenario, like blog. I personally do not like this approach and
rather go with fine-grained plugins that do small things here and there.
Eventually, the user does not care over how many directories the application
logic is spread out and the plugin developer doesn't either if the API for
the plugin system is well done.

Oliver

> 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
> >
> >   
> 
> _______________________________________________
> Radiant mailing list
> Radiant at lists.radiantcms.org
> http://lists.radiantcms.org/mailman/listinfo/radiant

-- 
Oliver Baltzer
.web   > http://nobits.org/oliver/
.pgp   > 0x32B54706
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.radiantcms.org/pipermail/radiant/attachments/20060713/c322da3d/attachment.bin