Develop Reference

Wicket AjaxFormUpdatingBehavior and Javascript

I have these two DropDownChoice (DDC) objects that work perfectly fine: when one element is chosen from the first DDC, the list for the second gets update with related choices. The first is strumListDDC, the latter is controlListDDC.
controlListDDC.setOutputMarkupId(true);
controlListDDC.setChoiceRenderer(new ChoiceRenderer<>("name"));
controlListDDC.add(new AjaxFormComponentUpdatingBehavior("change") {
#Override
protected void onUpdate(AjaxRequestTarget target) {
QCControl qcc = controlListDDC.getModelObject();
lotList = QCLot.getLotsForCtrl(qcc.getId());
if (!lotList.isEmpty()) {
target.add(lotListDDC);
}
}
});
searchForm.addOrReplace(new Label("strumListLabel", "Strumento:"));
searchForm.addOrReplace(strumListDDC = new DropDownChoice<>("strumList", InstalledStrum.loadAllStrum(false)));
strumListDDC.setDefaultModel(new Model<>());
strumListDDC.add(new AjaxFormComponentUpdatingBehavior("change") {
#Override
protected void onUpdate(AjaxRequestTarget target) {
InstalledStrum is = strumListDDC.getModelObject();
controlList = QCControl.loadQCControlPerStrumType(is.getStrumType());
lotList = new ArrayList<>();
if (!controlList.isEmpty()) {
target.add(controlListDDC);
target.add(lotListDDC);
}
}
});
For niceness reasons, I added this little bit of Javascript to the page template from which all my HTML pages are derived:
$(function filtersScroll() {
var $filters = $(".viewANfilters");
detailsPos = $filters.position().top;
$(window).on("scroll", function () {
if ($(window).scrollTop() > detailsPos)
$filters.css("position", "fixed").css("top", 0);
else
$filters.css("position", "fixed").css("top", detailsPos -$(window).scrollTop());
});
});
I add the javascript through using Wicket (but the problem is still there if I insert the code directly in the HTML, I just post it for completeness):
response.render(JavaScriptContentHeaderItem.forScript(Costants.JS_FILTERS_SCROLL, "filters_scroll"));
When I add the javascript, the onUpdate function of the first DDC never gets called (checked with debugger). As soon as I remove the javascript, the autoupdating behavior starts working fine again. Not that this javascript is fundamental to the page, I can still go on without it, but I fear the same thing will happen again when I will need to add some serious javascript.
Since I'm pretty new at javascript, can anybody give me a hint on what's stopping the AjaxFormComponentUpdatingBehavior from working? Can it be some sort of conflict between different script tags? There are others in the final page, added by Wicket itself, but since they have always been more than one I didn't think a new script would cause any trouble...

Check your selector ".viewANfilters" - if no element with that class is present, position() will be undefined, your JavaScript fails and Wicket won't be able to register any event handlers.

Spotfire - javascript to trigger IronPython script to be executed on report load

I have the follwing javascript code that it triggers an IronPython script when I load the report.
The only issue I have is that for a reason I don't know it does it (it triggers the script) a couple of times.
Can some one help me? below is the script:
var n=0;
$(function () {
function executeScript() {
if (n==0){
n=n+1;
now = new Date();
if (now.getTime()-$('#hiddenBtn input').val()>10000){
$('#hiddenBtn input').val(now.getTime());
$('#hiddenBtn input').focus();
$('#hiddenBtn input').blur();
}
}
}
$(document).ready(function(){executeScript()});
strong text});
Please, let me know if you need more information.
Thanks in advance!!!

I have had similar issues with Javascript executing multiple times. Spotfire seems to instance the JS more than once, and it can cause some interesting behavior...
the best solution, in my opinion, only works if users are accessing the document via a link (as opposed to browsing the library). pass a configuration block to set a document property with a current timestamp, which would execute your IP script. this is the most solid implementation.
otherwise, you can try something like this:
// get a reference to a container on the page with an ID "hidden"
var $hidden = $("#hiddenBtn input");
// only continue if the container is empty
if !($hidden.text()) {
var now = Date.now();
$hidden.text(now)
.focus()
.blur();
|}
this is essentially the same as the code you posted, but instead of relying on the var n, you're counting on the input #hiddenBtn > input being empty. there is a caveat that you'll have to ensure this field is empty before you save the document
one addtional solution is using a Data Function to update the document property, like #user1247722 shows in his answer here: https://stackoverflow.com/a/40712635/4419423

