With CSS, one can use the float property to make text flow to the left or to the right of an element rather than have the element occupy the entire row.

But what I hadn’t realised until today was that the align attribute (that’s the plain old HTML attribute, not a CSS property) of the table element can be used to the same effect. Setting the attribute to “left” or “right” will float the table to the left or right respectively. So, for example, three left-aligned tables will follow each other on the same line rather than being rendered vertically one below the other:

<table align="left" border="1">
<tr><td>foo</td><td>bar</td></tr>
<tr><td>foo</td><td>bar</td></tr>
</table>
<table align="left" border="1">
<tr><td>foo</td><td>bar</td></tr>
<tr><td>foo</td><td>bar</td></tr>
</table>
<table align="left" border="1">
<tr><td>foo</td><td>bar</td></tr>
<tr><td>foo</td><td>bar</td></tr>
</table>

And the clear attribute of the br tag can be used to do the same thing as the clear CSS property would: force the following text to start below, undoing the effect of floating:

<br clear="all">

It’s a feature of HTML which has little purpose these days, what with CSS being the preferred way to change the presentation of page elements, but it’s nice to know about nonetheless.

It can’t really be disagreed on that something like example.com/index.php?page=article&id=409 is not nearly as nice as example.com/article/409.

Turns out this isn’t all that hard with PHP - infact it can turn into something that’s very useful from more than just a readability viewpoint.

The Plan

What we’re going to do is capture everything past a particular point in our URL and pipe it to PHP, we’re going to let PHP do most of the the legwork.

• Using mod_rewrite we get everything past a particular point.
• We will then pass that into a PHP get variable. We’ll use “p”, you can use anything.
• In our PHP we will define “rules” for our URLs with very simple regular expressions.
• When something matches, we’ll get the appropriate page - otherwise we’ll give back a 404.

(more…)

The problem is the way IE6 treats the z-index css property.

According to the W3C spec, the order in which page elements are drawn
is determined by their position within their surrounding stacking
context. The page itself is the outermost stacking context, and by
default page elements are positioned in the order in which they appear
in the document. Their z-index is effectively zero:

html
  |- head           (0) }
  '- body           (0) }
       |- div1      (0) } stacking
       |    |- div2 (0) } context
       |    '- div3 (0) }
       '- div4      (0) }

When the z-index css property is applied to an element, this
does 2 things. Firstly it specifies where that element should be
positioned within its surrounding stacking context. A lower index puts
the element behind the others, and a higher one ensures that the
element will be drawn infront of the others. The z-index property also
creates a new stacking context in which its index is zero. The order
in which this element’s children are drawn will be determined by this
new stacking context:

html
  |- head                          (0) }
  '- body                          (0) }
       |- div1 [z-index: 2]  (0) } (2) }
       |    |- div2          (0) }     }
       |    '- div3          (0) }     }
       '- div4                     (0) }

Thus if our div3 is given a z-index of -1:

html
  |- head                                (0) }
  '- body                                (0) }
       |- div1 [z-index: 2]       (0)  } (2) }
       |    |- div2               (0)  }     }
       |    '- div3 [z-index: -1] (-1) }     }
       '- div4                           (0) }

Then the rendering order would be:

html
head
body
div4
div3
div1
div2

The problem with IE6 is that when an element is given the css property
position: relative, it establishes a new stacking context even
if no z-index property has been set with it.

This is extremely annoying because it means that the children of a
relatively positioned element can never be told to render below its
previous siblings or above its subsequent siblings. You’re kind of
“boxed in” to a range of z depths. The workaround? I guess to avoid
using relative positioning, if possible.

public abstract class Handler
{
	public void handleInput(Input input)
	{
		// do nothing - just catch all Inputs not handled by subclass
	}
}

public abstract class Input
{}

public class AlphaInput extends Input
{}

public class BetaInput extends Input
{}

public class GammaInput extends Input
{}

public class MyHandler extends Handler
{
	public void handleInput(AlphaInput alpha)
	{
		//handle one kind of input here
	}

	public void handleInput(BetaInput beta)
	{
		//handle another kind of input here
	}
}

public class Main
{
	public static void main(String[] args)
	{
		Handler handler = new MyHandler();

		//handle an AlphaInput
		Input input = new AlphaInput();
		handler.handleInput(input);

		//handle a BetaInput
		input = new BetaInput();
		handler.handleInput(input);

		//handle a GammaInput - it can handle any subclass of Input because of the
		//catch-all method in the Handler superclass.
		input = new GammaInput();
		handler.handleInput(input);
	}
}

THIS WILL NOT WORK. What will happen here is that all three inputs will be handled the same way. They will all be swallowed up by the catch-all in the Handler class, which accepts the Input type.

