Eirik Hoem’s Blog

When doing complex applications it’s often nice to have some sort of system for handling settings. PHP has a nice function called parse_ini_file which can be used to create a basic but still usable setting file feature. A simple class which loads the configuration file and offers some methods to retrieve the values for a given key is all that’s needed. The example I’m providing is pretty basic, but it’s still very usable and can be added to almost any application.

First, we need to create a file to hold the settings. It’s ordinary plaintext and follows the INI format.

Here is a quick sample of some key / value pairs:

[general]
locale = no_NO
company.name = MyCompany

datasource.host = localhost
datasource.database = mydb
datasource.username = user
datasource.password = 1234

The class for accessing the file:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

class MyConfigClass{
  protected $config;
 
    public function __construct()
    {
      $this->config = parse_ini_file('../conf/myapp.ini');
 
    }
 
    public function getConfig($key = null)
    {
      if($key !== null)
      {
        if(isset($this->config[$key]))
        {
          return $this->config[$key];
        }
        else
        {
          throw new Exception("Unknown key '$key' in configuration");
        }
      }
      else
      {
        return $this->config;
      }
    }
 
    public function setConfig($config)
    {
 
      $this->config = $config;
    }
}
 
?>

Usage:

1
2
3

$configManager = new MyConfigClass();
 
$value = $configManager->getConfig['datasource.host'];

Now, when working on larger application one usually have a application like class, and that’s a nice place to put this code. When using Prado I usually place the config code in the TApplication class.

Technorati Tags: PHP

I’ve been struggling with lava support for Firefox after upgrading from Ubunut 7.10 to 8.04. All I had to do was to remove the package called icedtea-gcjwebplugin. Now, I don’t know my way around lava anymore, but at least it did the trick. Worth a shot if you have problems.

Update:

John has some more information on this issue if the above didnt do the trick:

I also needed to link to the new plugin….

cd /usr/lib/firefox-3.0/plugins$
sudo ln -s /usr/lib/jvm/java-6-sun/jre/plugin/i386/ns7/libjavaplugin_oji.so

Thanks John!

Technorati Tags: Java, Firefox

A coworker of mine has been working on a ajax enabled regex tool which lets you evaluate regex expressions in several languages (including PHP PCRE and PHP POSIX) with instant results. You can choose which functions to use, such as match, match all, replace, split etc. It also offers some basic help and hints. It’s really handy when working on those painful expressions.

You can check it out at http://regex.larsolavtorvik.com/. Stop by his blog as well.

Technorati Tags: PHP, Perl, JavaScript, Python

Ever wanted to generated PDF documents on the fly with PHP? Perhaps populate a standard contract with a customers name and address? FPDF and FPDI are two neat libraries which greatly helps when working with PDF files. FPDF is the main library for handling PDF files, while FPDI lets your import existing PDF documents into the FPDF documents. In the code sample I’ve prepared here I’m importing a PDF template document, writing some information to the document, then sending it to the “customer”. FPDF offers several neat ways to expose the generated document, such as a stream to the browser, a string, or just storing it to file. You can download PDF Sample code to test it.

Be sure to head on over to the FPDF site and FPDI site for more information on these two libs.

Related posts:
Generated PDFs over HTTPS with Internet Explorer

Technorati Tags: PHP, PDF, Frameworks

I just came across this post by Mike Henke, where he writes about a presentation from the Google Automating Testing Conference. Google is working on a framework based on Selenium which they use internally. The post contains some interesting slides in addition to a presentation video. I’ve embedded the video in this post for your convenience, but I suggest you give Mike a visit.

Update: Video removed, please check the links above.

Technorati Tags: PHP, Testing, Frameworks

This post is pretty much a revamp of a previous post called “Working with X-Fire soap services and inheritance in PHP“. That title was a bit misleading, and not really that good when it came to providing a sample.

Let’s say we have a SOAP method called createCustomer(Customer c), and we have a base class called Customer, which has to subclasses, Person and Organization. Person has firstname, lastname, while Organization as orgname and orgid. Now, the createCustomer call accepts a object of the class Customer, and any derived classes.

When retrieving a Person / Organization over SOAP, PHP automatically creates instances of the correct classes, but when calling createCustomer, passing a Person / Organization it breaks. Out object is sent as a Customer, but with Person or Organization fields added. The SOAP server expects to find a xsi:type for the object we are sending to tell what kind of Customer it is. It seems like PHP does not set this itself (maybe it should?).

I spent quite some time looking for info on how to specify the xsi:type for the objects, and I finally came across SoapVar.

I created a base class which the SOAP classes extended. A method called pack is responsible for setting xsi:type.

(I’m very aware that my pasted code looks like a mess in this blog. I will fix that ASAP).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

 
class BaseClass{
  private  $namespace = "http://model.api.domain.com"; // from your WSDL
  protected function pack($obj){
    $class_name = get_class($obj);
    $namespace = "http://model.api.domain.com";
    $pack = new SoapVar($obj, XSD_STRING, "$class_name", $namespace);
    return $pack;
  }
}
 
class createCustomer extends BaseClass{
  public function setCustomer($customer){
    $this->customer = $this->pack($customer);
  }
}
 
$customer = new Person();
$customer->setName("John Doe");
 
$request = new createCustomer();
$request->setAccountID(123);
$request->setCustomer($customer);
 
$client->createCustomer($request);

That fixed the problems for me atleast.

PS: If your SOAP classes are prefixed you’ll need to strip the prefix in class_name when creating the SoapVar.

Related posts:

• Working with X-Fire soap services and inheritance in PHP
• Array problems with SOAP and PHP - Updated

Technorati Tags: PHP, SOAP

Update:

I guess I didn’t make the purpose quite clear here. This method will allow you to show custom error messages when PHP hits a fatal error. The shutdown function will always run.

Scripts tend to die, and that’s not usually nice. We do not want to show the user a fatal error nor a blank page (display errors off) . PHP has a function called register_shutdown_function which lets us set up a function which is called at execution shutdown. What this means is that our function will be executed when our script is done executing / dying and PHP execution is about to shut down. By setting up a variable to false at the start of our script, and setting it to true at the very end of the script we can have our shutdown function check if the script completed successfully or not. If our variable is still false we know that we never made it to the last line of our script, hence it died somewhere. I’ve prepared a very basic sample which shows how you can give the user some proper feedback if a fatal error should arise. You’d want to turn of display of fatal errors for this to look nice.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

$clean = false;
function shutdown_func(){
  global $clean;
  if (!$clean){
    die("not a clean shutdown");
  }
}
 
register_shutdown_function('shutdown_func');
 
$a = 1;
$a = new FooClass(); // will fail with fatal
 
$clean = true;
?>

As you can see, the shutdown_func prints something if the clean variable isn’t set to true when the shutdown function runs. This should of course be wrapped in a class (and NOT use globals), and for something more usable I recommend checking EZ Components way of doing this.

This is a follow up to my post about array problems with SOAP and PHP. The scenario was that when an array with only one object was returned over SOAP the array was discarded and pointed straight to the single object.

Cmm was kind enough to tip me this PHP bug report, which explains that this is actually not a bug, but a feature.

To get arrays containing one single element, simply create the SoapClient as follows:

1

$x = new SoapClient($wsdl, array('features' => SOAP_SINGLE_ELEMENT_ARRAYS));

Related articles:

• Array problems with X-Fire, SOAP and PHP

I recently went to a presentation where some guys from CodeGear showcased Delphi for PHP and VCL4PHP. It’s a new product which enables PHP developers to use drag / drop and wysiwyg methods to build applications with PHP. The IDE uses VCL4PHP as the underlying framework.

This kind of tool is something that ASP.net has had for a long time (ie Visual Studio.net). Not only does it make the development process easier when it comes to building applications, but it also handles setup of applications, default configs etc. Until now there hasn’t been any tools for doing this with PHP, so I sincerely congratulate CodeGear on getting something out to the masses. Their IDE is a really nice tool with lots of potential. It ships with apache, and has lots of nice features like a integrated debugger etc. The immediate draw-back is that it runs on Windows only. My impression is that most PHP developers (atleast above hobby level) works on Linux based workstations, so I imagine getting a strong user base could prove to be difficult.

Now, why do I think that Prado is far superior to VCL, and why would it have been a better choice:

1.Exception handling
Any framework which are viable for larger scale application development should use exceptions. It’s an established way of controlling code flow and making sure the code can recover from error.

VCL: This is the first MAJOR flaw which would possibly be the hardest to fix. I’ve spent some time looking around in the VCL code, and there is some basic exception handling here and there. The problem is that most of the controls does not have any exception handling at all. This makes it very hard and tedious to control the follow when errors occur.

