{
    "href": "/post/2005/03/28/solar-005-released/",
    "relId": "2005/03/28/solar-005-released",
    "title": "Solar 0.0.5 Released",
    "author": "pmjones",
    "markup": "html",
    "tags": [
        {
            "href": "/tag/php/",
            "relId": "php",
            "title": "PHP",
            "author": null,
            "created": null,
            "updated": [],
            "markup": "markdown"
        },
        {
            "href": "/tag/solar/",
            "relId": "solar",
            "title": "Solar",
            "author": null,
            "created": null,
            "updated": [],
            "markup": "markdown"
        }
    ],
    "created": "2005-03-28 22:20:13 UTC",
    "updated": [
        "2005-03-28 22:20:13 UTC"
    ],
    "html": "<p><a href=\"http://solarphp.com/\">Solar</a> is a simple object library and application repository for PHP5.  Solar stresses comprehensibility and simplicity; reusable code should be easy to understand, and that's what I strive for in Solar.  It is written with worldwide application distribution in mind, so things like localization are built in from the start.</p>\n<p>This release includes a new and very important component: the \"Solar_App\" class.  It takes some superficial hints from Ruby on Rails (but is definitely not comparable to RoR in any meaningful sense).  Essentially, Solar_App is an application controller class; when you extend it (e.g. to Solar_App_Bugs, the proof-of-concept bug tracker for Solar) it looks for subdirectories called \"controllers\", \"models\", \"views\", and \"helpers\".  (So it looks like I have started to adopt \"real\" MVC methodology after years of shunning it.)</p>\n<p>It's easy enough to define new controller actions: you put your controller scripts in \"controllers\", and for each script you can call an action.  For example, if you have \"edit.php\" in controllers/, Solar_App will call it if the \"action\" URL variable is \"edit\" (\"http://example.com/index.php?action=edit\").  There's a little more to it than that, of course, but the source code is thoroughly commented and should provide a good full-up example for now (it is a proof-of-concept, after all).</p>\n<p>One nice thing about distributing apps this way is that they never have to leave the Solar directory itself; you can just create a simple PHP file (5-6 lines) to start Solar, get the application object, and call its output() method; the entire application sits outside the web root.  Pretty nifty; you can see an example in the Solar_App_Bugs package (included in the full Solar package).</p>\n<p>The full change notes are:</p>\n<p>* This is a public development release, and is not yet stable.</p>\n<p>* Added Solar_Super class for retrieving superglobals, modified Solar.php to use it</p>\n<p>* Added Solar::cookie() method for retrieving cookie values.</p>\n<p>* Added Solar::session() method for retrieving session data.</p>\n<p>* Added new Solar_App application controller class (with standard directory structure using an MVC architecture inspired by Ruby-on-Rails)</p>\n<p>* Solar_User_Auth 'action*' keys and values renamed to 'op*' (Solar_App now owns the 'action' keyword)</p>\n<p>* Added validation for 'new' and 'edit' forms in Solar_Cell_Bugs</p>\n<p>* Added Solar_App_Bugs proof-of-concept application based on Solar_App</p>\n<p>You can download this release, read the API docs, or join the mailing list -- just visit <a href=\"http://solarphp.com\">http://solarphp.com</a>.</p>\n"
}