“Why not?”, you might ask. It turns out that Java, and likewise C++, are what are known as single-dispatch languages. A class method can be thought of as a function where the first parameter is the object which owns the method. For example, when we make the method call handler.handleInput(input), this can be thought of as the function

handleInput(handler, input);

Java, as a single dispatch language, will examine at runtime the actual type of object that the first of these parameters is refering to (in this case, MyHandler), but will not do the same for subsequent parameters - it will use the type we referred to them by (in this case Input). Thus when finding the appropriate function to use, Java comes up with:

handleInput(MyHandler handler, Input input);

Java calls the method of MyHandler which accepts an Input - i.e. the one inheritted from Handler which does nothing. Other languages, such as Common Lisp, are known as multiple-dispatch languages because all the parameters’ types are investigated at runtime.

Design patterns such as the Visitor pattern were invented to work around the limitation of single-dispatch in languages like Java. Patterns such as this basically boil down to the object being passed in as the parameter identifying its own type to the receiving object.

For example, the handler example could be improved by altering the code to look like this:

public abstract class Handler
{
	public abstract void handleInput(Input input);

	public void handleAlphaInput(AlphaInput input)
	{
		// do nothing
	}

	public void handleBetaInput(BetaInput input)
	{
		// do nothing
	}

	public void handleGammaInput(GammaInput input)
	{
		// do nothing
	}
}

public abstract class Input
{
	public abstract void handleMe(Handler handler);
}

public class AlphaInput extends Input
{
	public void handleMe(Handler handler)
	{
		handler.handleAlphaInput(this);
	}
}

public class BetaInput extends Input
{
	public void handleMe(Handler handler)
	{
		handler.handleBetaInput(this);
	}
}

public class GammaInput extends Input
{
	public void handleMe(Handler handler)
	{
		handler.handleGammaInput(this);
	}
}

public class MyHandler extends Handler
{
	public void handleInput(Input input)
	{
		input.handleMe(this);
	}

	public void handleAlphaInput(AlphaInput alpha)
	{
		//handle one kind of input here
	}

	public void handleBetaInput(BetaInput beta)
	{
		//handle another kind of input here
	}
}

public class Main
{
	public static void main(String[] args)
	{
		Handler handler = new MyHandler();

		//handle an AlphaInput
		Input input = new AlphaInput();
		handler.handleInput(input);

		//handle a BetaInput
		input = new BetaInput();
		handler.handleInput(input);

		//handle a GammaInput
		input = new GammaInput();
		handler.handleInput(input);
	}
}

We must create separate methods to handle alpha, beta and gamma inputs, and these may be optionally be overridden in subclasses of Handler. To decide which to invoke, each subclass of Handler must implement handleInput(Input input) and call input.handleMe(this) to get the subclass of Input to identify its runtime type, by calling the appropriate method and passing itself in. Its ugly, it means that adding new Input subclasses is extremely awkward, but its the best that Java has to offer without using reflection.

I hit a bit of a problem, however, when some of the emails in the pop3 mailbox I was trying to read threw java.io.UnsupportedEncodingException: utf-7. The problem was that the javamail api, while supporting a whole host of character encodings, didn’t support UTF-7. I hadn’t heard of this encoding before and thought maybe, as these were spam emails I was trying to read through, the sender had set a silly value in the header to try and throw off simple mail readers such as mine. However a quick visit to wikipedia informed me that UTF-7 is a real encoding, albeit a rarely used one.

It appears that if you don’t want UTF-7 encoded email to break your mail reader, you have to decode it yourself. The encoding seems a little awkward but there is a solution on this mailing list.

For my purposes, however, it was sufficient to extract the text in an extremely quick and dirty way by reading the raw bytes from the message input stream and only writing out those which fell within the ascii character range (outputting a “?”, otherwise):

private String cheapBodyExtract(InputStream input)
	throws IOException
{
	ByteArrayOutputStream baos = new ByteArrayOutputStream();
	int c;
	while((c = input.read()) != -1)
	{
		baos.write(c);
	}
	byte[] bytes = baos.toByteArray();
	for(byte b : bytes)
	{
		if(b < 32 || b > 127)
		{
			b = '?';
		}
	}

	return new String(bytes);
}

To output the page, the toDocument method is called and written to the servlet response object:

resp.getWriter().write(page.toDocument());

However, in doing this you may find that the resulting page does not look the same as the original HTML, as the Doctype declaration will be missing from the start of the output, leaving the browser in quirks mode as it renders the page.

The lack of doctype is apparently by design, as it is not part of the DOM standard. XMLC does provide the means to add it back in, however, and that is the DOMFormatter object in org.enhydra.xml.io. DOMFormatter writes a DOM tree to an output stream and takes an OutputOptions class to specify various options for doing this. To add the doctype to the output, the public and system ids must be set in the OutputOptions class:

