Solar 0.7.0-devel released

After too-long a hiatus, I’ve released Solar 0.7.0; you can get it from our PEAR channel server here. (Solar is a simple object library and application repository for PHP5; it is similar to PEAR and Horde, and might be described as a library-like framework for MVC development.)

The interim was filled with lots of improvements, not the least of which are some new classes and fixes from Matthew Weier O’Phinney. His work on the forms portions has been helpful and enlightening; I think we may now have a true MVC contender against HTML_QuickForm when combined with the improved form plugin for Savant3.

The change notes are quite long; you can read them below.

* WARNING: This is a public development release, and is not yet stable.

* Added new class, Solar_Filter, to filter data.  This is a companion to
Solar_Valid and is currently used mostly for prefiltering submitted form
values.  Thanks, Matthew Weier O'Phinney.

* Added new class, Solar_Form_Loader, to allow loading of form elements
from external sources.  Currently has only one method, fromXml(), to load
elements from a SimpleXML file.  Thanks, Matthew Weier O'Phinney.

* Solar:

  * New protected method environment() performs some standardized
  environment setup at Solar::start() time.  Solar now
  automatically...

    * Unsets all registered global variables if 'register_globals'
    is on.

    * Unsets $_REQUEST (you should use Solar::get(), ::post(), and
    ::cookie() for security reasons).

    * Dispels magic quotes from get/post/cookie/files/server
    superglobals if 'magic_quotes_gpc' is on; handles Sybase quotes
    as well as slashed quotes.

    * Turns off 'magic_quotes_runtime' and 'magic_quotes_sybase' so
    that SQL sources do not quote values on retrieval.

  * Solar::start() no longer sets error_reporting and display_errors.
   Per note from Matthew Weier O'Phinney.

  * Fixed bug where start() was calling __solar('start') instead of
  solar('start') on shared objects (the latter is correct).

  * Added locale strings for 'VALID_*' keys to support default
  validation messages in Solar_Sql and Solar_Form.

  * You can now specify an alternate config sources as the only
  parameter to calling Solar::start().  Pass an array to populate
  $config directly, an object to populate from the object properties,
  or a string to indicate an arbitrary path to a config file.  The
  default remains to load $config from the file defined by the
  SOLAR_CONFIG_PATH constant.  Per discussion with Matthew Weier
  O'Phinney.

* Solar_App_*:

  * View scripts now use the new Savant3 auto-escaping function
  and the new Solar_Template plugin locale() for localized strings.

* Solar_Base:

  * Constructor now allows passing of a string as the $config value,
  which is subsequently treated as a path to a php-array config file
  (this means you can have a config file specifically for a class
  instead of having to pass an array).

* Solar_Filter:

  * The alphanumeric() method is deprecated; use alnum() instead, it's
  easier to type. The alphanumeric() method will be removed after the
  0.7.0 release.

* Solar_Form:

  * BC BREAK:  Made $config protected like every other Solar class.
  Config values are now populated through to the new $attribs
  property, which stores attributes for the form tag itself.  If you
  were using $config to retrive form-tag attributes, you should now
  use $attribs instead.  Updated Solar_App_* views to reflect this
  change.

  * Added prefiltering of submitted values; use addFilter() method, or
  add a 'filter' key to the element array when using setElement().
  Thanks, Matthew Weier O'Phinney.

  * The populate() and validate() methods now take an optional
  paramter; if that param is an array, it is used for the $submitted
  property.  This allows you to pick the value population source
  instead of having to choose only from $_GET and $_POST.  Thanks,
  Matthew Weier O'Phinney.

  * Added reset() method to restore form to its originally-configured
  state.

  * Added load() method to load attributes and elements (with filters

  and validations) from an external source.  Per discussions with
  Matthew Weier O'Phinney.

  * When no message is given for validation, attempt to get a default
  validation message from Solar/Locale/en_US.php based on the method
  used for validation (c.f. the new VALID_* translation keys).

* Solar_Sql:

  * In quote(), changed is_double() to is_float() to match with column
  pseudo-type name.

* Solar_Super:

  * No longer uses the magicStripSlashes() filter when values are
  fetched, because the Solar environment setup now takes care of
  slashes at start() time.

* Solar_Template:

  * Updated to Savant3 alpha2 and converted all Solar_App_* view
  scripts to use its new auto-escaping functions. See change notes at
  http://phpsavant.com/yawiki/index.php?area=Savant3.  Of note, the
  'form' plugin will change in the next release, and the 'scrub'
  plugin will disappear in the next release.

  * Added new 'Plugin/' directory with new 'locale' plugin to help
  with locale transalations (you can now use $this->locale('KEY')
  instead of Solar::locale('Solar', 'KEY')).  All Solar_App_* view
  scripts now use this plugin.

  * Adds the 'Solar/Template/Plugin/' directory to the top of the
  configured resource_path automatically.

* Solar_Valid:

  * The alphanumeric() method is deprecated; use alnum() instead, it's
  easier to type. The alphanumeric() method will be removed after the
  0.7.0 release.