IE8 Unresponsive script error popup on Elements reset

I have a js code which resets the value of elements on jsp by type on ajax response. Code runs a for loop for all elements; gets all elements by name for nearly 800-900 elements. IE 8 gives annoying popup message for unresponsive script. I have been through lot of articles regarding it but none helped so far or I couldnt implement to fix an issue.
Below is the code which is causing pop up.
function clearField(ele,eleType)
{
if(eleType=="checkbox")
{
ele.prop('checked', false);
}
else if(eleType=="text")
{
ele.val("");
ele.removeAttr('disabled');
ele.removeAttr('readonly');
}
else if(eleType=="radio")
{
if(ele.is(':checked'))
{
ele.prop('checked', false);
}
}
else if(eleType=="multiple")
{
if(ele.data('echMultiselect')!==undefined)
{
ele.multiselect("uncheckAll");
ele.multiselect("refresh");
}
}
else if(eleType=="hidden")
{
ele.val("");
}
else
{
ele.val("Select");
ele.removeAttr('disabled');
ele.removeAttr('readonly');}
}
Above function gets called in for loop iteration. ele is fetched as below and passed to a function.
var ele = $("input[name='"+ elementName+"']");
Kindly suggest if any improvement can be done or any other approach can be used to implement the same.

The unresponsive script popup is caused by a long-running function. This blocks javascript's single threaded event loop and renders the page unresponsive until the function exits. If you run the clear asynchronously, the event loop won't get blocked. For example, you can replace clearField(ele,eleType) with setImmediate(clearField.bind(null,ele,eleType)). This is a quick hack to free up the event loop and prevent the popup from appearing, but does not address the performance issues underneath.
DOM access is an expensive operation and accessing hundreds of elements should be avoided, if possible. If your use case is to always reset all the fields to a default stage, I'd suggest having a looooong HTML string of all your elements and just calling $(parent).html(htmlString) to set the elements. This way you only need one DOM access and the effect is instantanious.
http://api.jquery.com/html/

How to impact the HTML rendering priorities with AngularJS?

I'm prerendering my HTML pages for the search engines bots via PhantomJS through Selenium, so that they can see the fully loaded content. Currently, after PhantomJS reached the page, I'm waiting 5 seconds so that I'm sure everything is loaded.
Instead of waiting those 5 seconds every time, one solution I contemplate is to wait until an attribute html-ready on the <body /> tag is set to true:
<html ng-app>
<head>...</head>
<body html-ready="{{htmlReady}}">
...
</body>
</html>
.controller("AnyController", function($scope, $rootScope, AnyService) {
$rootScope.htmlReady = false;
AnyService.anyLongAction(function(anyData) {
$scope.anyData = anyData;
$rootScope.htmlReady = true;
});
})
The question is: will the html-ready attribute always be set to true after any view update has been done (e.g. displaying the anyData)? In other words, is it possible that during a laps, the html-ready attribute is true while the page is not fully loaded yet? If yes, how can it be handled?

It should be done after the digest, thus it has more chances to work as expected.
AnyService.anyLongAction(function(anyData) {
$scope.anyData = anyData;
$timeout(function () {
$rootScope.htmlReady = true;
}, 0, false);
});
But it is useless in terms of the app. You have to watch for changes in every single place, Angular doesn't offer anything to make the task easier.
Fortunately, you are free to abstract from Angular and keep it simple.
var ignoredElements = [];
ignoredElements = ignoredElements.concat($('.continuously-updating-widget').toArray());
var delay = 200; // add to taste
var timeout;
var ready = function () {
$('body').off('DOMSubtreeModified');
clearTimeout(timeoutLimit);
alert('ready');
};
$('body').on('DOMSubtreeModified', function (e) {
if (ignoredElements.indexOf(e.target) < 0) {
clearTimeout(timeout);
timeout = setTimeout(ready, delay);
}
});
var timeoutLimit = setTimeout(ready, 5000);
Feel free to angularify it if needed, though it isn't the production code anyway.
It is a good idea to put the handler into throttle wrapper function (the event will spam all the way). If you use remote requests on the page that can potentially exceed timeout delay, it may be better to combine this approach with several promises from async services and resolve them with $q.all. Still, much better than looking after every single directive and service.
DOMSubtreeModified is considered to be obsolete (it never was really acknowledged, MutationObserver is recommended instead), but current versions of FF and Chrome support it, and it should be ok for Selenium.