OutputOptions options = new OutputOptions();
options.setPublicId("-//W3C//DTD HTML 4.0 Transitional//EN");
options.setSystemId("http://www.w3.org/TR/REC-html40/loose.dtd");

DOMFormatter formatter = new DOMFormatter(options);
formatter.write(page.getDocument(), resp.getWriter());

<Car xmlns="my-namespace-1">
    <Engine />
    <Wheels>
        <Wheel />
        <Wheel />
        <Wheel />
        <Wheel />
    </Wheels>
</Car>

Here the Car element has the namespace “my-namespace-1″ as
defined by the xmlns attribute. The Engine,
Wheels and each Wheel element all inherit the same
namespace.

However it is worth nothing that the same does not apply to
attributes. Attributes have no namespace unless they are prefixed -
even if a namespace has been defined for their parent element.

For example:

<Car xmlns="my-namespace-1" colour="blue" >
    <Engine cylinders="6" />
    <Wheels>
        <Wheel tirepressure="ok"/>
        <Wheel tirepressure="ok"/>
        <Wheel tirepressure="ok"/>
        <Wheel tirepressure="low"/>
    </Wheels>
</Car>

Here, the cylinders attribute on the Engine, the
tirepressure on the Wheel elements and even the
colour attribute on the Car - all of these belong to the
default namespace rather than to “my-namespace-1″.

For these attributes to use that namespace, a prefix would have to be
defined for them, for example:

<ns:Car xmlns:ns="my-namespace-1" ns:colour="blue" >
    <Engine ns:cylinders="6" />
    <Wheels>
        <Wheel ns:tirepressure="ok" />
        <Wheel ns:tirepressure="ok" />
        <Wheel ns:tirepressure="ok" />
        <Wheel ns:tirepressure="low" />
    </Wheels>
</Car>

$_SESSION["servicename"] = array("Just", "Some", "List", "Of", "Names");

But for some strange reason, this list of names was being reduced to
just the last item in the list. Stranger still, this was only
happening on the live server and not on my machine.

The reason turned out to be register globals. They were turned on
(don’t do this - its a terrible security hole) for the server and not
for my machine. When register globals are on, all the POST and GET
parameters to the script are exposed as variables at the global scope.
For example, hitting your script with a parameter such as

"myscript.php?foo=bar"

will assign the value “bar” to a global variable called $foo.

print $foo; //prints the value "bar"

What I hadn’t realised, however, was that the contents of $_SESSION
are also exposed as variables in the same way. And, of course, I’d
used a variable with the same name without thinking. And assigned to
it, overwriting the data in $_SESSION:

$servicenames = $_SESSION["servicename"];

foreach($servicenames as $servicename) // <-- problem!
{
    print "$servicename <br />";
}

Hence I was left with the last item in the list. This is one of many
reasons to write scripts which DON’T rely on register globals being
turned on.

Generally when using GD or any such image manipulation stuff server-side, you usually check the MIME type and do whatever is necessary with whatever file you’re given. image/gif, image/png etc…

IE6 is funny with JPGs that you upload though, most other browsers will send the MIME type along with the file as image/jpeg. But IE6 sees image/pjpeg.

I’m assuming this is only the case for progressive JPEGs - though I haven’t properly done the research.
This had me driving up the wall for a while, images wouldn’t upload properly, I assumed it was the HTML of course, turns out I just wasn’t detecting the file type as being a JPEG.

<input type="image" src="foobar.gif" name="my_parameter" value="5" />

In Firefox, and probably every other browser other than Internet
Explorer, clicking this submit button will post to the next page 3
parameters:

• “my_parameter”, with a value of “5″
• “my_parameter.x” with the x coordinate of the mouse on the button
  when it was clicked
• “my_parameter.y” with the y coordinate of the mouse

The x and y coordinates are not important for what I was doing - the
important part was that the action of clicking the button submitted a
name-value pair. This meant I could have multiple image submit buttons
at the end of a form and depending on which the user clicked, a
different value would be posted to the next page along with the rest
of the form data.

Internet Explorer 6 (and below, presumably), has other ideas. This
browser submits the following:

• “my_parameter_x” - the x mouse coordinate
• “my_parameter_y” - the y mouse coordinate

Not only does it break the standard by using underscores but it fails
to send the contents of the value attribute at all.

The solution? Probably to use the standard submit button:

<input type="submit" name="my_parameter" value="5" >

This will post the correct parameter, however the text shown on the
button will be the contents of the value attribute: “5″. In my case
this won’t be suitable - I shall have to come up with something else.