Talk In Code

File permissions are important, especially if you want to let a user agent view a file. If the file doesn’t have the correct permissions then it will not be accessed and could cause your script to fail. To get around this you might want to use the following function. It uses the PHP function chmod(), which sets permissions, but it does this recursively from wherever you set it off from.

function chmod_R($path, $filemode) {
 if ( !is_dir($path) ) {
  return chmod($path, $filemode);
 }
 $dh = opendir($path);
 while ( $file = readdir($dh) ) {
  if ( $file != '.' && $file != '..' ) {
   $fullpath = $path.'/'.$file;
   if( !is_dir($fullpath) ) {
    if ( !chmod($fullpath, $filemode) ){
     return false;
    }
   } else {
    if ( !chmod_R($fullpath, $filemode) ) {
     return false;
    }
   }
  }
 }
 
 closedir($dh);
 
 if ( chmod($path, $filemode) ) {
  return true;
 } else {
  return false;
 }
}

This is especially useful for some scripts that create or copy files as these files might be created without the correct permissions. You can call this function by giving it a directory and an octal value for the preferences. Note that the octal value is important. If you want to give the files the permission of 775 then you must use 0775. The following is an example of this function in action, it had been given the current directory that the script resides in to run from.

chmod_R(dirname(__FILE__),0775);

Everything under this directory, including the script file, will be set to 0775, which is standard for most purposes.

Yesterday I talked about using the Flex Script element to run code within the mxml file, you can also use the source attribute of the Script element to reference external files. To create an external script file FlashDevelop go to the File->New and select Blank Document. You can also do this by pressing Ctrl+N. This will create a blank document that you must save into your src folder of your project with the extension as. Note that if you call this file sourcefile.as then you must reference this in your script tag like this.

<mx:Script source="sourcefile.as">

</mx:Script>

When you do this you will notice that the script file will be part of the Main.mxml file. You can add functions in the same way as you would with an inline script tag.

Printing

With this external script file we will now create some images and print them using the built in printing object that Flex has. This object is called FlexPrintJob and you must include this at the top of your script file if you want to use it. Put the following line at the top of your script file.

import mx.printing.FlexPrintJob;

Create a button in your mxml file that will be used to print.

<mx:Button id="print" label="Print" click="printImage();" />

Add in an image that will be printed.

<mx:Image source="one.png" id="one" />

Here is the image that will be used.

Flex test image

Go back into the script file and add the function that will print the image out. We called this function printImage() in our Button declaration. This function works by creating a new FlexPrintJob object called printJob. This function start() is then used to try and print. Basically, this function returns true if the print job worked, and false if the user clicked cancel.

