is it possible to delay loading of some controls on an xpage?
This is the problem: let's say you have a control that does a fultextsearch and displays the result in a repeat control. this ft search might take a long time and will hold the webpage loading in a waiting state until the search result is ready.
I want my page to load most of the data initally, and some "time consuming" controls should be loaded in to the page as a sperate request after the inital load.
this way the user will immediatly see the webpage, but some of the data on the page will load a little bit later without holding the webpage in a waiting state from the server.
possible?
The downside to using rendered is that all the value bindings will still evaluate, even if the corresponding markup isn't sent to the page. So the trick here is making sure the components don't even exist until you want them to.
Every component has a getChildren() method. This returns a mutable List of components, which has a add() method. This allows you to add components to the page on the fly, either while the page is loading, or later during an event. For the purposes of what you're trying to do, you would want to defer adding the "expensive" components until a subsequent event.
Create an event handler attached directly to the view root (), give it a unique ID (e.g. "loadExpensiveComponentsEvent", set its refresh mode to partial, set a refresh ID to whatever div or panel will contain the search results, and set its event name to an arbitrary event (e.g. "loadExpensiveComponents"). This prevents your event from being triggered by actual user behavior. Set the event's code to SSJS that will inject your components.
Then add a script block () to trigger the event after the page has loaded:
XSP.addOnLoad(function(){
XSP.firePartial(null, "#{id:loadExpensiveComponentsEvent}");
});
Your page will load without the search result components. Once the page has fully loaded, it will trigger the component injection event automatically.
For guidance on how to code the injection event, open the Java file that has been generated from your existing page to see what components need to be injected and what to set their values to.
You can pack them into a panel and set their rendered status to rendered=#{viewScope.pageFullyLoaded}. Then in the onLoad event have a XSP. partialRefresh request where you set viewScope.pageFullyLoaded=true
A little ugly but doable. Now you can wrap that code into your own custom control, so you could have a "lazyGrid", "lazyPanel" etc.
Not sure why I did not think of this before. the dynamic content control in extlib actually solves this problem. the dcc can be triggered onClientLoad both using javascript and ssjs afer the page has loaded.
one problem I am facing now is that I am already using the dcc on my site so I need to put another dcc within my dcc. and this seem to be a bit buggy. I have reported it to the extlib team on openNTF.
Related
I'm new with Ember and I would like to show a full screen overlay when a user presses a "get stuff from the server" button.
What is the best way to achieve this?
Does Ember already provide something built-in? Or is it that the only way is to have a piece of HTML in one of my templates, to show/hide it when the promise where I make the AJAX call returns?
You have a few options available to you.
The first concerns a route change. Conventionally speaking, if the user is hitting a button that transitions to another route, a separate route can be created to handle this in-between loading experience.
To describe this briefly, if you have a route named foo, creating a sibling route named foo-loading with an associated template, will show a "foo-loading" page state while things are being fetched, and then dismiss it once things are good.
Alternatively, as you've hinted, if the call to action for a user intends an updated result on the same route, a loading service could be useful. In your application template, you could have a loading div that is hidden by default. Prior to initiating an AJAX request, you could turn the loading state on and reveal the loading div. Then, once the AJAX call is settled, the finally block could include a call to conceal the loading div.
This latter approach would involve a conditionally loaded block in the primary application template, a loading service handling show and hide, and a loading template.
You could use ember-modal-dialog to create a loading screen component that gets rendered when you're waiting for your ajax request.
For example:
// view.js
showLoadingScreen: true
// view.html
{{#if showLoadingScreen}}
{{loading-screen}}
{{/if}}
// loading-screen.html
{{#ember-modal-dialog}}
<div class="loader-full-screen-class"></div>
{{/modal-dialog}}
The advantage of the component/ember-modal-dialog is that this pattern is usually implemented as a modal, and this library is the standard in ember. The component then allows you to put it anywhere you need it to be.
Recently I've overridden Wicket's DefaultPageStore methods serializePage and deserializePage and enhanced them with logging to track time spent in them.
I discovered that deserializePage is never called because the actual page is always retrieved from the SessionEntry#sessionCache.
I suspect this is due to my page setting setVersionPagesByDefault(false) which creates the situation where there is only current version of a page which is serialized in the SessionEntry and then (needlessly) in the DefaultPageStore from where it's never deserialized.
If this suspicion is correct, I'm then able to make method serializePage a no-op a and skip serialization, which currently takes 3 or 7 seconds (DeflatedJavaSerializer) for page X.
I did not detect any side-effects so far, so my question is: is this safe? And if not, then why?
I'm considering this only as temporary solution until I'm able to move the data from the page to proper cache.
Here is some info on page versioning: http://wicket.apache.org/guide/guide/versioningCaching.html
If you do not need support for back button, you can disable page versioning - it has not side effects, assuming that your pages handle back button correctly. Jumping back to the page that has no state can create page without initial parameters. Like for example: you jump from page A to B and provide some arguments to B. Now user is on page C and clicks back button. This will result in redirect to page B, but no arguments will be passed this time. If you would use page versioning, wicket would only deserialize page B and execute rendering again.
Here is also one possibility to disable page store:
http://maciej-miklas.blogspot.de/2013/09/wicket-6-disable-page-serialization.html
I am a newbie in JSF.I am creating a simple page with a checkbox and a readonly field.When I deploy to weblogic server ,I get what is expected output.
Now I have put autosubmit property on checkbox and partialtrigger propery on the other readonly field.My readonly field changes as expected on changing the state
of checkbox.I was curious to find out what Ajax code has been put in finally rendered page when i declare auto submit property to true.Basically I want to know
what is the html and ajax(javascript) code difference between the case when auto submit property is enabled and disabled.Is there any tool which can compare two source codes?
Thanks in advance.
Being able to see the exact difference in code may be difficult as the associated Javascript files for your JSF component toolkit have probably been minified, however you should at least be able to see the difference in the Javascript event declarations on the generated input element.
A tool like Firebug is the best choice as it gives you the ability to highlight DOM elements and view their corresponding styles, attributes, and events. It doubles as an excellent Javascript debugger as well, allowing you to place breakpoints in JS code so that you can walk through the execution of what is happening on each click event.
When autoSubmit is false, there is likely no Javascript event being triggered. When it is true however, there is likely an onclick event being triggered that is formulating an Ajax request. You might have a hard time figuring out what is happening because it is minified, however it is more than likely making such a call.
http://docs.oracle.com/cd/E17802_01/j2ee/javaee/javaserverfaces/2.0/docs/js-api/symbols/jsf.ajax.html
I have an app that has several different types of form elements which all post data to the server with jQuery AJAX.
What I want to do is:
Show a loader during AJAX transmission
Prevent the user from submitting twice+ (clicking a lot)
This is easy to do on a one off basis for every type of form on the site (comments, file upload, etc). But I'm curious to learn if that is a more global way to handle this?
Something that's smart enough to say:
If a form is submitting to the server and waiting for a response, ignore all submits
Show a DISABLED class on the submitted / clicked item
Show a loading class on the class="spinner" which is closest to the submit item clicked
What do you think? Good idea? Done before?
Take a look at the jQuery Global Ajax Event Handlers.
In a nutshell, you can set events which occur on each and every AJAX request, hence the name Global Event Handlers. There are a few different events, I'll use ajaxStart() and ajaxComplete() in my code sample below.
The idea is that we show the loading, disable the form & button on the ajaxStart() event, then reenable the form and hide the loading element inside the ajaxComplete() event.
var $form = $("form");
$form.ajaxStart(function() {
// show loading
$("#loading", this).show();
// Add class of disabled to form element
$(this).addClass("disabled");
// Disable button
$("input[type=submit]", this).attr("disabled", true);
});
And the AJAX complete event
$form.ajaxComplete(function() {
// hide loading
$("#loading", this).hide();
// Remove disabled class
$(this).removeClass("disabled");
// Re-enable button
$("input[type=submit]", this).removeAttr("disabled");
});
You might need to attach to the ajaxError event as well in case an AJAX call fails since you might need to clean up some of the elements. Test it out and see what happens on a failed AJAX request.
P.S. If you're calling $.ajax or similar ($.getJSON), you can still set these events via $.ajaxStart and $.ajaxComplete since the AJAX isn't attached to any element. You'll need to rearrange the code a little though since you won't have access to $(this).
I believe you have to do 2 for sure and 3 to improve usability of your app. It is better to keep backend dumb but if you have a security issue you should handle that too.
Good day,
I was wondering if there is a way to make Ajax move on to the next code segment only when all the elements included in the server-side code page are fully loaded. When the retrieved data is text-only there’s no problem, but sometimes there are photos included.
This is part of the code I have been using:
xajx.onreadystatechange = function(){
if(xajx.readyState==4){
document.all.div1.innerHTML = xajx.responseText;
document.all.div1.style.display = “”;
}
}
The thing is that when the response is retrieved (readyState set to 4) and div1 is displayed, the Photo has not been completely loaded yet, so actually the user can see the process of the picture slowly appearing, as he would in any other “normal” case. What I want to do is making div1 available for display only once all the components are fully loaded while meanwhile the system does its stuff in the background. Before Ajax I used hidden iframes like everybody, so I could enclose an onload event handler within the iframe tag (or in an external script), so div1 would appear only after the iframe has fully loaded, photos included.
Any idea?
You can use the 'onload' event on images themselves. You'll need to work out how to attach that event when you are downloading the code dynamically as in your case.