Are you stuck with a legacy PHP application? You should buy my book because it gives you a step-by-step guide to improving your codebase, all while keeping it running the whole time.
Share This!Share on Google+Share on FacebookTweet about this on TwitterShare on RedditShare on LinkedIn

8 thoughts on “Solar 0.7.0-devel released

  1. Added new ‘Plugin/’ directory with new ‘locale’ plugin to help
    with locale transalations (you can now use $this->locale(‘KEY’)
    instead of Solar::locale(‘Solar’, ‘KEY’)). All Solar_App_* view
    scripts now use this plugin.

    Could you kindly explain more on this features? Does it mean that it can help me to translate a query to a content items written in one human language into a query to a coresponding content items written in another human language?

    Thanks in advance.

    Shaman

  2. Hi, Shaman, I’d be happy to give some more details.

    First, let me quote from the Main:SolarGoals page: “Although English is the de-facto language of developers worldwide, end-users don’t want to see English-only labels, buttons, and text. Solar classes come with easy built-in text localization so that it’s easy to translate into languages other than English.”)

    Next, you need to read the “locale” documentation here:

    Main:LocaleFiles

    The Solar_Locale Class

    With those under your belt, you will know how to create a locale file (essentially a PHP array of key-value pairs) and how to request a translation for a particular class and key. Normally, because templates are not derived from Solar_Base, you would need to call Solar::locale(‘Class_Name’, ‘KEYWORD’). It gets tedious typing that same class name over and over.

    So now, in your templates, you can set the default class for translations with $this->locale(‘Class_Name::’) and then get translated text using $this->locale(‘KEYWORD’). If you need translations from a class other than the default, you can prefix with the class name and two colons, e.g., $this->locale(‘Something_Else::ANOTHER_KEYWORD’).

    Hope this begins to help.

  3. It means that Solar can help us to prepare static label texts, button, in multilanguage. What about dymamic contents? Does Solar have any support to multilanguage websites that can display a piece of content in many language: an articles, a news,

    Ex: I have a web site for a hotel: The main language is English of course. But my customers is French, German… Therefore, I need to prepare my contents (stotred in database) in 3 languages: a piece of English news will have 2 coresponding piece of news in French and German. If an user wish to switch to a language other than English, he/she will read the news in the coresponding language if any.

    Thanks

  4. Hi Tohe —

    Right now, Solar is primarily a library-and-framework, not a content management system. You can build applications with Solar, but it is not itself an application (although it does come with two proof-of-concept applications built on Solar principles).

    Solar does not have a built-in content library; for now, that part is up to individual users to build. I don’t know yet if Solar will have a “standard” CMS library component; if it does, multi-language facilities should be part of it.

    Sorry to disappoint. 🙁

  5. I spent a little time this morning looking over solar. I’m a PHP-based web developer, and have built several applications from scratch. How I dislike re-inventing the wheel over and over.

    I’ve been looking into Ruby on Rails of course, and Django for python, and even more full-featured (but rigid) CMS frameworks like Drupal.

    I see you’re involved in Solar, DB_Table, Savant, etc. My question is, currently, what do you consider the ideal technology mix if you needed to build a new medium-sized CMS in PHP? (We can assume PHP5).

    Thanks,
    Daniel Talsky

  6. Hi Daniel —

    I wish I were widely-experienced enough to know for-sure an “ideal” for anything. I have seen the RoR demo and it looks great, but I think it glosses over the maintenance aspect of an application’s life cycle. I’ve heard of Django second-hand.

    However, I have not programmed much outside of PHP in the past five years (some Java, some JS, some Perl, but that’s it). For that reason, I can’t offer useful comparisons between PHP as a language and RoR or Django as frameworks. I would point you to the guys at lesscode.org, who have a good article (and good comments) with more information here.

    So to answer your question directly, my ideal is of course PHP, as it’s what I’m using. I’ve been very happy with it, and I do not yet see any compelling reason to move away from it for web development. When I do, you can be sure I’ll start evangelizing it at every opportunity.

    I hope this helps; let me know if it does not.

    p.s. Also see Quoderat’s comparsion of PHP and Rails.

  7. Right, I wasn’t really asking for a comparison with other technologies. I was mainly asking, what IS that mix of PHP technologies you like? All the ones you have listed in your side bar?

  8. Hi again Daniel —

    I guess I took your question too literally (or perhaps too figuratively? whatever :-).

    Yes, the sidebar lists my favorites, but note that I am the primary author on those projects, so of course I am biased. The one authorship exception (sort of) is Yawp, which is mostly glue-code for a collection of projects that were *not* written by me, all of which come from PEAR: Auth, Benchmark_Timer, DB, Cache_Lite, Log, and Var_Dump.

    My new favorite, though, is Solar, which is essentially a collection of my favorite PEAR capabilities, each written from scratch to be PHP5 E_STRICT and internally consistent with each other.

    Hope this helps; again, let me know if it does not, or if you have more questions.

Leave a Reply

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