If you can, you may want to set post_max_size to a low value (say “1M”) to make testing easier.

First test to see how your script behaves. Try uploading a file that is larger than post_max_size. If you do you will get a message like this in your error log:

[09-Jun-2010 19:28:01] PHP Warning:  POST Content-Length of 30980857 bytes exceeds the limit of 2097152 bytes in Unknown on line 0

If you’re not careful this can lead to unexpected behavior in your application. The end result can range from silent failure all the way to lost customers.

Solving the problem

The PHP documentation provides a hack to solve this problem:

If the size of post data is greater than post_max_size, the $_POST and $_FILES superglobals are empty. This can be tracked in various ways, e.g. by passing the $_GET variable to the script processing the data, i.e. <form action=”edit.php?processed=1″>, and then checking if $_GET['processed'] is set.
Source: PHP manual

To be clear, it is suggesting that you pass a value in the query string along with your form. If the value is in the $_GET superglobal and both $_FILE and $_POST are empty then the maximum upload size is exceeded. There are two problems with this approach: it adds extra complexity on the front-end and it can potential give a false positive.

Extra complexity on the front-end means extra documentation and more room for mistakes. And if there is a mistake it may not be caught for a long time (does your QA team routinely upload large files?). In this case we already have all the data that we need to determine if the maximum file size was exceeded without adding extra complexity and headache for developers.

We know what type of request is being processed, we have the $_POST and $_FILES arrays, and we have the content length as it was passed to the HTTP server from the client. From that we get this code:

if ( $_SERVER['REQUEST_METHOD'] == 'POST' && empty($_POST) &&
     empty($_FILES) && $_SERVER['CONTENT_LENGTH'] > 0 )
{
  $displayMaxSize = ini_get('post_max_size');

  switch ( substr($displayMaxSize,-1) )
  {
    case 'G':
      $displayMaxSize = $displayMaxSize * 1024;
    case 'M':
      $displayMaxSize = $displayMaxSize * 1024;
    case 'K':
       $displayMaxSize = $displayMaxSize * 1024;
  }

  $error = 'Posted data is too large. '.
           $_SERVER[CONTENT_LENGTH].
           ' bytes exceeds the maximum size of '.
           $displayMaxSize.' bytes.";
}

The important thing to notice is the “if” statement on lines one and two. The example code just sets an error string. Production code might display a message to the user, execute some Javascript (for asynchronous uploads), or pass back a XML or Json object for Flash clients.

I’ve tested this code with Apache as both a module and as CGI. As far as I know it should work fine with IIS as well.

Situation #1: A variable named “new” in a dynamic class

You are creating a dynamic object and you need to use a reserved word as a member variable name but you can’t.

var x:Object = new Object;
x.new = "this doesn't work";
x['new'] = "this works";

The first method is a nice way to get 1084: Syntax error: expecting identifier before new when you try to compile. Remove that line and use just the second one and you are all set. It is OK to mix and match access methods, as long as you never use dot notation for reserved words.

Situation #2: A RPC method named delete

You are making a remote call via the RemoteObject class (such as I was doing with Drupal) and you need to call a method named “delete” (or “new” for that matter). You naturally try this:

var ro:RemoteObject = new RemoteObject;
ro.endpoint = "http://www.example.com/amfphp";
ro.delete( 1234 );

You will be promptly greeted by the now familiar 1084 error when you try to compile and using a different notation won’t work. I’ll break the solution into multiple parts although it could just as easily be chained together:

var op:AbstractOperation = ro.getOperation('delete');
op.send( 12345 );

Incidentally the result of the “send” method is a AsyncToken object (the same object that “ro.delete()” would return if delete were not reserved) which can then be used to add responders.

There you have it. Two quick and easy ways to get around methods and properties with reserved words for names.

Flex form with drop shadow header

It seems easy enough so let’s give this a try:

<mx:Style>
HBox {
  paddingTop: 5;
  paddingBottom: 5;
  paddingLeft: 5;
  paddingRight: 5;
  dropShadowEnabled: true;
}
</mx:Style>

Usually the dropShadowEnabled: true would be enough but in this case you may be surprised if you put the above style into an MXML file with an HBox in it. Drop shadows don’t work on HBox components without some more tweaking. They don’t work for VBox, FormItem, Canvas, Grid, and Tile either. But dropShadowEnabled works beautifully to create Flex drop shadows on a component like TextInput.

What sets TextInput apart? It has a border by default. That is the key. Put borderStyle: solid in our style sheet then all the sudden our HBox has a drop shadow. Unfortunately it also has a nice one pixel border as well. To fix that we can set the borderThickness to zero and you’re done.

<mx:Style>
HBox {
  paddingTop: 5;
  paddingBottom: 5;
  paddingLeft: 5;
  paddingRight: 5;
  dropShadowEnabled: true;
  borderThickness: 0;
  borderStyle: solid;
}
</mx:Style>

Quick Two Point Summary

• Drop shadows will be hidden if the component doesn’t have a border.
• The border can be zero pixels.