1

We have an ASP MVC application that leverages partial-page AJAX updates. When a user-driven action occurs on one panel of our screen, we need to ensure our jsTree (in a separate panel) updates.

However, attempting to act within the success: portion of the AJAX call does not work - this occurs too early, and the jsTree is not yet ready to accept these commands. Executing the same commands later works just fine.

We've worked around the issue as follows: -Upon the AJAX success, store the desired callback method in a new Javascript class:

var EPCStateMembers =
{
    _callbackMethod: "",

    StoreCallback: function (callbackMethod)
    {
        EPCStateMembers._callbackMethod = callbackMethod;
    },

    UseCallback: function ()
    {
        if (EPCStateMembers._callbackMethod != "")
            EPCStateMembers._callbackMethod();

        EPCStateMembers._callbackMethod = "";
    }
}

Within the AJAX success, we call EPCStateMembers.StoreCallback()

Then, once the jsTree is ready (indicated by its own event, reselect.jstree) - we invoke

EPCStateMembers.UseCallback();

Functionally, this solution works.

However, before we resign ourselves to temporary Javascript state storers as our goto solution...I'd like to ask the question - does a better pattern or practice exist for such situations?

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
Jamie Russell
  • 11
  • 2
  • I'm not sure I understand what you mean by "too early". Why is the jsTree not yet ready to accept those commands? Is the jsTree updated as well? – lbstr Jun 14 '12 at 21:32
  • lbstr - If I breakpoint within the web browser while executing the lines of code that instruct the jstree to clear selections, then select the new node, nothing visually occurs. When I then proceed, I watch the tree display as it instructed to initially load - opening and highlighting the first node. (I tested removing these specifications, and the too-early code still does not 'stick'.) When I execute the same code within the reselect.jstree event, the selection occurs. – Jamie Russell Jun 15 '12 at 14:50
  • I found this today. Is this an appropriate tool for this problem? http://stackoverflow.com/questions/9583783/when-should-i-use-jquery-deferreds-then-method-and-when-should-i-use-the-pip – Jamie Russell Jun 15 '12 at 14:52

1 Answers1

0

I agree as far as it should be stored and executed as some type of onload event that occurs on the tree object.

But, since this is regularly occuring operation(mutating the jstree) and not a one time initialization thing, maybe jstree should be the one to worry about its own internal state, and should queue mutation requests on its own, when necessary.

I say this only because I try to avoid objects that have complicated api's due complicated internal state. I don't like having to worry about whether methodX will fail or do the equivalent of throw IllegalStateException when it's reasonable to design that possibility out.

Plus, you keep the code more DRY. You wont ever have multiple occurrences of if(!tree.ready()) { queueit() } littering your code, when it could have been done in one place, encapsulating it.

goat
  • 31,486
  • 7
  • 73
  • 96
  • http://stackoverflow.com/questions/9583783/when-should-i-use-jquery-deferreds-then-method-and-when-should-i-use-the-pip – Jamie Russell Jun 15 '12 at 14:51