First post on 1.1 changes, as much as I’ve talked about them in the past, then datamanagers become more and more an integral part of the core of Engine. In 1.1 I’ve spend quite some time on optimizing the API and making sure that each manager validate input correctly and syncs it correctly.
New datamanagers
Originally 1.0 shipped with just a few datamanagers:
- session
- style
- user
- usergroup
In 1.1, more datamanagers have been added to accompany the newly added tools in the DevTools application:
- datastore
- option
- optioncategory
- permission
- template
While these new ones doesn’t cover all the remaining abilities of the core framework, then these help make existing ones more feature-complete, like the ‘template’ datamanager thats connected to the ‘style’ for example.
As mentioned, not all things can be controlled by datamanagers, yet. In 1.1, 2/3 of all the things that couldn’t be managed by datamanagers, can now be. What still is missing, by intention in 1.1 is:
- language
- phrase
- phrasegroup
These have been left out for 1.2, due to the big focus 1.2 will have on internationalization.
Hooks API
Previously in 1.0, datamanagers came with 1 somewhat baked-in hook that datamanagers could choose to implement, called APICache (API – Prefix, Cache – Name), while only the location of hooks have changed for this particular one, two new have found its way to the core and the API that executes hooks have been made public, so applications that chooses to override it, can do so.
The new ones that have been added in 1.1 is:
- Virtual: Calls a method named ‘virtual’, with the field, and the data for that field
- VirtualField: Calls a method named ‘virtual<Field>’, with the data for that field
- Resetable: This method is baked in, as it tells the datamanager base, that a datamanager may reset it self to its original state.
While these work essentially as the ‘Cache’ hook, then they should differ in terms of their functions.
Validation
Validation in 1.1 of fields have been rewritten from scratch and all methods have been well tested to make sure that consistent data can be passed to the datamanager.
While this is just a first step towards the direction, I personally wanna go for, then this suits the 1.1 series much better, as some of these rewrites have decoupled the logic between the previous ‘Filter’ component (now named ‘Input’) and made the datamanager base more self contained. For example, the ‘callback’ method no longer exists in the ‘Input’ class, nor does the ‘STRING_EMPTY’ constant.
Another feature, that I believe is really powerful and causes less code writing, is the new validation constant ‘VALIDATE_IDENTIFIER’, this makes the datamanager base automatically validate the identifier to ensure unique keys in the database, remain unique whilst causes less validation code to be written for each datamanager.
Contexts
While this probably should have been in the ‘Hooks’ section, then I think its notable to mention contexts. Contexts are a way telling the datamanager where we are now, and what we are executing, which makes hooks less complicated to design and implement by making the datamanager deal with logic for each context internally.
Currently theres 4 contexts:
- CONTEXT_NONE – Indicates that we’re not in a special method, could be validation of callbacks for example
- CONTEXT_SAVE – Called in save()
- CONTEXT_DELETE – Called in delete()
- CONTEXT_VOID – Indicates that this datamanager instance now is void and cannot do anything (after a successful delete for example)
While you may be wondering while there is no ‘CONTEXT_RESET’ as mentioned the new Resetable hook, this is because it is a hook that requires each datamanager that implements it, implement this method, meaning that its only called in one context hence why no context in the base.
Hope this gave a bit of insight of datamanagers and what they bring in 1.1,
-K
