[Solar-talk] Solar 0.19.0 released

[Paul M Jones]

Hi everyone,

I just released Solar 0.19.0; you can get it from the usual source.   
The big additions in this release are project-support related.

The Solar_Docs_Apiref 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.)

The related Solar_Docs_Phpdoc class will parse a PHPDoc comment block  
into its summary, narrative, and technical portions.  While nowhere  
near as robust as Greg Beaver's PHPDocumentor, 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).

Solar_Docs_Apiref also makes use of the new Solar_Class_Map, which  
parses a Solar-style file hierarchy and returns an array of class- 
name keys with file-name values.

There is a new Solar_Log class, with adapters for file-based logging  
(good for production), echo-based logging (good for development), and  
multiple log support.

There's one big change in Solar_View: 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.

In line with this, you no longer use Solar_View::addHelperPath(),  
getHelperPath(), or setHelperPath(); instead, you addHelperClass(),  
getHelperClass(), and setHelperClass().  The class-based methods work  
just the same as the path-based methods, except you specify class  
name prefixes instead of path prefixes.  For example, if you used to  
"addHelperPath('Vendor/App/Helper')", you would now "addHelperClass 
('Vendor_App_Helper')".  Then helpers of that class will be used  
before the Solar_View_Helper classes are used.

Also in line with this, the Solar_View 'helper_path' config key has  
been renamed 'helper_class', and a new Solar_Controller_Page config  
key 'helper_class' has been added so that page controllers know where  
helpers are (this is to support view helpers attached to layouts).

Finally, Solar_Test_Suite usage has changed a bit.  Instead of  
setting a 'sub' key to specify that you want to run a sub-series of  
class tests, you specify that same value when calling  
Solar_Test_Suite::run($sub).

As usual, please review the change notes for fuller descriptions.


Future Plans
------------

The next release will concentrate on feature requests, and (sorry!)  
another class reorganization so as to be more consistent with pattern- 
based names, and to reduce the depth of some parts of the hierarchy.

None of the reorganizational changes should require more than a  
simple search-and-replace on the existing code base when complete.   
For example, Solar_Sql_Driver will become Solar_Sql_Adapter,  
Solar_Cache_File will become Solar_Cache_Adapter_File, and so on.

The User subclasses (Auth, Role, Access) will come to the top of the  
hierarchy, so Solar_User_Auth will become Solar_Auth, and the  
Solar_User_Auth_Driver files will become Solar_Auth_Adapter files.

There are other change ideas too; you can see those in the todo file  
here:

     http://solarphp.com/svn/todo/todo.txt


As always, if there are questions, comments, or concerns, please let  
me know at your convenience, and thank you for using Solar.


-- pmj