Wedge
Public area => The Pub => Plugins => Topic started by: Arantor on May 15th, 2012, 04:26 AM
-
OK, so I was contemplating how an arcade plugin might work, and in particular adding new games to one - as plugins themselves that depend on the main arcade.
And here's the weird thing, it occurs to me that we could do something truly neat.
As you know, the plugin manager works by the plugin-info.xml files, and the different XML indicates various things - there are XML tags for adding new bbcode, for adding scheduled tasks, and so on. What if a plugin could declare its own extra XML handlers?
So like the arcade plugin, it could declare a <arcade-game> block handler, so that arcade games could be bundled into plugins quickly and easily without having to do complex database changes or anything, just declare new items and let the arcade handler figure out what it wants to do with it.
In reality all we're really talking about is a hook in the enable/disable plugin routines that also passes the manifest SimpleXML object and plugins can register a hooked function for there. I don't think many would use it but it is certainly an interesting idea.
-
/melikes this
-
Fantastic idea :)
-
The one problem is how I indicate from a 'child plugin' that it requires these features from a parent package, like in this case how we indicate that <arcade-game> block in a plugin is dependent on a given plugin being installed and enabled.
I suppose what could be done is if the plugin indicates it needs the handler function as part of the <required-functions> block?
-
I suppose what could be done is if the plugin indicates it needs the handler function as part of the <required-functions> block?
-
It's... interesting... trying to do that. I did originally plan on doing that actually in the package parser but I never got any useful error messages out of the RelaxNG parser that I could feed back to the user.
I could certainly apply more validation than is currently applied, though. There is already a certain amount of validation carried out just viewing the list, it wouldn't be harder to pull out a list of first level children and validate based on that at least, but it's not particularly easy to provide any useful error messages from that.
-
It's... interesting... trying to do that. I did originally plan on doing that actually in the package parser but I never got any useful error messages out of the RelaxNG parser that I could feed back to the user.
I could certainly apply more validation than is currently applied, though. There is already a certain amount of validation carried out just viewing the list, it wouldn't be harder to pull out a list of first level children and validate based on that at least, but it's not particularly easy to provide any useful error messages from that.
-
Sure it is, though it does make life interesting for plugin authors - if it does get implemented I'd rather keep it as straightforward as possible for developers.
-
Actually, I realised today that I pretty much need to do validation of tags at the first-child level.
Consider the bbcode support I added, and now assume for the sake of argument that I implemented that in Wedge 1.1. Plugins that were written for 1.1 would install successfully (as far as plugman cares) on 1.0 but the bbcode wouldn't work. There isn't a safety net there to validate that it works, and plugman does not fail visibly on most things, it just ignores them (which is probably a safer way to go about things, though it isn't helpful for debugging much)
Anyway, here's the plan. First level validation needs to occur for general support, and that is what gets extended by plugins that declare their own XML blocks. This does also provide for a certain level of safety in terms of plugins - should I add sections, later plugins won't be installed on earlier versions. (And if people hack the plugin-info.xml file, it isn't going to work properly anyway, heh)
-
I just thought of something. What if the parent plugin is removed? Then the child plugin has its added tags, but the plugin manager has NFI what to do with them.
-
Well, I should get the plugin manager to disable those too.
Note that the related circumstances I've seen with Dragooon's notifications plugin are applicable.