Plugins - Githubissues

This is a concept I'm playing around with. Feel free to add your commentary.

One of the most painful things a developer has to do is make a paginated recordset and a pagination control. Faster doesn't include that because we like the idea of using best-of-breed components and reducing the time required to learn the core framework. We want to keep the core limited. However, it seems suitable that Faster evolve to include a plugins framework just as cool as the one with WordPress, and which lets you install and uninstall functionality like a pagination API.

In a paginated feature, there are really 2 points of frustration:

Figuring out the LIMIT clause for MySQL with Offset and Limit values, based on the page that is passed via the URL, such as /1, /2, /3 on the end of the URL (which may then follow with optional query parameters).
Drawing the control so that it handles First, Prev, Next, Last, and then 5 slots (where possible) to let one select a slot within those 5 slots at a time unless they click First, Prev, Next, or Last. There's a lot more to this, but you know the deal if you've ever searched on Google for something and paginated through it.

To implement this in Faster, it appears that we would want to have a "_plugins" folder under the "app" folder. In that folder, one would create new directories for their plugins, just like WordPress has. Then, we need like a plugin initializer script, which we could call init.php. This would load our callback functions into the Faster API at critical event junctures. As Faster runs through its typical bootstrap -> front controller -> page controller -> model -> database -> model -> page controller -> view var injection -> view display path, it would have event junctures we could intercept, receiving all critical data so that we can modify it before it moves to the next juncture. Our init.php script of our plugin could load those callback functions into a Faster master plugin table.

We can handle in our page controller the parsing of the URL to get the page number. Now we need our LIMIT clause parameters of Offset and Limit. Our Pagination plugin can have a callback when the page controller loads, instantiating a $Paginator class object. We can then use it to give us our Offset and Limit. The other thing we need is to render a typical pagination control in HTML. So, since $Paginator class object is loaded in memory and available to our page controller, we can call $Paginator, pass it some of these parameters, and it can render the HTML for us, which we can then use to display on the page.

As for the event table, we can cache it in a session array variable. No database necessary. It would load the plugin callbacks into the event table and cache it for the remainder of a user session. That way, unless a plugin folder's md5 checksum doesn't change, it keeps this cached and doesn't have to keep reloading that table all the time.

As the event junctures occur, they can then call the callbacks with call_user_func_array() and pass it the relevant data one usually needs at these junctures. (We can define this further in a Plugin API Codex.)

Now one thing we need to think about here is that someone may use Faster for like their product catalog application, and may want to offer a plugin API feature for it. (That's a common thing in product catalogs.) Therefore, we offer this in the above spec, but we're autoloading those plugins. We need a setting in the app/config.php to not autoload, and to require that one amend a file like app/_plugins/installed.php on what plugins are installed or not. That way, one's admin page of their product catalog application can install and uninstall plugins with ease.

Thoughts?

volomike / Faster

Plugins #14