Prado: Usage of exceptions throughout the whole framework, with the possibility to have custom exception handlers lays the foundation implementing proper flows in the application and user friendly feedback when errors occur.

2. Usage with other PHP frameworks
A framework needs to play nice with other framework these days. There is no framework that has everything, so the coder will most likely use any given framework in addition to something else.

VCL: None of the controls I’ve seen while checking out the VCL source code are prefixed. Having controls with class names like ListView, PageControl, TreeNode etc won’t play nice with other frameworks. Also, using class names like Object and Component isn’t something you’d want to have in a framework.

Prado: All components in Prado are prefixed with a ‘T’ like TLabel, TPage, TListView ensures cooperation with other frameworks.

3. Generation of HTML code from controls
VCL: The controls implement a method called dumpContents which basically writes HTML and JavaScript tags and attributes by using echo. Some sub classing is done where the parent renders as well.

The following snip is taken from their CustomLabel code:
552 if (trim($this->LinkTarget)!=”") $target=”target=\”$this->LinkTarget\”";
553
554 $class = ($this->Style != “”) ? “class=\”$this->StyleClass\”" : “”;
555
556 echo “<div id=\”$this->_name\” $style $alignment $hint $class”;
557
558 if ($this->_link==”") echo “$events”;
559
560 echo “>”;
561
562 if ($this->_link != “”) echo “<A href=\”$this->_link\” $target

By letting most of the controls be responsible for writing the low-level HTML code it’s much harder to keep the code XHTML valid, and does not exactly scream re-use. See next point for how Prado handles this.

Prado: Controls that render contents in Prado extends TWebControl. I’d like to quote the Prado manual for TWebControl here:
“TWebControl is the base class for controls that share a common set of UI-related properties and methods. TWebControl-derived controls are usually associated with HTML tags. They thus have tag name, attributes and body contents. You can override getTagName to specify the tag name, addAttributesToRender to specify the attributes to be rendered, and renderContents to customize the body content rendering. TWebControl encapsulates a set of properties related with CSS style fields, such as BackColor, BorderWidth, etc.

Subclasses of TWebControl typically needs to override addAttributesToRender and renderContents. The former is used to render the attributes of the HTML tag associated with the control, while the latter is to render the body contents enclosed within the HTML tag.”

4. XHTML code generation
Producing valid XHTML is something we should all strive to do. Not doing so may result in display problems in most browsers.

VCL: I tried to validate a basic demo site created with Delphi for PHP and VCL4PHP. The results speaks for them selves. The generated HTML code is not XHTML compliant. Example from the CustomLabel code again - echo “<A href=\”$this->_link\” $target. Remember that XHTML tags are always lowecase. There are several other problems as well, and the validation link shows some of them.

Prado: The HTML code that Prado generates is mainly done in the parent controls, so keeping the base implementations XHTML valid mostly ensures that the child controls will be as well. This also removes the actual rendering code from the controls, so creating new controls is far easier and cleaner.

5. Validation controls
Input validation is some of the most boring tasks when writing web applications, and it can be fairly difficult to get it right.

VCL: According to the guy from the presentation there is none, but I found a screen cast here. It seems way more tedious than the Prado way, and I can’t tell if it’s released or just in trunk / testing at the moment.

Prado: Prado ship with several validation controls which works both client side and server side. TRequiredFieldValidator, TRegularExpressionValidator and TEmailAddressValidator ensure that the coder can feel very safe when it comes to validating input. TCustomValidator lets the user create custom validation logic to perform tasks (for example login checks). A complete list and usage examples can be found here.

6. Encapsulation
Encapsulation is a way to make sure that the internal state of classes isn’t messed with by code that should not be able to.

VCL: I’ve been looking trough the code trying to find controls that actually use private methods for managing their internals. As far as I can see there is only a fraction of the controls which uses private methods, and when they do it’s only for one or two methods. This is a design no-no when everyone can call everything.

Prado: Only methods which have to be public are public. This ensures proper encapsulation and prevents the coder from accidentally messing up the state of a control.

7. Component properties

VCL: Delphi for PHP stores all component properties in XML files. I see the point of doing this for the sake of the IDE, but when it comes to runtime code I do not. During the demo they showcased how to use smarty templates with VCL, and to add a control which was created in the RAD gui they use markup ala {button1}.

Prado: Prado separates the code and login into two files (.php which holds the page class, and .page which holds the markup). The properties for the components are kept in the .page files which is a much easier way to look at the controls when creating markup. Check this link for a quick intro to how Prado handles this.

8. Usage of globals
VCL: Using globals? We all know this is bad and belongs pretty much belongs in PHP4 applications. If you need a dirty hack it can be a last resort kind of thing, but using it throughout the whole framework?

Example of globals usage:
30 $exceptions_enabled=true;
31
32 global $use_html_entity_decode;
33
34 $use_html_entity_decode=true;
35
36 global $output_enabled;
37
38 $output_enabled=true;
39
40 global $checkduplicatenames;
41
42 $checkduplicatenames=true;

183
184 /**
185 * Global $application variable
186 */
187 $application=new Application(null);
188 $application->Name=”vclapp”;
189

These things should be config related and stored in either the application object or a core base class.

I also checked out the blog demo from this page, and usage of globals can be found throughout the applications (global $BlogDB, global $AdminDeleteComment etc).

Prado:
Prado uses globals in one single file, and that’s the file responsible for generating client side scripts. Settings which span the whole application can usually be accessed from the application object.

9. Ajax

I’m considering to do another post comparing the ajax features in depth, but I just wanted to point out one thing seen in this screencast on AJAX. The coder escapes from PHP to write the javascript, then jumps back into PHP. In Prado things like these follow the same design as the rest of the framework.

Conclusion

I want to do some more in depth comparisons of controls and ajax support later on, but my current impression of VCL4PHP is that it’s “out of date” or not quite on a professional level. Not taking advantage of PHP5 features like interfaces and encapsulation, lacking proper exception handling, key features like validation and not generating valid XHTML code are all major points which I would expect a proper framework to have in place. One has to wonder why CodeGear went in this direction.

If you consider using VCL / Delphi for PHP I recommend that you first stop by the VCL4PHP forums to get some impressions on how people are using it and see their experiences.

I would really like to come in contact with someone that knows VCL4PHP so that a in depth comparison of the different controls can be done.

When working against complex soap servers from PHP it’s generally a nice thing to be able to act on exceptions and not just provide the error message. I’ve been working against X-Fire web services for the last few months, and every time an exception is thrown it’s returned as a SoapFault with the actual exception name as property in the detail field. I wanted proper exceptions which I could do something useful with, so I poked around and came up with something which fixes this. The basic idea is to catch the soap fault exception, parse it for information and build a new exception based on the name which is retrieved. The code is a bit gritty since the actual name of the exception is a field, but that’s nothing that reflection can’t solve. The doRequest method is the method used to call the web service methods. This is a part of my soap client class.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63

/**
* Do the soap request
*
*/
protected function doRequest($name, $args = array()) {
  try {
    $response = $this->__soapCall($name, $args, $this->options);
    return $response;
  }
  catch(Exception $e) {
    $newEx = $this->buildException($e);
    throw $newEx;
  }
}
 
 
/**
* parses a soap fault and returns the error code and message
* used by buildException
*
* @param SoapFault $e
* @return array
*/
protected function parseSoapFault(SoapFault $e) {
  $pos = strpos($e->faultstring, ':');
  $code = "";
  if($pos) {
    $code = substr($e->faultstring, 0, $pos);
    $message = trim(substr($e->faultstring, $pos+1, strlen($e->faultstring)));
  } else {
    $message = $e->faultstring;
  }
  return array($code, $message);
}
 
 
/**
* This method takes a SoapFault and builds a proper exception from it
*
* The SoapFault can hold a server side exception name in it's detail field. This
* method takes a peek to see if that field exists, and if it does the name of the
* field is extracted via reflection. A new exception is created of the class that
* was just retrieved and the message and code is set.
*
* The message and error code is extracted from the soap fault.
* @param unknown_type $e
* @return unknown
*/
protected function buildException($e){
  list($code, $message) = $this->parseSoapFault($e);
  if (!isset($e->detail)){ // No exception found
    $ex = new GenericException($message,$code);
    return $ex;
  }
 
  // get the actual name of the exception
  $reflectionObject = new ReflectionObject($e->detail);
  $properties = $reflectionObject->getProperties();
  $exceptionName = $properties[0]->name;
 
  $exception = new $exceptionName($message,$code);
  return $exception;
}