-
Notifications
You must be signed in to change notification settings - Fork 0
Contextual, Extendable Configurations and More
Object-based configurations allow a great deal of control over how your developer's configurations are compiled, but they take time and overhead to author and maintain as changes are made. Additionally, they tend to take more lines of code and time to set up then other configuration methods.
INI, YAML, and XML take more lines of code and create unnecessary complications to the author, while also forcing you to write your configurations as static files that can not intelligently adapt to the needs of your project.
Array configurations I find the most straightforward and fastest to work with than any of the options available to PHP.
Despite their speed to work with, clarity to read, flexibility and power, array-based configurations have not evolved significantly in decades (in most languages, including PHP).
Tempest Tools configurations provide a wide range of new features and functionality which take your configuration options to there next natural state of evolution. This is important because many Tempest Tools features are handled by setting simple configuration settings in your config arrays.
All configurations of Tempest Tools can extend other configurations in the same array. This is to say that the blocks of configuration that you write can use an “extends” key which lets you make any discrete block extend any other block. Now you never have to repeat yourself or worry about changing your configuration settings in more than 1 place as your project evolves. The same kind of inheritance features you previously have only found when working with classes, now also comes to the blocks you create inside your configurations.
Contextual configurations allow your code to automatically adapt to the context it is being run in. For instance, the access rules for your entities can adapt based on any criteria you define -- allowing admins different access rights than users for instance or returning different data through the API when the resource is accessed via a different route, and etc.
Without contextual configurations, I have seen many projects resort to what I call the “Shadow Access Control Layer”. This is when you start putting snippets of code buried throughout your project in order to handle different contexts that your code is being accessed in. Sometimes this new code ends up in nooks and crannies of the project that new developers won’t easily discover or be able to understand. Other times this shadow layer can lead to unexpected results -- such as when your QA personnel is testing functionality using an admin account, when the functionality they are testing has some arcane rules in its shadow layer that produces unexpected results when the user is an admin vs a normal website user accessing it, etc.
With Scribe, you set the configuration context on the route, and also specify a fallback for if that context is not found on a Controller, Repository, or Entity. These contexts are passed down via the chaining features of Scribe to all other Scribe classes that the request interacts with.
Now you have clear blocks in your config file for the different contexts that users can access your code through (such as via an endpoint with user level permissions, or one with admin permissions, or one that is meant to return different data than is generally returned).
These capabilities make the functionality of your application adaptable to every scenario while keeping your code construction clear and readable to anyone versed in Scribe functionality.
Contextual configs go hand in hand with Tempest Tools Extendable config functionality allowing each configuration to extend other similar contexts configurations so no code ever needs to get repeated to achieve the desired result.
Scribe configs allow you to define whether or not the configuration should be interpreted as “Permissive” or not. A “Permissive” config block automatically assumes that all options are permitted unless you specify otherwise, while a “Non-Permissive” config block assumes that all options are not allowed unless you specify otherwise.
For instance, you could specify that a front-end query to your index, may specify a where for every field except for username, or specify that the query may only specify a where that relates to a username (permissive vs nonpermissive).
This simple feature allows you to keep config files as small as possible by only specifying details about your config where necessary.
Any configuration option in Scribe may be substituted with an ArrayExpression. Array expressions are objects, that when encountered will be interpreted, and the interpreted result will be used in lieu of a static value. Array expressions can do the following and more: *Reference anything in the shared array helper via a path -- allowing entries in your configs that point to other data you have stored. *Return strings based on a template -- the template uses path placeholders to reference other data in your shared array helper. *Return the result of a Closure -- any array value can be the result of a Closure, allowing you to process at runtime what the value of the array key should be. Closures are automatically passed a wealth of data automatically allowing your code to make well-informed decisions about what data to return from the closure.
To get a deeper understanding of the basics of the configuration system please see the examples in this wiki as well as the documentation for the Tempest Tools Common project here: