Smoking toooooo much PHP

I had to laugh the otherday reading one of the Microsurf's blogs about how they suddenly had to deal with customer comments, and suprisingly enough, not many where positive. I think the guy was from the .Net team, and I considered he probably get's it easy, at least he's not on the IE team..

I gave up microcrap years ago, and only now use it for interoperability testing, where most of the time it fails, (XP included..) but I was supprised this week, when working with a new team here, when someone asked me why he should use linux rather than microsoft.

Youth and alot of Microsoft giveaways had ended up with the impression that this stuff fulfilled every need and desire. I have to admit I was a little shocked, I rarely find people who actually like what microsoft attempts to deliver. Most are resigned to the fact that it's a pile of crap but they are either to lazy to learn something new or, blindly believe that the next version will be better.

I started explaining the concept, that as a developer you have the ability to actually fix things with linux. Where he seemed to think that microsoft actually fixed things, especially as his old company had some developer/partner package.. But digging deeper it was pretty clear that solving problems just meant news about workarounds comes faster.. Actually fixing stuff still required something close to a miracle. (CSS fixes for IE came to mind)

But what really would have been a killer example was reading about Webdav support on XP, basically it's completely broken (there are even Knowledgebase articles saying so from 2003). Yet again re-inforcing my view of Microsoft as a company that may fix bugs in each release, but breaks just as many new things with each effort. So however many blogs you see coming out of microsurfs, the knowledge that they will completely ignore their customers (which thankfully I managed to remain from being), means that they still have a long while before anyone actually expects their software to work.

*UPDATE* the source is now in cvs.php.net/pecl/svn

That itch just got to much today, and I started on libsvn bindings for PHP. With a few hints from the subversion mailing list, I now have 3 commands working

<?php
dl('svn.so');
svn_checkout("http://www.akbkhome.com/svn/ext_svn","/tmp/ext_svn");
print_r(svn_cat("http://www.akbkhome.com/svn/ext_svn/svn.c"));
print_r(svn_ls("http://www.akbkhome.com/svn/ext_svn/"));
?>

It's a long way from being completed, but, it's quite nice to see how easy it was to get this far..
This one's php4 friendly, so you can try it out by downloading from the subversion server @ http://www.akbkhome.com/svn/ext_svn/

DBDO has finally made it to a state where it can be released. After testing on this site's PHP5 version, I finally nailed the last few segfaults.

The DBDO page on pecl.php.net lists the the differences between it and DB_DataObjects, and you can get an idea of the API by looking at the source for this websites PHP5 version or the documentation on DataObjects. The main things that still need looking at are

• Join support
• experimenting with PDO integration

It would be nice to hear from anyone that get's past the fun of compiling libgda (from CVS), and get it to work.

I sometimes wonder if engineers have a secret obsession with configuration options. I've been working on a few projects in the last few weeks that have made me wonder if the developers consider configuration options an excuse to be lazy, and let someone else sort out their mess.

Other than developing software, I also install my software, and other peoples, onto clients computers. At one point a few years ago, I was asked to provide instructions to install the software so they had a backup plan if I was un-available. Simple I thought, I write great software that's easy to install and set up. So off I went and wrote a realitively simple installation document.

Amazingly enough, the unfortunate guy the other end had great difficulty getting the application up and going. Some of the more classic problems where

• The application needed write access to various folders on the machine, and those folder locations where configurable.
• The application needed to use a number of system commands, and the path to the command needed setting up.
• The application was going to be installed in a different path to the development box, with a different hostname etc.

I've also seen applications have configuration options for

• name of the help url.
• width of output (in a wrapped pre formated text area)
• specific folder locations for specific purposes.
  

One of the primary failings to all of these options, was the fact that almost all of them are either not required, or should have been defaulted by the application.

• Write access, can normally be dealt with by writing to the ini_get('session.save_path') by default, if the user wants to change the path, they can actually set the option or change the php.ini or .htaccess and modify the save_path
  You can also create your own application specific subdirectory under that temporary directory. PEAR's System::mkdir(array('-p',$mytmpdir)); works very well there.
  
• System::which() provides a cross platform version of the unix which command. - this can be used to default paths for applications (hence no requirement for these type of options)
  
