OK! I'm back from being unable to do stuff. And oh boy did I do a shitty job of writing documentation (while simultaneously screwing up my sleep cycle) last time!
Thanks for pointing out the... bad name. It's been renamed, therefore a new link: https://github.com/Zee1234/PlaceholderAPI
As per the purpose: It's made to handle textual placeholders. Think about NilSPace's Chatter plugin. Some "random" plugin can tell Chatter "Hey, if you get some text {MyPluginName_ThatOneThing}, then just call "ThatOneThingsFunction" in my library to get what it should be instead!". What PlaceholderAPI (ever so lovingly shortened to PAPI) does is take the weight off of plugin devs to accommodate every plugin that wants to do that separately. Instead, Plugin X can tell PAPI "I want you to replace MyPluginName_ThatOneThing with whatever I return from 'ThatOneThingsFunction'". Then, Plugin Y, having encountered a placeholder that it doesn't know, asks PAPI about it. PAPI recognizes MyPluginName_ThatOneThing, and therefore calls ThatOneThingsFunction, and returns the result to Plugin Y. This allows Plugin Y and Plugin X to be fully compatible with each other without either having to build around the other.
More detailed (AND actually good this time (I swear)) documentation can be found in the Readme on Github. There's also an example plugin that shows how you would integrate with PAPI at the end of the file.
The problem it solves? One plugin Dev having to satisfy multiple multiple other plugin's text-replacement systems. Use cases? A factions plugin and a {chat formatting plugin, boss bar plugin (can we do those yet?), scoreboard plugin, action bar plugin, title plugin (same here :/)}. It's not exactly a big problem right now, but it could be a big help when cuberite gets bigger.
Ninja edit: the help line in the placeholder registration is for later when I make a console command that creates a text/HTML/XML (possibly all three?) file that lists all placeholders you can use, allowing uses to generate their own form of documentation.
Thanks for pointing out the... bad name. It's been renamed, therefore a new link: https://github.com/Zee1234/PlaceholderAPI
As per the purpose: It's made to handle textual placeholders. Think about NilSPace's Chatter plugin. Some "random" plugin can tell Chatter "Hey, if you get some text {MyPluginName_ThatOneThing}, then just call "ThatOneThingsFunction" in my library to get what it should be instead!". What PlaceholderAPI (ever so lovingly shortened to PAPI) does is take the weight off of plugin devs to accommodate every plugin that wants to do that separately. Instead, Plugin X can tell PAPI "I want you to replace MyPluginName_ThatOneThing with whatever I return from 'ThatOneThingsFunction'". Then, Plugin Y, having encountered a placeholder that it doesn't know, asks PAPI about it. PAPI recognizes MyPluginName_ThatOneThing, and therefore calls ThatOneThingsFunction, and returns the result to Plugin Y. This allows Plugin Y and Plugin X to be fully compatible with each other without either having to build around the other.
More detailed (AND actually good this time (I swear)) documentation can be found in the Readme on Github. There's also an example plugin that shows how you would integrate with PAPI at the end of the file.
The problem it solves? One plugin Dev having to satisfy multiple multiple other plugin's text-replacement systems. Use cases? A factions plugin and a {chat formatting plugin, boss bar plugin (can we do those yet?), scoreboard plugin, action bar plugin, title plugin (same here :/)}. It's not exactly a big problem right now, but it could be a big help when cuberite gets bigger.
Ninja edit: the help line in the placeholder registration is for later when I make a console command that creates a text/HTML/XML (possibly all three?) file that lists all placeholders you can use, allowing uses to generate their own form of documentation.