Wiring AddOns - Plugins for behaviours and complex operations

phreak

Hi all,

Interestingly i very often come to the point that the wiring of plugins would be totally great to make plugins to work with each other. Complex calculations of user behaviour could create an awesome user experience. The hosted version has some features that makes it more richer to combine Badges and Rections, or Post Count with Roles and so. On the OS side of Vanilla we are missing some of this great wiring options.

For now every plugin works kinda for itself as it's almost not able to communicate based on a rule set with others (beside of those written by one developer and intended to be combinded for example @peregrine's or @lifeisfoo's). Surely this is not a new idea, but i wanted to ask into the round what your thoughts are about this.

What ideas did you have in mind?
What ways does Vanilla provide to wire actions behind the curtain?
Could there be something like a "Wiring plugin" that is able to combine actions/functions of plugins in the back?
Is there a way to extend the possibilities of what can be done with plugins?

I know some developers had ideas and plugins in mind and already started working on these, but most of them broke with their projects. Not because of skill - but as we all know, because of the lack of more substantial support and future projection for the OS people by the V team, which makes it hard to grow the OS scene stronger so free devs could make at least some bucks on plugin development.

Wiring plugins? Stupid, impossible or a plugin worth thinking of?
Is there a way of setting up a wiring idea without bloat the code of other plugins?

https://ifttt.com/ might explain the functionality but please don't misunderstood me, i know this is a fully featured application that can't be realized in Vanilla. I mean the principles of wiring.

x00

It is not a stupid idea, but first you have to consider what it actually means. Pluigns are sort of lateral, they intercept at key points in an application through 'events' and piggyback controllers to create new methods/pages.

You can call this parallel development.

This framework has a cascade effect in the sense that, dashboard is sort of the super application that fill in the gaps of vanilla. So application can work in parallel with each other or be totally independent. In terms of views it is totally like that, default.master, etc

Plugins can totally work in parallel to each other (and at the same time in parallel with the applications). However few pluings have put events of pluggable infrastructure in them.

I have done in some notable MarketPlace, karma bank. Generally you need a plugin to be a 'core', and the plugin working in parallel to it to then plugin into it.

If you want it to work both ways then you have think of it like this. pluign 1 is hooking in plugin 2 pluggable infrastructure, and plugin 2 is separately plugging into plugin 1 infrastructure.

The both have to have plugbability It some case it can be simple as providing $this->FireEvent('SomeEvent');, or even just a simple static function.

This event are quite loosely wired as you can pass whatever object you like.

I have been working on a design pattern where the API of the plugin (not vanillas API), would have an init event, as to then be able to access the API methods, via other plugins, or any hook files.

In any event it is up to plugin developers mostly.

it is also possible to reuse modules, and resource such as client side scripts.

Plugins that are totally dependent on another plugins should explicitly require them.

lifeisfoo

On a recent work, a client wanted custom badges and awards for his forum, auto-assigning them on certain external hooks/data.

What I've done

Since he wanted an OSS badge plugin I searched for existing plugins in the addons directory and I've found @peregrine badges. The "problem" with this is written for a "monolithic" badge system (that actually is good for performance) and I didn't want to make a work that needs to be updated with the plugin.

So I created a plugin called BadgesFactory that expose only badges and awards models with methods to declare(icon,name,description,etc), assign, deactivate/activate them and a module to show them in user profile pages. Next from the custom plugin for the client I added custom hooks to check when a badge needs to be assigned, and to activate/deactivate them when the plugin is activated/deactivated.

This is one way of "wiring", I think. I'll release it soon (with examples).

P.s.
For basic badges the client is using PeregrineBadges.

phreak

@x00: Thanx for this insight in the proceedural workflow of Vanilla. I have to admit i had to read it 3 times to understand what is going in here.

@lifeisfoo: Very interesting. I'm sure you also checked @businessdad's Awards before doing that. The features and logic sound similar. I also attached 2 screenshots describing the rules that can be set in the Awards plugin. It is pretty good and easy outlines in this plugin.

How could it be possible to extend a ruleset like this? It seems like a certain "plugin API" would be needed to create a systemwide access. It would be very interesting if plugins would be built with this (well explained) API in mind one day.

businessdad

In my opinion, trying to implement a generic wiring mechanism can lead to having a complicated structure, which would become messy to maintain and extend. It's definitely not a walk in the park.

To remain in topic of badges, my badges plugin is designed to be part of a larger system, but to work independently as well. The mechanism that allows the various parts to communicate and to interact with external sources is flexible and extendable, but still specialised to cater for the need of handling Users reputation.

businessdad

Talk about coincidence, I wrote my reply at the same time @phreak wrote his. Yes, using my rule system it would be possible to validate any criteria, including external sites, and assign a badge when certain conditions are met. Creating a rule involves using a special class and dropping the file in a specific place, but I was also thinking of event for registering or overriding rules on the fly.

Flexibility is the key behind the whole system (that doesn't mean perfect flexibility, yet, but it's a work in progress).

R_J

What would a developer need to reuse code from other plugins? That's what a meta framework would have to offer. The first two things that come to my mind are

1. reusable models so that when I want to see who's online, I could call a function inside of the whosonline plugin model, when I want to see the badges a user has, I want to call a function inside of the badges plugin model, etc.
2. being able to hook into the code someone has written in his plugin in order to change either behaviour, look or whatever

That's it. But it's all in Garden right now. As @x00 already stated, a FireEvent at the right place gives you the ability to hook into functions. A clear MVC structure in plugins enable others to override views, use their sqls, etc.

Instead of creating a framework in a framework, I think it would be more effectiv to give advises on how to write reusable code. Scaffolding and example plugins could be a great help with that!

• consider if it could be helpful to put a FireEvent(...before...) at the beginning of a code block and a FireEvent(...after...) at the end
• use parameters for your sql queries ($wheres could be a great help!)
• I'm sure there are more helpful advises for developers

Yes, all programmers would have to stick to that guidelines so that it is working without a meta framework, but if there would be a meta framework, all developers would have to stick to that framework so you the need the ccoperation of the plugin developers anyway.