Dispatched urls can lead to problems with data that hasn't loaded

[j.c.sackett]

The GUI has urls that can load various components (e.g. /inspector/juju-gui, /inspector/juju-gui/charm). Loading this urls directly can lead to rendering problems and other errors because services, charms, or other data may not be in the db yet.

We address this now where it's cropped up by either bailing out of the url and asking the user to try again, since data will be loaded when the user can react, or by entering various fragile retry-loops.

A better solution to the root problem is needed.

[j.c.sackett (jcsackett)]

The better fix for this after Jeff and I looked into this is to break up the inspector rendering into two steps. The first loads the inspector UI (absent the service/charm info), the second populates the info.

Much as we do now, we check to see if we have model and charm data; if we do, we proceed directly to the second stop. If not, we set up a function listening for the db.services and db.charms add signals, to check the db for the necessary info each time it's added. After a timeout, if no data is found, we can abort much as we do now (send notification and close the inspector).

This function needs to detach itself from the db events once it finds the data it needs, and then proceed to the second rendering step.

[j.c.sackett (jcsackett)]

Note that this should wait until after we remove the Ghost inspector; we need to check the model immediately to determine what sort of inspector we're rendering, which means we would have to put all of the logic above into the dispatch code--we would rather have it in the service inspector.