What was the design decision behind ItemPendingError in Flex?

Question

Flex has the notion of lazily loading data. It has a class named ItemPendingError which allows developers to handle it when an attempt is made to access data that is not yet available aka "pending".

However, looking at the documentation it's clear you have to add try/catch blocks around your code wherever you have code that might cause an IPE (ItemPendingError) to occur.

I'm curious if anyone knows why it works this way. I'm not sure what the best solution might be, but having to willy-nilly add in try/catch blocks to catch the error and then register a Responder with it feels bad and not very clean. And the fact that you sort of have to exercise your application to make sure you've caught all the possible places where the error might occur is also lame.

Is there some other way or better approach that I haven't seen/heard of?

Answer 1

At first glance, you're right. This approach "feels" lame. The problem is, there's a large amount of data and you want to access it at random but you don't want to load it. You have two options, wait for all the data to load up front or wait for the data to load when you want it. Flex uses the latter approach.

So really, I guess you're always assuming the data won't be there and you have to deal with that accordingly. The only way to avoid a try / catch block it would seem is to always check to see if the item is loaded (and wait while you load it if it isn't) before attempting to access it. Perhaps the creators of Flex felt like it was easier to code if you assume that the data is always available and just handle the error if it isn't?

I suppose this is more of a comment than an answer but I hope it helps.

Answer 2

I think that it is a language limitation and the nature of the client-server relationship implementation. The "persistence" is faked, and because of the asynchronous nature of the language the ItemPendingError lets components know that the object/collection is being fetched, and it doesn't need to keep asking the server for it (which would cause obvious problems). Components like List and DataGrid are built to handle the error, so they don't present much of a problem, and once you abstract it out in this manner it isn't such a pain.

This is an interesting approach to abstracting this issue...

Answer 3

An interesting aspect to binding is that you can ask for something asynchronously and let the binding refresh the GUI whenever it shows up.

For example, you have a list of items each of which has properties that link to objects bound to the display. As the user moves to new items, the accessor of those properties makes an asynchronous call to a server because it is waiting for the first request. The response from the server gets put into that property when it comes back from the server (and pokes the binding event).

The binding deals with a null anywhere along the chain, so the GUI shows nothing until the final target object gets filled.

Cheers