Let me give you two ways to do it.
1) CustomBehavior!
The most broadly useful technique to do this is to create another customBehavior further upstream in the view, whose job is to leave a hook to itself, for later that you'll use to push downstream and re-dispatch the main search(es).
So higher up in the page, typically just after the main Button module if there is one, you would have
<module name="CustomBehavior">
<param name="customBehavior">hookForReloadingPage</param>
... make sure everything you need to redispatch and refresh is downstream from this module...
Here's the definition. We dont even really define any behavior, we just leave a global reference to the module object itself for later. (Yes globals are evil and window._reloader is not going to win you any js awards, but you'll be fine. )
Sideview.utils.declareCustomBehavior("hookForReloadingPage", function(module) {
if (window._reloader) {
console.error("hookForReloadingPage - There can be only one.");
return false;
}
window._reloader = module;
});
By the time any searches are dispatched on the page, that window._reloader will have been defined long ago, so whenever you need to reload the main searches to show changes, just call from the JS:
window._reloader.pushContextToChildren()
Of course, the big question becomes, exactly when is it safe to call pushContextToChildren? The UI framework is better than you might think about cancelling and aborting searches once they seem to be superceded by subsequent interaction, and if you dont think about this, it's not hard to reload the page before or even at the exact time you're dispatching your "updating" search, setting up a race.
My advice is if you have an existing CustomBehavior that is running when the button is clicked to do something, implement this inside that existing customBehavior:
var PCTCReference = module.pushContextToChildren.bind(module);
module.pushContextToChildren = function() {
PCTCReference();
window._reloader.pushContextToChildren();
}
It looks a little insane, and it looks like a race, but the "updating" search will definitely get dispatched here before the main search reload is triggered. And I believe that "updating" search will be able to run to completion unperturbed while the upstream "main" search(es) redispatch.
2) the Gate module
There is another way, and that's to use the Gate module. If you weren't already using a customBehavior in your view, I'd say go with the Gate.
In this scenario, this Gate module takes the place of our reloader customBehavior
<module name="Gate">
<param name="id">reloader</param>
... everything you need to reload/redispatch is downstream from this Gate...
And then further downstream your button and search etc would look like this:
<module name="Button">
<param name="label">update</param>
<module name="Search"> | inputlookup | EvalStatementsToUpdateThings | outputlookup</param>
<!-- customBehavior is sometimes useful to just sneak in with only requiresDispatch
so as to force a dispatch at a particular point wihtout an unwanted visible module
like JobProgressIndicator being there. -->
<module name="CustomBehavior">
<param name="requiresDispatch">True</param>
<module name="Gate">
<param name="to">reloader</param>
</module>
</module>
End result is the same. On button click the search runs, once it's dispatched and running the context push moves down to the Gate module, which reaches up to the top of the page and starts a push from up there. Terrifying circular push ftw!
... View more