Short answer
No. It isn't guaranteed that your markup will be completely rendered when html-ready is set.
Long answer
To the best of my knowledge it's not possible to accurately determine when Angular has finished updating the DOM after the model changed. In general it happens very fast and it doesn't take more than a few cycles to finish, but that's not always the case.
Correctly detecting when a page has finished loading/rendering is actually quite a challenge, and if you take a look at the source code of specialized tools, like prerender, you'll see that they use several different checks in order to try to decide whether a page is ready or not. And even so it doesn't work 100% of the time (Phantom may crash, a request may take longer than usual to complete, and so on).
If you really want to come up with your own solution for this problem, I suggest that you take a look at prerender's source code (or another similar project) to get some inspiration.

innerHTML can't be trusted: Does not always execute synchronously

To see the problem in action, see this jsbin. Clicking on the button triggers the buttonHandler(), which looks like this:
function buttonHandler() {
var elm = document.getElementById("progress");
elm.innerHTML = "thinking";
longPrimeCalc();
}
You would expect that this code changes the text of the div to "thinking", and then runs longPrimeCalc(), an arithmetic function that takes a few seconds to complete. However, this is not what happens. Instead, "longPrimeCalc" completes first, and then the text is updated to "thinking" after it's done running, as if the order of the two lines of code were reversed.
It appears that the browser does not run "innerHTML" code synchronously, but instead creates a new thread for it that executes at its own leisure.
My questions:
What is happening under the hood that is leading to this behavior?
How can I get the browser to behave the way I would expect, that is, force it to update the "innerHTML" before it executes "longPrimeCalc()"?
I tested this in the latest version of chrome.

Your surmise is incorrect. The .innerHTML update does complete synchronously (and the browser most definitely does not create a new thread). The browser simply does not bother to update the window until your code is finished. If you were to interrogate the DOM in some way that required the view to be updated, then the browser would have no choice.
For example, right after you set the innerHTML, add this line:
var sz = elm.clientHeight; // whoops that's not it; hold on ...
edit — I might figure out a way to trick the browser, or it might be impossible; it's certainly true that launching your long computation in a separate event loop will make it work:
setTimeout(longPrimeCalc, 10); // not 0, at least not with Firefox!
A good lesson here is that browsers try hard not to do pointless re-flows of the page layout. If your code had gone off on a prime number vacation and then come back and updated the innerHTML again, the browser would have saved some pointless work. Even if it's not painting an updated layout, browsers still have to figure out what's happened to the DOM in order to provide consistent answers when things like element sizes and positions are interrogated.

I think the way it works is that the currently running code completes first, then all the page updates are done. In this case, calling longPrimeCalc causes more code to be executed, and only when it is done does the page update change.
To fix this you have to have the currently running code terminate, then start the calculation in another context. You can do that with setTimeout. I'm not sure if there's any other way besides that.
Here is a jsfiddle showing the behavior. You don't have to pass a callback to longPrimeCalc, you just have to create another function which does what you want with the return value. Essentially you want to defer the calculation to another "thread" of execution. Writing the code this way makes it obvious what you're doing (Updated again to make it potentially nicer):
function defer(f, callback) {
var proc = function() {
result = f();
if (callback) {
callback(result);
}
}
setTimeout(proc, 50);
}
function buttonHandler() {
var elm = document.getElementById("progress");
elm.innerHTML = "thinking...";
defer(longPrimeCalc, function (isPrime) {
if (isPrime) {
elm.innerHTML = "It was a prime!";
}
else {
elm.innerHTML = "It was not a prime =(";
}
});
}