If the start() function returns true then the object to be printed (in this case the image with the id of "one" is added to the printJob object. Finally, the send() function is called which sends the data off to the printer. Here is the function.

public function printImage():void
{
 // Create a FlexPrintJob instance.
 var printJob:FlexPrintJob = new FlexPrintJob();
 
 // Start the print job and check that it worked
 if (printJob.start() != true) {
  return;
 }
 
 // add object to be printed to the print job
 printJob.addObject(one);
 
 // send to printer
 printJob.send();
}

This is the simplest use of the FlexPrintJob function as there are controls that can be used to format the pages.

It is possible to print off multiple objects, especially if they are children to another object, by adding the parent object to the FlexPrintJob object. Take the following section of mxml, which defines a Canvas element, with three positioned images as children.

<mx:Canvas id="images">
 <mx:Image source="one.png" id="one" x="0" y="0" />
 <mx:Image source="two.png" id="two" x="100" y="0" />
 <mx:Image source="three.png" id="three" x="0" y="100" />
</mx:Canvas>

This produces the following application.

Three images in a canvas

To print out all three images at once just include the Canvas object instead of the single image object. Change line 11 in the printImage() function from this:

 printJob.addObject(one);

To this.

 printJob.addObject(images);

The printJob object knows about inheritance and will print out everything contained within that element. This includes buttons or any other element that you put into the canvas element.

See the Flex documentation for more information about the FlexPrintJob object.

Yesterday I wrote two posts about CodeSniffer and a common warning that I couldn’t find any decent documentation on. I thought that today I would go over something that I also had trouble finding out about, this is the file doc error. When you run CodeSniffer on a class you might find the following error being produced.

C:\php5>phpcs MyClass.php
 
FILE: MyClass.php
--------------------------------------------------------------------------------
FOUND 1 ERROR(S) AND 0 WARNING(S) AFFECTING 1 LINE(S)
--------------------------------------------------------------------------------
2 | ERROR | Missing file doc comment
--------------------------------------------------------------------------------


Most developers should be familiar with doc comments. They are used as a standard model for commenting and can also be used to generate API documentation automatically. What the CodeSniffer documentation doesn’t explain is the difference between a file doc comment and a class doc comment. A class doc comment is a comment that precedes a class, it describes not only what the class does, but also gives author, version and license information. Here is a typical (and very simple) class doc comment. The @ symbols are used to generate the API documentation.

<?php
/**
 * MyClass Class Doc Comment
 *
 * @category Class
 * @package  MyPackage
 * @author    A N Other
 * @license  http://www.gnu.org/copyleft/gpl.html GNU General Public License
 * @link     http://www.talkincode.com/
 *
 */
class MyClass{
}
>


A file doc comment is placed at the top of the file, above any include statements and contains pretty much the same information as the class doc comment. When added to your application your document structure might look like this.

<?php
/**
 * MyClass File Doc Comment
 *
 * @category MyClass
 * @package   MyPackage
 * @author    A N Other
 * @license  http://www.gnu.org/copyleft/gpl.html GNU General Public License
 * @link     http://www.talkincode.com/
 *
 */
include('anotherclass.php');
/**
 * MyClass Class Doc Comment
 *
 * @category Class
 * @package  MyClass
 * @author    A N Other
 * @license  http://www.gnu.org/copyleft/gpl.html GNU General Public License
 * @link     http://www.talkincode.com/
 *
 */
class MyClass{
}
>


As long as you make sure that different lines are spaced correctly, and that there is a single blank line between the class comment and the first parameter, you should find that running CodeSniffer will produce no errors. You will also be able to generate some pretty neat documentation which you can bundle with your application.

If you are debugging a PHP application then you might want more information than the values of some current variables. There are a number of built in magic variables that can be used to print out the file name, line number, class and method that the debug statement is printed out on. Here is an example that prints out some information from a class.

class class_test{
 
function method_test(){
  // the full path to the current file
  print 'File: '.__FILE__.'<br />';
 
  // print the current line
  print 'Line: '.__LINE__.'<br />';
 
  // print the current class name
  print 'class: '.__CLASS__.'<br />';
 
  // print the current method name
  print 'method: '.__METHOD__.'<br />';
 
  // directory separator of the current
  // system (windows = \ and linux = /)
  print 'Directory separator: '.DIRECTORY_SEPARATOR.'<br />';
 }
}
$test = new class_test();
$test->method_test();

This will print out something like the following.

File: C:\Apache Software Foundation\Apache2.2\htdocs\test.php
Line: 10
class: class_test
method: class_test::method_test
Directory separator: \

Having a header file that prints out a standard menu on a site is a good idea and saves you time in the long run as you only have to edit one file to change an item on the menu. However, what if you only want to display a menu or sub-menu when a particular page is loaded? This is a common problem, and finding out what page you are on is something that all PHP programmer come across at some point or another.

The PHP $_SERVER superglobal array has three items of interest which can be used to find out the current page. These are PHP_SELF,REQUEST_URI and SCRIPT_NAME and they all appear to have the same values but there are some subtle and important differences. Here are some examples of their values (on the right) with the original URL (on the left).

PHP_SELF
test.php = test.php
/example/ = /example/index.php
/example/test.php = /example/test.php
/example/test.php?id=123 = /example/test.php
/example/test.php/test/123 = /example/test.php/test/123

REQUEST_URI
test.php = test.php
/example/ = /example/
/example/test.php = /example/test.php
/example/test.php?id=123 = /example/test.php?id=123
/example/test.php/test/123 = /example/test.php/test/123

SCRIPT_NAME
test.php = test.php
/example/ = /example/index.php
/example/test.php = /example/test.php
/example/test.php?id=123 = /example/test.php
/example/test.php/test/123 = /example/test.php

So from these tests we can say that SCRIPT_NAME is probably our best bet for getting the filename that is running the code we are looking at. We can get that output like this.

$currentFile = $_SERVER["SCRIPT_NAME"];

Next, you will need to extract the parts of the path into an array and pick out the last item. This will be the filename.

$currentFile = $_SERVER["SCRIPT_NAME"];
$parts = explode('/', $currentFile);
$filename = $parts[count($parts) - 1];

I have seem some variations on this theme, but using SCRIPT_NAME seems to be the most reliable method. One thing to watch out for is that one some server setups you might find that SCRIPT_NAME simply doesn’t exist. In this case I would use PHP_SELF as this is implemented by the language and will always be present.

To find the current directory you only need to look at the rest of the array. So if the file we are looking at has the following URL.

http://www.talkincode.com/example/test/123/test.php

Then our array contained in the $parts variable will contain the following.

[0] =>
[1] => example
[2] => test
[3] => 123
[4] => test.php

The first item is always blank because the SCRIPT_NAME variable always starts with a slash. So when we use the explode() function on it a blank item is created. This can easily be deleted by using the following:

unset($parts[0]);