Portable plugin apps?

I might be working on a project for a friend shortly. They have lots of experience with developers who use Drupal - and I get the feeling (could be wrong) that you can semi-plug-and-play with Drupal?

So..
Want a wiki - use X plugin
Want a user system - use Y plugin
Want user profiles - use Z plugin
Want user gallery - use A plugin
Want a blog - use B plugin

So I started looking around, and there are plugins for specific frameworks, or standalone applications written in a framework, WebGUI CMS seems to have a lot of features but I want to use my framework of choice (and experience!).

Having been playing with Plack it got me thinking...

Just as Plack/PSGI sits between the webserver and your code, could someone (brighter than me!) come up with a standard for sitting between a framework and an app (blog/gallery/wiki/forum etc)?

The app would need to have a standard way of initializing (creating db tables etc), but with so much discussion of NoSQL databases that might not be so problematic. Maybe the apps could focus on just data - supplying default templates which can be overwitten in the framework.

Anyway I can see so many issues, but as I start this project I get the feeling I may have to reinvent some wheels (or at least remould some existing ones) and that just doesn't seem right!

5 Comments

I've got notes somewhere for something similar, but I never got around to implementing anything. Going from memory and leaving aside the issue of initialization, in execution, I would think of it much like PSGI -- a plugin provides a code reference that you call with an "environment" and you get back content that would get dropped into some portion of a template.

Unlike PSGI, I don't think you need headers, but having an out-of-band status seems helpful for knowing whether the content is good or whether an error occurred. It's possible that you'd want to get back HTML and CSS to compose into the reply.

Then, much like PSGI, you could have plugins which simply compose other plugins.
Plugin A provides the general layout, and calls plugin B for the menu, and plugin C for the main content.

If people are interested in setting up a mailing list or IRC group to explore this kind of thing, please count me in.

Maybe I'm misunderstanding you, but this sounds a lot like Reaction. It never really got off the ground though.

This is something recurring over and over and it evidently it is extremely difficult to get right. Drupal manages to get there by being a monolitic framework and dictating how everything has to behave. I am convinced that there is another way, a loosely coupled set of libraries way and I'll try to get there.


My current experiments are around Dependency Injection. DI is a silly name to something very straightforward - it means that all that is needed is passed via parameters, never from some global variable (not even from a Singleton) or created on the fly. Of course all these objects passed around still need to be created somewhere - the point is to have just one place per scope where you create all of them. This part of code should be simple - it's like a config file - and I would leave it to the user code.


Catalyst did a lot to get to the loose coupled design - but it still takes over the object creation part and this way it needs to interface everything. I imagine a web library that is just a part of the application, that the application creates it and feeds all the data it needs - I think this will be a better design and a better basis for a component architecture.

It's a very tough nut to crack, because typically in a CMS environment you've got a lot of shared objects and infrastructure (users, templates, settings, configs, files, sessions, database connections, cache, auth, routing, etc).

We're actually planning on something like this for the next generation of WebGUI (not 8, but 9). Instead of having the apps as plugins to a WebGUI specific API, they would be more like silos that can run stand alone or in combination with each other. Unfortunately we're no where near far enough along to help you with your project.

Like dagolden, I'd sign up if a mailing list were started for such a project.

A propos that 'user system' - what do you think about my latest experiment: https://github.com/zby/Plack-Middleware-Auth-Form

Leave a comment

About Ranguard

user-pic London Perl developer