views:

111

answers:

4

I am basically quite sure this pattern must exist and possess a name... for now I will call it "gate pattern"...

Here it is:

In my webpage's javascript, I have to trigger various asynchronous processes. Let's not discuss how trully async js is, but anyway I have to trigger 2 or 3 AJAX calls, must be sure, the UI build-up has finished, and so on.

Only then, when all these processes have finished, I want to do run a certain function. And precisely once.

Example

1: cropStore loaded()
2: resizeEvent()
3: productStore loaded()

The Pattern: At the end of every (sucessful) Ajax-load-callback, the end of the GUI construction routine, etc... I set a respective flag from false to true and call gatedAction()

onEvent( 'load',
{
   ....  // whatever has to happen in response to cropStored, resized, etc...
   // lastly:
   f1 = true; //resp f2, f3, ...
   gatedAction();
}

Gate will check the flags, return if any flag is still unset, only calling the target function, if all flags (or as I call them: gates) are open. If all my async pre-conditions call gatedAction() exactly once, I hope I can be sure, the actual targetFunction is called exactly once().

gatedAction ()
{
   // Gate
   if ( ! f1) return;
   if ( ! f2) return;
   if ( ! f3) return;

   // actual Action ( <=> f1==f2==f3==true )
   targetFunction();
}

In practice it works reliably. On a side-note: I think java-typical (not js-typical) synchronization/volatile concerns can be ignored, because javascript is not truly multithreading. Afaik a function is never stopped in the middle of it, just to grant another javascript function in the same document run-time...

So, anyone, is there a name for this? :-)

I need this pattern actually quite often, especially with complex backend UIs.. (and yes, I think, I will turn the above butt-ugly implementation into a more reusable javascript... With a gates array and a target function.)

+1  A: 

It sounds like Balking pattern to me.

reko_t
A good first pointer! Thanx. It talks of only a single precondition though. And my exactly-once mantra (in the face of coming from multiple calls/threads) is also not reflected...
Fronker
Well in this case the pre-condition would be that "all these methods have finished executing"; it still is a single pre-condition.
reko_t
Balking is about acting *object* state - but there can be any number of states to check, in fact this is frequently implemented as a switch. cf. the pattern I have heard referred to variously as the gatekeeper or guardian or clause pattern which is about checking *input*.
annakata
Thanx. I have a hard time googling these (in a software context. plenty of clause patterns...). There's a software-related but still-offtopic (though interesting) gatekeeper pattern (think: Scrum MC/PO) here http://users.rcn.com/jcoplien/Patterns/Process/section26.html , even if I translate this to software itself, it's something different.
Fronker
A: 

In addition to the actual answer to your question, you might be interested in the Rx framework for Javascript. It's a port of the .NET version and allows you to compose events, so you don't have to work with tons of flag variables. It's meant for this sort of thing.

http://msdn.microsoft.com/en-us/devlabs/ee794896.aspx

JulianR
But way too heavy. What I got in mind should fit into a 20-30 lines of javascript, even in a generalized form. (Looking at typical ExtJS javascript code, at least that's my estimate).Still: Thanx!
Fronker
+1  A: 

I have no idea, if your pattern has a special name, but it seems equivalent to just using a counting semaphore, which blocks the thread, which started all those other actions, until they all made a V-invocation. Of course, there are no threads and semaphores in JavaScript, but instead of using many boolean variables you could use just one integer for counting.

Dominik Seibold
">you could use just one integer for counting" In practice: No. Stuff like resize events are notorious to kick in multiple times, even on a single resize. (OK, my question wording was not precise: Target action exactly once, after all prerequisite actions at least once is probably what hits it)
Fronker
+1  A: 

It is similar to the Rendezvous pattern, although that pattern is generally used in the context of multithreaded real-time systems.

Kristopher Johnson
Cool. We're getting close! "reifies the synchronization of multiple threads as an object itself" hits it quite well (the above pattern is not meant as a singleton, there can be distinct things "to jointly wait for" in a big page).
Fronker
"The Rendezvous object may contain data to be shared as the threads synchronize" actually covers a point I ommited. Because once all pre-requisite threads are done with their part, indeed there's typically stuff the targetAction must access regarding "their work". So having threads deposit "their stuff" (result/construct reference) as an array parameter of gatedAction() makes a lot more sense then channeling it by other (dodgier) means...
Fronker