• for paths and urls, PHP provides plenty of information about where your application is, and how to access it, forcing a user to configure them is almost always unnessecary.
• Templates are really the place to modify url's or fixed paths or widths, Flexy's ability to be told about template folders to use, enables you to override (eg. copy and modify) specific templates that you need to change for your site.
• Some options are just plain pointless, for the 2 in 2 million users who want them, there is usually a better way that adding an option (class inheritance comes to mind - extend my class and add it to your wrapper...)
• And sometimes you just have to put your foot down, the help files are always going to be in [root]/help.. there's no choice in it, and dont waste our time making it configurable..

Solving this issue has involved the refactoring of my FlexyFramework many times, the history of how and where do configuration went something like this:

• a ConfigData folder in the application root, stored one config file for each domain the app was installed on.
• These contained a huge number of options, for all the packages that the applicaiton used.
  
• As time has evolved, I've removed the requirement for alot of the core options, and used defaults that work 99% of the time.
• About a year ago, It struck me the autoloading of these Files was actually the cause of some setup bugs and time wasting, so I moved almost all the remaining options to the index.php line that starts the Framework, and pulled in a single option from a machine wide ini file. (basically moving any optional stuff into the bootstrap file.)
• So at the end of the day, we have one global .ini file for each server, which basically lists all the database dsn's for the various applications. (for simpler servers, the index.php file explicitly loads an ini file from somewhere, which generally only contains the database dsn.)

So finally I can say in the documentation

• download, unzip
• create the database using the .sql file (or similar)
• Then depending on the complexity of the project
• alter the index.php, add the database dsn.
• alter the xxx ini file, and change the database dsn.

And hey presto it works...!, well sometimes..

DBDO's slow migration from vapourware to bugware has been progressing this week. A month ago, I started useability testing on the PHP5 version of this site, and it helped find alot more issues than the unit tests that I had set up.

A few weeks ago though, I was working on another application that uses a threaded version of PHP embed, and DBDO, which was throwing up quite a few bugs around setting / fetching data using the overloaded internal setters and getters.

The original design of DBDO, was that when you fetch a value (eg.)
echo $do->name;
that the object would internally get the value from libgda at this point, rather than the way DB_DataObject currently does, by assigning all the PHP variables when you call $do->fetch().

The trouble was that this way of working began to get very confusing when mixed with all the potential ways that you may access the data.

• Setting the column value (at this point you have to store a seperate hash for assigned values)
• print_r and it's like need you to actually set values for all the properties.

I ended up with something like 3 hashes doing various tasks, and each needing memory managing. And as usual, complexity leads to numerous bugs.. So I made the decision last week to follow DataObjects logic of simply setting the properties on fetch().

This removed a large chunk of code, and in general simpified the whole query building process. Things like the update code could easily compare the fetched data against the current object properties and update only the changed data. The only thing that caught me out was that unless you add a zend_objects_store_add_ref() after changing the properties internally, the values get free'd too early and segfaults occur.

Anyway, the current plan is to get back to testing the code on the PHP5 version of this site next week, then actually make an alpha release...

Whenever someone starts saying template engines, there's an equally vocal community that gently suggests that PHP is a great template engine. Well, I think this week that sounded alot like bollocks...

The pear website, while not a masterpiece for PHP code, has however been written by some pretty smart people, and uses (in parts) the concept of PHP as a template engine. Last week however we got a very polite email to the group mentioning that it was possible to do Cross site scripting attacks on some pages.

The root of the issue was that it was outputing variables (either directly from input or indirectly) which had not been escaped correctly for HTML or javascript, so it was possible to make your favourite javascript hacks work through the url..

While the issues with pearweb where not that serious, it did illustrate the problem of simple PHP templating against more complex engines like Flexy.

When I wrote Flexy, I'd been doing webdev for quite a while, and realized that like everyone else, I make mistakes (some may say like my opinions on this blog). So to some degree, I tend to prefer my applications to protect me from myself, while at the same time allow me to deliberatly break things.

One of the more unusual features of Flexy, is that all tags eg. {stuffThatOutputsVariables} or the method calls are by default html escaped. (unless you explicitly add the :h modifier). Not only this, these tags within javascript blocks, just dont work. You are forced to use the <flexy:tojavascript tags to send variables to the javascript code, again, reducing the chances of accidentally letting your friendly hacker have fun with your site..

So while PHP templates have some advantages, in that it lacks the requirement for compiling. That penalty seems a small price to pay for the extra protection.. so Flexy's new catchphrase may be, "Put your condom on, and use a Flexy Template Engine..."