ASP-Style Programming in PHP?

An old buddy of mine wants to start using PHP, but the problem is that he’s been working with Microsoft technologies for so long, he doesn’t get “the PHP way”. His background, for many years, has been with ASP.NET, COM, and those sorts of things.

As it turns out, there’s a PHP framework out there that maps well to “the ASP.NET way”: Prado.

http://www.pradosoft.com/

They’re at a 3.0 release as of a week ago, and won the Zend PHP5 competition last year, so that should speak to the quality of the software. From the page about PRADO we can see they base their concepts on a component model, so it’s very like Apache Tapestry, Borland Delphi, and (for the guy who asked me originally) Microsoft ASP:

Most PHP frameworks are trying to establish a loose standard of organizing PHP programming, most preferably the MVC (model-view-controller) model. It is difficult to compare PRADO with these frameworks because they have different focuses. What we can say is, PRADO is more like a high-level language built upon PHP while those MVC frameworks stand for the best programming practices. Both aim to help developers to rapidly complete Web application development. The advantage of PRADO is its rich set of prebuilt powerful components and extreme reusability of the PRADO code, while the advantage of the MVC frameworks is the complete separation of model, view and controller, which greatly facilitates team integration.

I can see that PRADO is very much *not* my style; I don’t know a lot of open-source scripter types (Perl/PHP/Python/Ruby) who would really go for this, as it seems over-architected to me. This is not meant as a critical point against PRADO, because it obviously fills the needs for those who like that style of programming. Personally, I don’t really want another language on top of PHP (this relates back to why I started Savant; i.e., as a response to Smarty). But if you’re used to Microsoft or Java, I can see how this would be an easy way to get on board in the open-source world and start using PHP with your previous non-PHP habits.

Which brings me to a philosophical point: is there a better phrase than “the PHP way” to describe the way we expect PHP apps to be built, or some sort of metaphor that encapsulates the concepts related to “the PHP way”? Not just MVC, because PRADO appears to do that, but some other way of describing succinctly how a PHP app “ought” to be. Maybe there isn’t one single description.

Having said that, I think these template notes from the WACT project might be useful hints; see also here. My bet is that the greater majority of PHP/Perl/Python/Ruby programmers are “imperative” guys than “declarative” guys, and maybe that plays into what a proper metaphor might be. Prado/ASP.NET are clearly more declarative, and Savant/Solar/etc are clearly more imperative. Perhaps Less Code is related to the metaphor we want.

I’d be interested to hear comments and feedback, if for no other reason than to compare and contrast the different approaches.

UPDATE (2006-05-04): Interesting analysis from here; note that it is originally from Dec 2005.

Instant Forms from Tables with Solar

I was talking with Matthew this morning, and he asked if I was setting up a methodology to create forms using table definitions. My answer was “yes!”.

Here’s an example: 2 lines to start Solar, 2 lines to connect to an existing Solar_Sql_Table, 2 lines to create a Solar_Form using the table columns, and 2 lines to display it with Solar_View using the associated form helper. (The “Solar_Model_Nodes” table is part of the existing Solar_Content domain model.)

<?php
// prelims
require 'Solar.php';
Solar::start();

// sql and table connection
Solar::register('sql', 'Solar_Sql');
$table = Solar::factory('Solar_Model_Nodes');

// get a form and load elements from the table
$form = Solar::factory('Solar_Form');
$form->load('Solar_Form_Load_Table', $table);

// display the form
$view = Solar::factory('Solar_View');
echo $view->form($form);

// done!
Solar::stop();
?>

This creates an element for each column and a form-level validation based on the column datatype. Number and string columns get a properly-sized “text” element, CLOBs get a “textarea”, and booleans get a checkbox. If the column has its own validation of “inList” or “inKeys”, it gets a “select” element of the allowed values. Soon, when I add Ajax-y widgets, date/time/timestamp columns will get date-picker elements.

The $form->load() call can use ‘Solar_Form_Load_Xml’ too, if you want to define forms using XML. (I don’t, but Matthew liked the idea and contributed the code.)

If you only want certain columns, you can pass a list of them as the third param to $form->load():

$cols = array('email', 'subj', 'body');
$form->load('Solar_Form_Load_Table', $table, $cols);

Now, this is not all sweetness and light; the magic requires that you do the work of definining your columns in the Solar_Sql_Table class. Lucky for us, that’s pretty easy. More on that in another post.

Solar 0.17.0 Released

This release of Solar includes a minor BC break in how Solar_Sql_Table lets you set up column validation. It also standardizes how validation routines get feedback messages. The change notes are:

