aurora 0.9.6 released
today we celebrate another neat release of aurora1 
. this time the motto was all around bug-fixing, stabilizing and grinding the corners. apart from this, some significant things have changed under the hood.
.htaccess won’t be written automatically anymore
use ./run –htaccess-write to do this manually.
auth, db, model and validation have been extracted into a plugin
this was a necessary first step to make way for the upcoming shiny new db-api along auth and validation modules. i’ll write something about them as soon as possible. use “ama -pur -pi db1_with_auth” within your project to get the old stuff back.
optional extension.method call style
in order to easily know which extension holds which method when looking at a cli or url file, extmod now understands an optional extension.method style ( instead of naming the method only ). application::run (), the cli- and url-wrapper are aware of this and work hand in hand with extmod. to close the last hole, extmod provides you a __call ( $func, $args ) method which you can use to call methods with the $ext_name.$method style, too. appls and libs extend from extmod so this functionality is always right at your hand.
external calls with extmod
this means that calling $appl -> _call_external ( $callable, $args ) will initialize the appl as usual and then call the given callable ( same as in php itself ) with args. you may use this to mimic template rendering from a specific appl while actually being in a different lib or something like that. this also ensures proper direct template rendering from an url file without the need for a one-liner-method.
support colliding method names across extensions
enabling config/boot/extmod_drop_duplicates makes it possible to have the same method names accross extensions within the same appl or lib. this is especially neat when writing rest-like interfaces. the backdraw is that methods that collide won’t be callable thru the appl or lib as usual. you have to use the $ext_name.$method style in your url or cli files.
semi caching while in development environment
long time i thought about enabling some minimal caching while in development. some day i had an idea how to do this so that aurora and your project will startup much faster while always keeping track of changes in your files. this leaded me to semi-caching which does excactly that. while in production environment aurora won’t check the config files anymore after creating the cache.
calling methods from appl or lib emit signals
this can be handy to interfere with calls to appls, libs and their extension.methods to check for authentication or if a user may see a certain website. a kind of aspect oriented approach.
i’ve been using this to directly render templates from an url file ( mini-cms ) while always calling the auth lib and checking if the user may see the page or not. the latter case would simply redirect to the main page.
in another project i’m using signals to catch calls from an url file to certain extensions and present a login page or not. here complete extensions are blocked from the user if necessary.
adaptive template rendering
this sounds much more complicated than it is. the problem is that one method may not be equally good for rendering all template blocks. after some testing i found out that there can be mainly two methods in use, choosing one of them according to the size of the block to render. in the end this approch found use in many small places improving the overall rendering speed a bit.
user-definable open basedirs
copying the config/web.yml file into your project and taking a look into it will reveal an array called public_folders. this can be used to let nearly every folder be accessible from the web. –htaccess-write will write special rules for them. you may use this approach to share images, css, javascript or something else accross all your appls and libs in your project. i use it to provide a download folder.
pitfall: template’s $_ var
until recently i really thought $_ was broken. but then i logically investigated the situation just to find out that it’s perfectly fine. the thing is: you have to use at least $_/ and never forget the trailing slash. this way even if $_ is empty, a slash is available resulting in a valid base url.
notes and changelog
http://feedntrack.de/l/1/4xt80
download page
http://feedntrack.de/l/1/1587f
hopefully this has provided you a little overview of what is new and what has been improved so far.
now get coding .
–