Archive

Posts Tagged ‘HTMLLoader’

HTMLLoader

May 9th, 2008 1 comment

HTMLLoader does not exposes any useful error. I understand the need for security, the fact that this component was created for a developer who loads known content, but I cannot explain why Adobe didn’t go all the way with it. It is known that they are planning to modify the security rules once again, but when we could expect to let developer know about the basic events of this component?

If you really need to use HTMLLoader in your AIR application the plan should go like this:

1. Use a URLLoader to load the HTML page you are intending to display. Setting the dataFormat to URLLoaderDataFormat.TEXT will permit you to load the data in the HTMLLoader using loadString() method. The use of URLLoader is helping you listen for HTTPStatus and IOError events, so you could know that a URL is invalid or it cannot be accessed. Also, you can display progress if it is needed, right?

2. The documentation says that HTMLLoader might not trigger complete event, depending upon the page. So, first you’ll have to make sure that no HTMLUncaughtScriptExceptionEvent is not caught, because you can orient yourself with this event too. You also need to know that if you change the URL to something invalid, the previous loaded page will not clear and again, you have no event that you could listen.

3. Mount a timer that will check if there is a DOM for your HTMLLoader and/or check for the domWindow.document.URL (usually if there is a error that you should know about, the document.URL didn’t got updated – the HTMLLoader component will behave like nothing happen). Look if the event htmlDOMInitialize fires, it might help too (depending on what you have to do). Do not assume that everything went well only because you can see the content of some page (remeber ? there are pages which never trigger complete event).

I hate to admit it (since I am a big fan of Adobe), but they screw up on this one – and they did it big time. To expect that one day a HTMLLoader will also be available for Flex (not only for AIR) – even if that means going through a security sandbox (to check if the page is loaded from the same domain as the Flex application) it is too much: the AIR is not ready for a serious browser like experience.

I find it interesting that there are people out there that still think that displaying HTML pages in AIR is easy. It might be easy if you want to leave every event on chance, hoping that no-one will complain about it, or the user will understand the fact that some pages are not working!

WebKit integration is poor documented, code completion for HTMLLoader and FlexHTMLLoader is not so complete, the usage of HTMLLoader (there are some articles) seems so rigid (for something named Flex) – maybe AIR 1.0 is not so ready to display HTML page at a professional level, leaving the impression that was made in a hurry, without fully understanding the need of a developer which might want to make use of this capability.