How to make plugins of plugins

[reformedView]

Hey all,

     This article (https://decibel.ni.com/content/docs/DOC-19176) does a decent job of walking through how to use plugins with a packed project library (PPL) system.  I'd like to go a little further, if possible.  How does one make plugins of plugins?  For example, if I have a fruit plugin interface, I might have a banana plugin, apple, rasperry, etc.  I then would want to make some plugins for the banana plugin -- peel, taste, eat.  I may want taste and eat for apple, as well as juice for raspberry.  Is this wonderful mess even possible?  My current thought would be to just make a generic fruitAction plugin interface and have a fruit's actions stored within a subfolder of that fruit.

Any suggestions welcome,

Nathan

[Norbert_B]

Nathan,

stacking plugins is, in general, possible. But not recommended.

That being said, i don't see any stacking in your example. In your example, you use one abstraction called "Fruit" which provides already all three functions: peel, tast, eat.

If you are using LV OOP for the plugins, it is very easy to have three child classes from fruit: Banana, apple, raspberry. Each can have a different implementation of the three functions.

For instance "peel" doesn't really make sense for raspberries, so you would leave it out. For banana, peel is a manual process without additional tools, for an apple, you might want to use a knife as tool.

Also creating juice or milkshakes out of each fruit is simply added to your plugins if using LV OOP:

The class fruit will add "make milkshake" as abstract function. Each childclass would then implement something (slightly) different algorithm for it as you have to peel a banana first, a raspberry possibly has a stem which should be removed first. And a milkshake made out of apples... well, maybe it tastes, maybe not 😉

hope this helps,

Norbert

[Vijay_J]

---

@reformedView wrote:

Hey all,

     This article (https://decibel.ni.com/content/docs/DOC-19176) does a decent job of walking through how to use plugins with a packed project library (PPL) system.  I'd like to go a little further, if possible.  How does one make plugins of plugins?  For example, if I have a fruit plugin interface, I might have a banana plugin, apple, rasperry, etc.  I then would want to make some plugins for the banana plugin -- peel, taste, eat.  I may want taste and eat for apple, as well as juice for raspberry.  Is this wonderful mess even possible?  My current thought would be to just make a generic fruitAction plugin interface and have a fruit's actions stored within a subfolder of that fruit.

Any suggestions welcome,

Nathan

---

Plugins of plugins is possible and we have done in our company for a platform project.

For example: Hardware Drivers plug-ins used by the Test Steps plug-ins. You will have to have two abstraction layers.

It is bit complex.

Regards,

Vijay.

[reformedView]

Mr. Norbert, thanks for your reply.  You are right, peel, taste, juice are more methods of a plugin class, not stacked plugin objects.  Sorry my illustration wasn't well-formed.  Compost that and try a Fruit interface that has Berry, Pome, Gourd plugins.  Berry then has Blueberry and Banana plugins, Pome has Apple and Pear, and Gourd has Squash and Zuccinni.  I can make a Fruit interface, easy.  But I have no idea what exotic creation of a Fruit plugin someone might add later (Jujube?), much less what interface its plugins might have.  A Pome interface might have a method Bob (you can theoretically bob for pears), which I can't see you doing for a Berry.  Likewise you would probably Juice a Berry or a Pome, but you probably only fry a Gourd after you Slice it (which could be done for any Fruit).  The point of all this is simply that I would like to be able to add any Fruit plugin, and then to whatever Fruit plugin add a more specific type of Fruit plugin, but the only core interface I have is for the Fruit.

Pardon me while I go Devour a delicious Orange Berry.

[Norbert_B · Accepted solution]

Nathan,

point of a plugin is to specify a "generic" operation to a specific use case. So in your example, you have the problem that the abstraction layer cannot provide a generic function which is specified by the plugin.

Of course, by some obscure and over-engineered approach, you might be able to solve a setup as you like. Still, i recommend you to provide only a single layered abstraction in the context of design. Of course, implementation can "stack" this. So in your second example, "Fruit" would provide generic operations on ALL kind of fruits without any implementation. Depending on the specific fruit, you would either leave the operation as dummy (no override) or add an override which indicates something like "This operation doesn't make sense with this type of FRUIT". For other fruit, you would add an override like "YAMYAM, tasty!"....

Norbert

PS: Please note that i haven't discussed any "architectural design for deployment" here. So the question starts for "one lvlibp" or "several"? But as you already quoted Michael Lacasse's Community Entry, you know where to find useful information 😄

[reformedView]

I think you have it there, flat structure with or without overrides. Thanks much, I'll give it a try.