Dec 09
2
Clay Brainstorming
I’ve been trying to be a little more open with what I’m working on for Clay, hence the ‘Framework for the 10s’ series. So…here’s some brainstorming as a blog.
I’ve been trying to figure out how to separate the use of APIs and applications as backend and frontend (with backend capabilities). I also want to leave the framework open enough where developers can create their own tools that easily override Clay’s default ones, but most of those tools will have a GUI, which means they have to be an application, and therefore have to be called explicitly using app::load(). What I’ve come up with is adding an app::alias() function to call a generic application name, which the actual returned application/application function can be specified by a configuration setting. This would not only make it easier for developers to migrate to their own tools, but would likely ease Clay upgrades down the road. Of course there is a way to explicitly deny an API of having a GUI, but I’m trying to make it easier to avoid the temptation and not close off the option if it is a must.
One of the many other concepts I’m trying to perfect is the use of extensions and plug-ins in Clay. What I’m considering is classifying all external API and Application functionality as a Service. Each would register their services with the framework on installation and the framework would use the appropriate or specified service when requested by another API or Application. Services would include direct content plug-ins, blocks, extensions, hooks, transformations, etc. Once again, this implementation would leave developers with the most choices and not close them off to only the functionality currently available within the framework.
Finally, for the sake of this blog, I’m considering using a packages approach to ‘Core’ installations. The Clay ‘installer’ does not actually have any database requirements, instead it uses tools provided by APIs and Applications, which means it is entirely customizable (it is actually it’s own web site, using Clay’s multi-configuration feature). To go a step beyond that (and for the sake of sanity), packages would allow a developer to create a package with set requirements and a functionality set to go with it. For instance, I could create a Message Board system (like PHPBB) using Clay’s APIs as the backend and provide a package that would tell Clay which applications/APIs/etc it needed to run. Clay would then set up the package from its installer and ensure all dependencies were met, as well as install the applications and APIs.