* Solar_Sql_Table

    * When specifying a 'valid' key for a column, you now get only
      one validation; if you need more than one validation routine,
      use the 'multiple' method.  Also, you can now specify the
      validation message key you want to use, instead of it being
      forced to 'VALID_COLNAME' (where COLNAME is the column name).
      You can still use a string as the 'valid' key value for simple
      validations.  These changes per discussion with Jeff Surgeson.

    * Uses more Solar_Valid validations internally now

* Solar_Form_Load_Table

    * Modified loading logic to use the new Solar_Sql_Table::$_col
      'valid' key value structure.

* Solar_Valid

    * New method feedback() standardizes Solar_Sql_Table and Solar_Form
      calls where a validation message is returned when data validation
      fails; this is the opposite of all other Solar_Valid methods, in
      that an empty return value indicated success, not failure.

    * New method range() checks a value against min and max range

    * New method rangeLength() checks the length of a value against
      min and max lengths

    * Renamed method inScope() to scope()

Automating Release Tasks

I noted earlier today that I’ve made 5 releases of Solar in 7 days. (Clearly I’m a fan of “release early, release often.” 😉 Obviously, I have the Solar-talk subscribers to thank for pointing out bugs and and making functionality requests; these are what drive the need for a release … thanks, guys. 🙂

But what I want to talk about in this entry is the release process itself. With the help of Greg Beaver (indirectly) and Clay Loveless (directly), Solar now has a moderate-length PHP script that handles almost all aspects of the release process automatically. Usage is at the command line; issue “php release.php” for a test run, or “php release.php commit” for a full release-and-commit cycle.

With any luck, the lessons I’ve learned here will be of use to someone else; with more luck, perhaps someone else will see possible improvements and mention them here. Read on for a narrative of how the script came to be.

Continue reading

Solar 0.16.1 released

This is a minor bugfix and enhancement release to the Solar library and framework for PHP5. The biggest changes are:

  • Packaging script now properly keeps Solar/App/Public in the main
    library directory (instead of in the data directory) … reported
    by StR.
  • Solar_View_Helper_Form now uses a ‘text’ element when an
    unrecognized element type is requested
  • Solar_Controller_Page::_forward() now sets $this->_view properly (previously, was
    not replacing dashes with slashes)

Let’s see, that’s 5 releases in 7 days; not too shabby. I think it’s time to blog about the release process.

Solar 0.16.0 released

Version 0.16.0 of the simple object library and application repository for PHP5 was released yesterday, mostly because I needed to make a minor schema change to one of the “content” tables. Seems the word “position” is reserved in some databases, and I was using that as a column name; the migration script in this release renames it to “pos”. There are other minor changes to the Solar_Sql class as well (including more documentation :-).

Solar 0.15.2 released

Just a quick note: fixed two bugs (one in the Solar_Controller_Page::_redirect() method, and one in Solar_App_Bookmarks “user” action for RSS feeds) and released 0.15.2, available now.

Solar is a simple object library and application repository for PHP. It acts as a framework for application development in PHP5, and runs cleanly under E_ALL | E_STRICT error reporting levels.

Solar 0.15.0 alpha released

Yesterday, I uploaded the first non-development (!) release of Solar, version 0.15.0 alpha. I know, “alpha” is only slightly less change-prone than “devel”, but it’s a move forward and it makes me happy. 🙂

You can see the change notes here, but the major updates are:

  • Solar_Uri has been refactored to be much easier to use, from 16 methods down to 5, with better “action” and “public” support, and it works with mod_rewrite now. (N.b.: Jeff Surgeson noted an issue earlier today with non-mod_rewrite subdirectories, but I’ve committed a fix and will roll 0.15.1 later today.)
  • Solar_User_Auth now calls session_regenerate_id() on all status changes, and calls to session_start() are no longer silenced.
  • Solar_Filter method names have been made consistent with each other.

Speaking of Solar_Filter, it probably bears comparison with Zend_Filter and Zend_InputFilter, seeing as they were recently reviewed at SitePoint. Solar actually has two separate classes for these functions: Solar_Valid, to check if input matches a particular format, and Solar_Filter, to force input to match a particular format. (Solar_Filter was contributed by Matthew Weier O’Phinney some months ago; thanks, Matthew.)

After Solar 0.15.1 has been out the door a couple more days, I’ll be ready to start *adding* functionality instead of adjusting (and breaking, and re-fixing 😉 existing functionality. High on the list of new functions will be:

  • a Solar_User_Access class for standardized application-level access control,
  • integration of the Dojo Toolkit for animations and effects (especially on forms),
  • and a new Solar_App_Todo application (for to-do lists, obviously).

I’ll be adding more narrative documentation, and perhaps start blogging about usage, as part of future efforts as well.

UPDATE (12:25 CST) — Just released Solar 0.15.1 with the subdirectory/mod_rewrite fix.