Last night, I released version 0.24.0 of Solar, the simple object library and application repository. Solar is a PHP 5 framework for rapid application development.
\nOn an administrative note, Clay Loveless has set up a Trac installation for us, so now you can report bugs and request enhancements without having to join the Solar-Talk mailing list. You can keep up with the Trac issues via the Solar-Trac mailing list if you like.
\nYou can read the change notes for a full run-down, but there are a few changes in particular that I want to highlight.
\n\nSolar_RequestIn previous releases, the Solar arch-class had a series of methods to read from the superglobals: Solar::post(), for example, would read a $_POST key and return it (or a default value of your choosing if the key did not exist). Those methods and their related support methods have been removed from the arch-class and placed in their own class, the new Solar_Request.
For now, Solar_Request acts as a singleton, since it is tied back to the super globals. Future releases will convert it to a true standalone object, and classes that need access to the request environment will receive a dependency injection of a Solar_Request object.
Whereas you would have used Solar::post() in earlier versions of Solar, you now create a Solar_Request object and use the $request->post() method. Solar_Request provides access to these superglobals after some minimal filtering (essentially just stripping magic quotes):
$_GET\n$_POST\n$_COOKIE\n$_ENV\n$_SERVER\n$_FILES\nWait a minute, there's no \"HTTP\" superglobal! One of the things that Solar_Request does for you is some basic cleaning and normalizing of the $_SERVER['HTTP_*'] values into their own storage array, so you can ask for the HTTP headers directly. For example, to get the value of the \"X-Requested-With\" header, ask for $request->http(\u2018X-Requested-With').
Solar_Request also lets you check how the current request was made:
Many thanks to Clay Loveless for getting Solar_Request up and running.
Solar_SessionSimilar to Solar_Request, Solar_Session (here) provides an interface to the $_SESSION superglobal. It also takes over for the previous Solar_Flash class by providing read-once \"flash\" support via the $_SESSION values.
In Solar, we aggressively segment the global name space so that different classes don't step on each other's toes. Solar_Session makes this segmentation easier, by providing a config key to tell the particular instance what class name space it should be working within the $_SESSION array.
It's not much, but I've added the tiniest bit of Scriptaculous enhancement to the reference application that comes with Solar, Solar_App_Bookmarks. In the \"edit\" view, instead of using a simple class to indicate success or failure of a save, I've put in a pair of effect calls:
// output a form from the \"formdata\" processor\necho $this->form(array('id' => 'form-bookmark'))\n ->auto($this->formdata)\n // ...\n ->fetch();\n\n// add an effect for success message lists\n$this->jsScriptaculous()->effect->highlight(\n \"#form-bookmark ul.success\",\n array(\n 'duration' => 3,\n 'endcolor' => '#aaaaff',\n 'restorecolor' => true,\n )\n);\n\n// add an effect for failure message lists\n$this->jsScriptaculous()->effect->highlight(\n \"#form-bookmark ul.failure\",\n array(\n 'duration' => 3,\n 'endcolor' => '#ffaaaa',\n 'restorecolor' => true,\n )\n);\nThat's all it takes. Again, Clay Loveless has done wonderful work with his JavaScript helpers for Solar.
\n" }