Solar 0.24.0 Released

By | September 26, 2006

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.

On 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.

You can read the change notes for a full run-down, but there are a few changes in particular that I want to highlight.

Solar_Request

In 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() — $_GET
  • post() — $_POST
  • cookie() — $_COOKIE
  • env() — $_ENV
  • server() — $_SERVER
  • files() — $_FILES
  • http() — …

Wait 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(‘X-Requested-With’).

Solar_Request also lets you check how the current request was made:

  • isGet() is true if this was a GET request
  • isPost() is true if this was a POST request
  • isPut() is true if this was a PUT request
  • isDelete() is true if this was a DELETE request
  • isXml() is true if this was an XMLHTTP request (Ajax!)

Many thanks to Clay Loveless for getting Solar_Request up and running.

Solar_Session

Similar 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.

Progressive Ajax Enhancement

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
echo $this->form(array('id' => 'form-bookmark'))
      ->auto($this->formdata)
      // ...
      ->fetch();

// add an effect for success message lists
$this->jsScriptaculous()->effect->highlight(
    "#form-bookmark ul.success",
    array(
        'duration' => 3,
        'endcolor' => '#aaaaff',
        'restorecolor' => true,
    )
);

// add an effect for failure message lists
$this->jsScriptaculous()->effect->highlight(
    "#form-bookmark ul.failure",
    array(
        'duration' => 3,
        'endcolor' => '#ffaaaa',
        'restorecolor' => true,
    )
);

That’s all it takes. Again, Clay Loveless has done wonderful work with his JavaScript helpers for Solar.

5 thoughts on “Solar 0.24.0 Released

  1. Pingback: PHPDeveloper.org

  2. Matt Mitchell

    Just wondering if when a new release will be coming? Thanks!

    - Matt

    Reply
  3. Koen Speelmeijer

    I don’t know wether this is a known issue or not, but when I try to set up a new application I get the error ’404: Page ‘Solar’ unknown.’. When I trace the error I see that it’s created in Solar_Controller_Front. Browsing the code I discover that somehow it allways returns ‘Solar’ as the $page var, even though I keep on changing my url to alternatives like ‘index.php/Hello’, ‘index.php/Test’, ‘index.php/Foo’.

    This was because $page was created on the wrong way.
    The original code was:


    // pull the page name off the top of the path, use the default
    // if none specified
    $page = array_shift($uri->path);

    Is it just me or should it be array_pop instead? I find this quite suprising because it’s the Front Controller, the first thing used when setting up an app.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *