The ProBoards JavaScript API

[Tim Camara]

Hey guys, today marks the launch of our new JavaScript API: www.proboards.com/developer/js.

This API was put into place to provide a stable, maintained codebase with which to interact with all the myriad JavaScript functions that are available to V5 forums.  At this time we aren't removing the old functions, and have no plans to do so, but we do reserve the right to change those functions should the need arise in the future.  These new functions are offered as a way to ensure that your plugins and other codes remain in good working order no matter what back end changes are made to the forum code.  

At this point the API offers almost all of the basic functionality that we see plugin authors already using.  However, there is definite room for growth, and this is where you guys come in.  We only have limited resources with which to expand and deepen the API offerings, and we'd like to prioritize it based on your feedback.  The API will be a long-term ongoing project, but where would you like to see us start?

To get this party started: Wormopolis, Chris, Peter, Todge, ®i©hie, Chris, Pebble, Shorty

[Wormopolis]

maybe start with listing what you already have so everyone is on the same page?

[Tim Camara]

Things we already want to improve (off the top of my head, in no particular order):

1. More examples
2. Post-level functionality similar to that of the thread-level functionality in the list_manager class
3. Input field generation

[Wormopolis]

Interface to and from the WYSIWYG editors so that it isnt as complicated to make changes (for example making a button that surrounds text in the editors with a custom tag). I realize Eton found a solution, but something more user friendly would be appropriate.

access to some of the AJAX functions (limited likely) for getting data that isnt on the page (like member data or post data).

[Pebble]

Thanks for this. After a quick browse there are already a couple of functions in there that I wish I'd known about!
I'll have a proper look tomorrow and see what could be added.

As an improvement, could an example line of code be given with each part of the documentation. There are a couple I saw that aren't clear, but my heads a bit frazzled at the moment, maybe I need some sleep....

[Wormopolis]

and thank you for adding the key push/pop/append/prepend functionality!

[Chris]

Oct 17, 2013 16:21:45 GMT -8 Wormopolis said:

access to some of the AJAX functions (limited likely) for getting data that isn't on the page (like member data or post data).

Perhaps it could be done the way I have seen in other APIs where the developer (or plugin if easier) is given a key to uniquely identify them/it then that key is used to meter the number of requests in order to rate limit the resource, this key/identifier is most likely already in place from what I gather. If a plugin (across all forums or perhaps on a per forum basis) exceeds a set amount of request within a 24 hour period (arbitrarily chosen) that plugin is given a penalty timeout where none of its requests are honored. This will be a strong deterrent for developers since not only would this have a significant impact on their reputation but users would be shunning poorly written plugins that exhibit such behavior (think search server down for examples of [unwarranted] backlashes against plugins).

Rate limits were used in V4 on things such as exalt/smite (1 hour) and posting (15 seconds) so it is not some foreign concept. This could perhaps also include regular key transactions to limit overuse and make these limitations triggered by default for plugins that have not been submitted to the online library. This way someone would be unable to create a custom plugin that intentionally abuses the system then distribute it unsubmitted or even more likely keep it as an unsubmitted plugin to benefit the members of a particular forum since restrictions will apply to all but the listed developers (max 8?). The development process would be unaffected by these restrictions since the system is capable of determining the original author of a plugin if it can offer an editable version download. All plugins that need to perform transactions with the server MUST therefore be submitted for approval in order to work with end users and adhere to rate limits.

Authors and/or forums that wish to exceed this base transaction limit could perhaps in the future purchase plans similar to the to the ad-free system to raise that cap thus generating a new revenue stream which I think the accountants would like.

Oct 17, 2013 16:21:45 GMT -8 Wormopolis said:

---

A lot of people resisted the idea of traffic lights when they first came out as well. the new system eventually grew on them

---

A commentary on V5, Obamacare, other?

[DarkPikachu]

request for clearer reference notation

calling something like nl2br() returns a definition error. (name is not defined)
I'm thinking this is more of a class object rather than a direct object as noted in the documentation.

this should be more noted as:
text.nl2br ( text )

style derrived from Python documentation

[Tim Camara]

It's actually pb.text.nl2br('YOUR_STRING_HERE'). The entire API is broken down in this way, you start any call with 'pb.', then any class names, then the function name. This is outlined, albeit briefly, on the homepage of the API.

[Former Member]

I would love a little more freedom when it comes to templates.
Possibly a little control over the board lists & threads. It would be nice to hook into the data(json) as opposed to getting back a view and having to scrape through it, which would also allow a designer much more flexibility. This would be great for board control on custom pages. ie: "/page/board/thread".

Is it possible to add a list feature(array) so we can create an array of data, for say select boxes in the plugin settings ?.
Currently I have to insert a JS component, and a json object, which is a bit of a hacky solution.


Regards,

Ps
Keep up the good work guys/gals

[Tim Camara]

I'm afraid I'm not quite sure what it is you're looking for. I'm not sure what else we can give you in terms of freedom, since you're already free to completely modify the HTML/CSS as needed. If you're referring to which data is loaded on which page, the only reason that's not available for customization is due to optimizations on the back end.

Can you give me an example of this list feature?

[Former Member]

Hi Tim,


As far as the item list, just maybe something to populate an array, to be used with <select> elements.

Currently I would need to do something like this.

plugin->namespace->user_interface->form_fields->code_box

{NOT realworld example}


{
   "regional": {
       "min":0 , "max":1000
   },
   "interstate": {
       "min":2000 , "max":3000
   },
   "dedicated": {
       "min":3000 , "max":6000
   }
}


[Tim Camara]

I would suggest taking a look through proboards.dataHash (the reference hash for dealing with proboards.data() calls) and try playing with proboards.item(). Between those two locations is contained most of the information available to the page about the various items that are being displayed.

[Wormopolis]

It might be important to restate that plugins/headers/footers dont run on the plugin settings page or the admin panel areas in general.

[Texas]

This isn't completely relevant to the API, but from what I gather from the brief description on the API, a global forum key is a key that can be accessed on every page by everyone. So if I set the value of the global key to "hat" then it will be "hat" by everyone that accesses it. Correct?