{
    "href": "/post/2006/05/25/solar-0190-released/",
    "relId": "2006/05/25/solar-0190-released",
    "title": "Solar 0.19.0 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": "2006-05-25 13:44:59 UTC",
    "updated": [
        "2006-05-25 13:44:59 UTC"
    ],
    "html": "<p>(<a href=\"http://solarphp.com\">Solar</a>, the simple object library and application repository for PHP5, is both a library and framework for developing web applications in PHP5.)</p>\n<p>The single biggest change in this release is in the license; we have moved from LGPL to New BSD.</p>\n<p>The main additions in this release are project-support related.</p>\n<ul>\n<li>The <strong>Solar_Docs_Apiref</strong> class will read an entire Solar-style file hierarchy and parse the inline documentation into an array; you can then build a writer of your own to take that array and generate documentation files from it.  (This is how I build the API reference documentation for the Solar web site.)</li>\n<li>The related <strong>Solar_Docs_Phpdoc</strong> class will parse a PHPDoc comment block into its summary, narrative, and technical portions.  While nowhere near as robust or full-featured as <a href=\"http://phpdoc.org\">PHPDocumentor</a>, I think the internals of Solar_Docs_Phpdoc are much easier to understand.  It doesn't support inline tags, but most of the important block tags are recognized and parsed appropriately (@var, @param, @return, @throws, etc).</li>\n<li>Solar_Docs_Apiref also makes use of the new <strong>Solar_Class_Map</strong>, which parses a Solar-style file hierarchy and returns an array of class-name keys with file-name values.</li>\n<li>There is a new <strong>Solar_Log</strong> class, with adapters for file-based logging (good for production), echo-based logging (good for development), and multiple log support.</li>\n</ul>\n<p>There's one big change in <strong>Solar_View</strong>: instead of custom helper locations being defined by paths, they are now defined by class names.  This means your custom helpers no longer need to be named 'Solar_View_Helper_*'; you can now name them as is proper for their location in the file system.  For example, if your helper classes are in the \"Vendor/App/Helper/*\" directory, you now name each helper class \"Vendor_App_Helper_*\".  This makes helper class names consistent with the rest of Solar.</p>\n<p>In line with this, you no longer use Solar_View::addHelperPath(),<br>\ngetHelperPath(), or setHelperPath(); instead, you addHelperClass(),<br>\ngetHelperClass(), and setHelperClass().  The class-based methods work<br>\njust the same as the path-based methods, except you specify class<br>\nname prefixes instead of path prefixes.  For example, if you used to<br>\n\"addHelperPath('Vendor/App/Helper')\", you would now \"addHelperClass<br>\n('Vendor_App_Helper')\".  Then helpers of that class will be used<br>\nbefore the Solar_View_Helper classes are used.</p>\n<p>Also in line with this, the Solar_View 'helper_path' config key has<br>\nbeen renamed 'helper_class', and a new Solar_Controller_Page config<br>\nkey 'helper_class' has been added so that page controllers know where<br>\nhelpers are (this is to support view helpers attached to layouts).</p>\n<p>Finally, <strong>Solar_Test_Suite</strong> usage has changed a bit.  Instead of<br>\nsetting a 'sub' key to specify that you want to run a sub-series of<br>\nclass tests, you specify that same value when calling<br>\nSolar_Test_Suite::run($sub).</p>\n<h3>Future Plans</h3>\n<p>The next release will concentrate on feature requests, and (sorry!)<br>\nanother class reorganization so as to be more consistent with pattern-<br>\nbased names, and to reduce the depth of some parts of the hierarchy.</p>\n<p>None of the reorganizational changes should require more than a<br>\nsimple search-and-replace on the existing code base when complete.<br>\nFor example, Solar_Sql_Driver will become Solar_Sql_Adapter,<br>\nSolar_Cache_File will become Solar_Cache_Adapter_File, and so on.</p>\n<p>The User subclasses (Auth, Role, Access) will come to the top of the<br>\nhierarchy, so Solar_User_Auth will become Solar_Auth, and the<br>\nSolar_User_Auth_Driver files will become Solar_Auth_Adapter files.</p>\n<p>There are other change ideas too; you can see those in the todo file<br>\n<a href=\"http://solarphp.com/svn/todo/todo.txt\">here</a>.</p>\n"
}