We can just put reload button regardless the result of the initial
rendering perhaps?
- Henry
On Wed, Jul 18, 2012 at 6:33 AM, Dan Dumont <ddum...@us.ibm.com> wrote:
> Has anyone thought of how to retry a gadget render that fails?
>
> Currently we have a message that we insert into the site if we detect a
> failure, and we'd like to put a reload button. But, after thinking about
> the code in shindig, and all of the lifecycle events in the container and
> the complexity of the navigate chain, I'm starting to feel pessimistic
> about doing this in a way that won't be really screwy.
>
> For instance, in the gadget lifecycle, It's not clear that the lifecycle
> events for a site may each happen once...
>
> So if I did something like:
>
> (function() {
> var original = osapi.container.Container.prototype.navigateGadget,
> retries = {};
> // override
> osapi.container.Container.prototype.navigateGadget = function(site,
> gadgetUrl, viewParams, renderParams, opt_callback) {
> original(site, gadgetUrl, viewParams, renderParams, function
> (gadgetInfo) {
> if (gadgetInfo.error) {
> // Don't call the original callback with the error, wait till we
> can retry it.
> retries[site.getId()] = function() {
> osapi.container.Container.prototype.navigateGadget(site,
> gadgetUrl, viewParams, renderParams, opt_callback);
> }; // User intervention will call this later... trust me.
> } else {
> opt_callback(gadgetInfo);
> }
> });
> };
> })();
> (Apologies for the formatting! Are we allowed to use pastebin?)
>
> Then lifecycle event listeners will be called multiple times for gadgets
> that need to be retried...
> I'm a bit uneasy over this kind of magic... I'm not sure what all the
> implications are on the rest of the container and CommonContainer code (or
> feature code similar to actions that does things with lifecycle
> listeners).
>
> Any thoughts?
