$xml = simplexml_load_file('path_to_the_file');

Sometimes you’d need to dump or save the entire XML as a string, but there’s no toString method! As you can see $xml is an instance of the SimpleXMLElement class.

var_dump($xml); // object(SimpleXMLElement)...

Actually if you take a closer look:

$xml->toString();

will return “Call to an undefined method toString()”, which is frustrating because the developers community is used to use toString() when converting an object into a string.

The solution

In fact there’s a method doing exactly what’s needed. This is SimpleXMLElement::asXML

As described in the manual page: “SimpleXMLElement::asXML — Return a well-formed XML string based on SimpleXML element” [2].

Besides that it does exactly what’s needed it sounds irrelevant, because you’ve an XML object and the name “asXML” doesn’t describe correctly what’s expected.

$xml->asXML() // ?!

1. SimpleXMLElement::asXML
2. SimpleXML Introduction

// before
$mail = new Zend_Mail('utf-8');
$mail->setFrom('sender@example.com', 'Sender Name');
$mail->setBody('message in Html');
$mail->addTo('recipient@example.com', 'Recepient Name');
$mail->setSubject('Subject');
$mail->send();

// after
$mail = new Zend_Mail('utf-8');
$mail->setFrom('sender@example.com', 'Sender Name');
$mail->setBodyHtml('message in Html');
$mail->addTo('recipient@example.com', 'Recepient Name');
$mail->setSubject('Subject');
$mail->send();

You want to submit the form by clicking on a link or some other element on the page and this is a simple task. You know that by simply adding something like document.forms[‘the-form-name’].submit() this will work.

    
    Submit

However you’d like to submit the form not only by clicking on that particular element, but also by clicking on the Enter while the focus is on a input field, and this wont work! That’s because you don’t have a input type=”submit”.

OK, first thing is to add a hidden input type=”submit” – than by clicking both on the Enter keyboard button and on the link with the onclick=”document.blah.blah.blah” will submit the form.

    
    
    Submit

But this is not true!

Than you’ll receive the following message:

document.forms['myform'].submit() is not a function

Why? This isn’t working, but ever line seems to be OK. The answer is – don’t name the input type=”submit” with the trivial – “submit”. Just give it another name:

    
    
    Submit

In example when saving a HTML formatted text you can use simply the htmlspecialchars method

$description = htmlspecialchars($_POST['description']);

Than you can be sure everything’s in the database, but it’s not actually HTML. Thus you don’t have any tags at all in the database field.

When you show this in the client side and you’d like to strip some tags, i.e. to keep only the <a> tag you can do this:

echo strip_tags(htmlspecialchars_decode($description), '<a>');

That’s the most simple way to keep everything as the original source. By me it’s better to keep whatever HTML markup there is on the input.

In fact how and why should I optimize CSS is the right question. Actually CSS is simply one ore more files loaded from the server to the client, usually a browser, with CSS specific rules that must be applied by the browser to the web page you’re seeing. That’s in general. Of course there are exceptions when CSS can be inline or added directly to the HTML tags, which is bad practice because thus the HTML markup becomes larger and even worse the browser cannot cache it and than load it quickly. In fact that’s why usually the CSS of a web page is put in one single file. Primary because that makes only one request to the server and in second hand because it can be cached by the browser.

Just because the nature of the CSS is that firstly it’s loaded and than executed one of the primary techniques of optimizing it is to make it smaller and therefore load faster. There are several methods of doing so. Enabling GZIP support of the web server and minifying the file are the most common ones. But one of the tricks you cannot optimizing just for second is using the so called CSS sprites.

CSS sprites

What are these? To answer this question I’ll simply try to give you an example. Let’s assume there are three CSS classes each one with its own background image. This makes four requests to the server. One for the CSS file and one per every background image. But what we’d like to achieve is to make less requests as we can. Than one of the things we can do is to make one single image and to change only the background-position CSS property to position it on the right place and to make it appear correctly.

Be careful! When you join all of the images into one single CSS sprite you may add one class with that background-image and every other class with only background-position property. Than every DOM element with that background must have both class names. Only than you can be sure the server will make two requests. One for the CSS file and one for the sprite.

