Just need to include `?pretty=true` to a request and the JSON returned will be formatted. As I was digging in there I think I may consolidate all of the Display logic into a single class and potentially bring back `.json` and `.xml` extensions to dictate what is returned. Would help a ton in scenarios where I have an endpoint that I want to server up a template on error or return JSON on success.
In an effort to only maintain compatibility with the latest version of PHP (currently the 5.5 branch) I dropped the sanity checks if `json_encode` was available as it is always available in PHP 5.2+. Dropping this sanity check also allowed me to remove the wrapper function and the `JSON_AVAILABLE` constant. Ideally I'd like to move towards dropping the `Convert` class entirely but will need a way to convert an array to XML as the `RSS` class still leverages it. One thought is to move that code right into the `RSS` class as it never gets used elsewhere because XML is gross.
Includes AYAH v1.1.7, a static wrapper class and an update to our main include file to handle loading the official AYAH library from the vendors directory.
Instead of making the Module the keeper of validation, moved the actual sanity checks to another class. This makes it stupid easy to use one module's validation (some or all) to validate arbitrary values elsewhere in your system.
Primary key queries should not be cached because the record may not exist today but could exist in the future and because the INSERT logic in PICKLES doesn't do any invalidation of the cache.
If you tried to use the extended array syntax to query against the primary key (id) and passed it an integer instead of an array, an error was occurring. Thanks @geoffoliver !
Pass a Model an optional second or third parameter to force the Model to check the cache before running the query and stashing the results in the key for future queries.
Caching was limited to single row selects against the primary key. Expanded to include cache checking and storing when selecting multiple values against the primary key. Does not work on any other row due to the fact that some rows may have duplicate values and the mapping could get borked pretty quick.
Too much juggling to make sure the proper assets were loaded. Opened up a security issue that allowed some pages to be accessed even if data was missing, just a headache, best to move away from it and allow users to defining custom routing in inde.php. Perhaps down the road allowing a Route class that the user can define everything in.
If you're pulling data against a single column and returning a single column the UID will be cached out to a key that can easily be recalled the next time the same query is executed. On UPDATE and DELETE the corresponding keys are deleted.
Now can access stuff as part of $this. Example: $__form->dobSelect() is now $this->form->dobSelect(). Both syntaxes are valid to allow for some migration time away from the old syntax
Instead of routing to a 404 or home, was just returning [] (empty JSON array). Updated to redirect home for the time being. 404 handling needs to be addressed soon anyway, it's kinda junk right now
It's a bitch to debug and at this point, I'm unsure that there's really any performance improvement by including everything. Also when moving towards namespacing in future revisions, having all of the PHP in a single file is a no-go.
Updated the error handler to allow for better failover during connection errors. Even in a single server setup, still using addServer as it uses passive connections and eliminated the need for an open method.