base64 to encode images

In other hand most of the web projects are pretty big, and unfortunately it’s too difficult to make only one single sprite just because it’s too difficult to manage it after the project has become very large. That’s why mostly in the practice there are several sprites for the main components. But the problem is that again there are more HTTP requests.

Is there any way to make only one request?

Yes there is. Simply by converting your CSS sprite into a base64 encoded image. In breve base64 is an encoding where you can practically make any data into a string. Thus the image can be represented by a string containing the same information as the image. Hopefully most of the browser, except of course MSIE, does read the so called data urls, or:

<img src="data:image/png;base64,..... " />

and that’s enough to get started with base64 and the single request. The sprite has become a string!

CSS and base64

The natural question is now how to merge all this? You now have one CSS file with one or more sprites. Than you can convert them into a base64 encoded strings and put them all into the CSS.

There is a problem, of course, what happens with MSIE. As I said before MSIE doesn’t read base64 encoded images. Hopefully there is a solution described very well by Stoyan Stefanov in his blog post here.

Finally …

now there is only one request and everything works pretty fine. This technique can be really helpful to someone who’s trying to optimize the CSS performance to the limits.

First of all you’ve to add this at the beginning of the page with the simple js code:

var jsReady = false;
function isReady()
{
return jsReady;
}

function pageInit()
{
jsReady = true;
}

of course the pageInit() function should be called onload of the body. It simply sets the JavaScript part to be ready for communication, after initialize the page. Than a small part of the javascript should be written for really speaking with the Flex application.

var swfReady = false;

function setSWFIsReady() {
swfReady = true;
}

function getSWF(movieName) {
if (navigator.appName.indexOf(“Microsoft”) != -1) {
return window[movieName];
} else {
return document[movieName];
}
}

function callFlexApp() {
if (swfReady) {
getSWF(“flash_movie”).methodInFlex(param_value1, param_value2);
}
}

Where flash_movie is the id of the object / embed pair.

First of all the JavaScript can begin to call methods in Flex only after the Flex application has returned that it has been initialized. That happens in Flex within the following file:

package communicator {

import flash.events.TimerEvent;
import flash.external.*;
import flash.utils.Timer;

public class Communicator
{

public function init():void {

if (ExternalInterface.available)
{

var containerReady:Boolean = isContainerReady();
if (containerReady)
{
setupCallbacks();
}
else
{
var readyTimer:Timer = new Timer(100);
readyTimer.addEventListener(TimerEvent.TIMER, timerHandler);
readyTimer.start();
}

}
else
{
trace(“External interface is not available for this container.”);
}

}

private function isContainerReady():Boolean
{
var result:Boolean = ExternalInterface.call(“isReady”);
return result;
}

private function setupCallbacks():void
{
ExternalInterface.addCallback(“callFlexApp”, callFlexApp);
ExternalInterface.call(“setSWFIsReady”);
}

private function timerHandler(event:TimerEvent):void
{
var isReady:Boolean = isContainerReady();
if (isReady)
{
Timer(event.target).stop();
setupCallbacks();
}

}

private function callFlexApp(param1:int, param2:int):void
{
// this function is called from javascript

}

}

}

That’s the short description how to set up a communcation between JavaScript and Flex.

The disadvantages of using SWFAddress is that the communication is slow and it had to change the uri, which is not always something the developer needs. In general the the Flex application listens for uri changes, simply by setting a timeout for a listener with very short period of time, like 10 milliseconds, and if some change occurs get’s the uri, parses it and process the changes.

From the beginning the hard-coded listening of the uri change is not a good idea. Even for very short timeouts it become risky when the user can click and skip an important refresh inside the flex application.

I strongly recommend the use of the build in ExternalInterface. The communication via ExternalInterface can be done in both directions to JavaScript to Flex and vice versa, which is the main advantage is the lack of programmatically added listening processes. Here all it’s done by the interface and the response from the other side is guaranteed.

There are tricky parts, of course, but in general it’s a secure and reliable way to talk between these two technologies.

A sample of the process you can find here.