I have an overridden GWT DialogBox that has as a widget overridden PagingScrollTable.
I have something like this in my code:
1) DialogBox dialog = new ...
2) dialog.center();
3) Window.alert("Hello");
In IE I would see alert after loading of table’s header but before loading of table’s content (about 1000 rows). But javascript is single-threaded language so how can it be?
May it be a browser issue or issue of my code?
Thanks!
Javascript may be single-threaded, but the browser isn't, and page rendering is not done by the Javascript engine, so there's no conflict that Javascript can be running while the page is rendering.
(in fact, you can add the async attribute on the <script> tag to tell the browser explicitly to do this, although sadly this attribute isn't fully supported in all browsers yet)
Javascript is asynchronous (and it runs inside a thread in the browser so it's not in lock-step with the page loading the way you might think it is. Once the javascript itself is loaded, it need only be triggered by an event to run, or, the fact that it's loaded is enough to run it. '' tag contents are processed by the browser instantly - so if you have code that isn't wrapped in a 'function' that you bind to 'unload' or something similar - it'll just run whenever it shows up in the DOM.
Related
I'm having problems loading my page with webdriver. My current (problematic) solution involves using the unstable load with firefox, but I'm open to other solutions.
The Core Problem
The root of all my problems comes from the fact my page will never fully load when I call it normally with webdriver, and thus will never preform the 2nd step, it's just always loading. It loads fine when you just go to the site with a normal browser. I've tried out a few work arounds that work intermittently, including opening the driver to google, and then going to the page which sometimes makes it load, and with
IJavaScriptExecutor js = (IJavaScriptExecutor)Driver;
js.ExecuteScript("return window.stop");
as suggested by this question, which sometimes makes it continue without loading. But neither of those work consistently at all (probably <50% of the time)
The best I've got so far is using the unstable load strategy. However that has its own different problems, all of which only happen sometimes.
1) Sometimes it doesn't wait for the page to load at all, and I get an "Unable to locate element:" exception within milliseconds of loading the page, despite the fact that I have a wait set up:
new WebDriverWait(cdriver, 30).until(ExpectedConditions.visibilityOf(cdriver.findElement(By.id(myId))));
Thread.sleep(3000); solves that problem, but I've read that is a sloppy way to do things.
2) If I get passed that step, my test should click one link, then click another and continue on with the test. However, it often gets stuck after that first click. So if my code is like this:
Thread.sleep(3000);
element1.click();
System.out.println("clicked!");
element2.click();
The first click (which doesn't load a new page, by the way, just a pop up on the same page) will work, but then the system will never print out "clicked!", it's stuck in the same way would be loading the page initially (without the unstable load thing). If/when it makes it over that hurdle, I think the rest of the test is fine.
Any ideas 1) why it works sometimes but not others. 2) how to fix it 3) how to just get my page to load in the first place
Thank you!
Try the following approach:
Don't wait for visibility of element on the page - in your case By.id(myId).
The element can become visible much earlier than the page is fully loaded, before all java scripts are loaded and fired etc.
Wait for some element on the page to be clickeable instead. For example you can wait until link becomes clickeable in this way:
By locatorOfLink1 = By.xpath(....); // By.id, By.name, By.linkText etc.
wait.until(ExpectedConditions.elementToBeClickable(locatorOfLink1));
If the above will not help for problem #2 (the webdriver gets stuck after the click), then send ENTER key to the link instead of the click:
element1.sendKeys(Keys.ENTER);
How can i get the page URL in single-approver-definition.xml in the e-mail template that is used to send an e-mail to the content creator once the reviewer approves or rejects the submission. The existing xml is as follows:
<template>
Your submission has been reviewed and the reviewer has applied the following:
${taskComments}.
</template>
I tried ${serviceContext.getAttribute("contentURL")} and it didn't work.
I want to be able to do - Your submission for ${pageURL} has been reviewed and the reviewier has applied the following: \n ${taskComments}.\n
Any suggestions will be appreciated.
I don't get what variable exactly you want to process in your notification. As I can only assume, you are using it for Web Contents and all interesting variables are stored in two places.
Workflow context variables - they are available directly. Few examples like:
${taskComments}
${entryType}
${userId}
${userName}
...
ServiceContext variables - they are available using $serviceContext. Few examples:
$serviceContext.getAttributes().get("version")
$serviceContext.getAttributes().get("articleId")
${serviceContext.getPortalURL()}
...
For all interesting variables check this url https://www.liferay.com/web/igor.beslic/blog/-/blogs/workflow-in-action-kaleo-workflow-context-variables Some could change already, however most of them is working fine for current version.
Content changes might be made on a page, they can also be triggered through Control Panel (or the API for that matter). When you're in a workflow, you typically don't have this context any more - if you find it somehow I'd not rely on it to be there. A workflow is unrelated to the UI and pages.
Also, an article might be submitted on one page, where it might be replaced/removed before it's even approved. In that case the link wouldn't help.
What might work is to check the concept behind "Web Content Display Pages" (if your article has them configured and you deal with web content). But the mechanics will vary depending on the actual content type you're dealing with. And content that goes through workflow might not be displayed on any page at all (e.g. when submitted through Control Panel) or on many different pages (either explicitly - Web Content Display - or implicitly - Asset Publisher).
#tomic basically provides pointers to what you have, I'm only reasoning why your initial problem is problematic to solve at best - it's not fully specifiable.
We pull data from server and for that If we are using Struts, then we can pull either by submitting a page which MVC Architecture or we cam make an AJAX call but conventions is of using forms and render response but we also face challenges to give rich user experience, so we compromise convention and start using excessive AJAX, so how we should make balance between two?
I personally think that AJAX should be used for displays updates and form submissions should be done via a page reload. Reasoning?
When submitting forms, you are telling the application to do something. Users tend to want to feel that it was done. When a page doesn't reload, users are often left wondering "Did that work?". Then they have to check to make sure what they did was right.
On the other hand, when you are displaying a chart or something, and the user says to "display 2011 data....now 2012 data" for instance, they aren't "doing" something (creating new entities, sending emails, etc). So AJAX can provide a nice user interface in this case. Page reloads would be annoying here.
In conclusion, I think form submission should be done via page reloads (let the user see it working), whereas display updates should use AJAX (prevent annoying page reloads).
Of course, this is a preference thing. Some of my company's applications use AJAX all over. But those are the applications that are the most difficult to maintain and debug. ;)
Regular old HTML form submission and fancy ajax forms are not mutually exclusive.
First, make the plain HTML form work correctly. Then, add javascript to hijack the form and send an ajax request.
The controller and model don't care if the user's browser supports (or has enabled) javascript. The rendered view is decided by whether the call was made with javascript or a simple form submission. This is one of the strengths of the MVC pattern, not a constraint.
I think that the choice between the two is somewhat intrinsic:
a form submission is synchronous and it reloads the page.
an ajax call is asynchronous and it does not reload the page.
If a certain action will change a lot of UI elements or needs to poll a lot of data to be rendered, I would go with form submission. On the other hand, if a certain action is used for simple actions, like populating a select box or improving user experience, then I would go for an AJAX call.
There is nothing avoiding you to use as many ajax calls or form submissions as you need, so in the end is up to you.
In this day and age, there is virtually no case to use the old standard HTML form submission method (other than pure nostalgia, or perhaps not knowing).
The <form> tags themselves can still be useful if you want to take advantage of the .serialize() function (which grabs all name-data pairs within the form into a query string), but other than that we don't need to use <form> tags at all these days.
Using AJAX, the developer has more control over the entire process, in a more condensed code base. But more importantly, we just don't do things that way anymore.
Consider:
(Old Style - Forms) When an HTML form submits: (a) it gathers the form field name= attribute values (these become the defacto variable names) (b) together with user-entered data in the form fields (which become the variable values), and posts these data-pairs to a PHP file (as specified in the action= attribute on the form tag). THEN, the page changes to that other page, causing a noticeable refresh of the screen and loss of all previously inputted user data. Even using the trick action="", wherein the form data is posted back to the same page it started from, the page is still reset/refreshed.
(New Style) Exactly the same process can easily be programmed using javascript/jQuery - except that the page does not refresh. All previously entered user data/text can remain undisturbed.
Back to your question:
With the old-style HTML form submission, the page changes - so if you want to do field validation you use javascript/jQuery to cut into the submit process, thus:
$('myform#btnSubmit').click(function(){
var some_fields_failed = false;
//check form field values here, set: some_fields_failed = true
if (some_fields_failed){
return false; //halts the HTML Form Submit process and returns control to the user
}
});
in which case you already are using most of the AJAX construct that would replace the HTML form submission process.
This simple introduction to AJAX provides some compelling reasons to use AJAX instead of the old-style HTML Form Submission process:
AJAX is a developer's dream, because you can:
Update a web page without reloading the page
Request data from a server - after the page has loaded
Receive data from a server - after the page has loaded
Send data to a server - in the background
Note that you can write ajax code in pure javascript, but until very recently it was considerably simpler (much less typing, more consistent) to use the jQuery (javascript) library. Hence, all examples above use jQuery. To include jQuery in your project, it is only necessary to include a reference to the jQuery library:
<head>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.2.4/jquery.min.js"></script>
</head>
StackOverflow maven, Schabse Laks, created a simple jQuery tutorial that is worth stepping through (IMPORTANT: Use Down Arrow to step through the pages)
If you have errors between submissions of data the only forms method you could check on the server. On the other hand if you make Ajax calls you could check that errors on the client side. So, out of this different technologies of transmitting data we could follow a decision that they serve different purposes.
When sending a form with AJAX, you generate the POST request and not the browser, so you have more control over it. Even if you don't need that control to begin with, in time it might become necessary.
One case would be protection against CSRF attacks on forms. It can be implemented by adding a hidden form input field containing a CSRF token, which is sent together with the form data. But a preferred implementation would be to add a custom header to the submitted POST request. However, you can't do the latter when using the old form submission method - the browser composes the request and you can't add your own headers.
Whenever there is an error during the load of a JSF facelet, JSF stops rendering the page at the point of the error and shows the error page instead (default behavior). I want JSF to continue rendering a page instead and show the exception/error within the page. For example if the page is loading a "portlet", which throws an exception, that exception would be shown as text within the portlet. I don't want the whole page to be forwarded to a separate error page.
I have initialized my own ExceptionHandlerFactory and ExceptionHandler implementations and I can iterate over the ExceptionQueueEvents succesfully. However, I don't know how to instruct JSF to continue loading the page despite of the error. Is this even the right approach at all? Is the ExceptionHandler called after (as I suppose) or in the middle processing the facelet? If after, is there anything I can do within my ExceptionHandler?
I know I should:
Hide the parts that user cannot access (my specific case relates to security, when user tries to load content he does not have rights to. However, I am looking for a global answer to this)
Manually handle the errors so unexpected exceptions would not be thrown
However, I want the user to be able to continue using the system despite of some minor component failure (for example if some newsfeed portlet throws an error that shouldn't prevent the user from seeing other content and using it).
I am using Mojarra 2.0.2. I feel this is a very simple to solve but I cannot figure it out :(
If your page has separate content, consider using (i)frames. This way, if some particular content fails to load, the whole page would still render, but that frame would show the error page. This of course implies that all your separate components are full html pages.
BalusC is absolutely correct that you should NOT try to handle any parsing exception etc. Oddly rendered page segments are not user friendly, and can lead to very bizarre results.
If you have roles/rights issues, those scenarios should be maintained separate from jsf rendering. Authorization should be confirmed before forwarding to a page, not while attempting to render it.
Doing so would mean that you're giving the enduser a halfbaked HTML page (because JSF hasn't (and can't) complete the HTML rendering) and it's unspecified how the webbrowser would display the page.
Don't do it.
I searched for it a lot but probably I am searching wrong strings. A Java applet is feeding live bits into my pages, java applet accesses the input fields on my page and places the information
<input type="hidden" id="F1" value="Nothing Yet">
and then it calls a javascript functionon the page say LivePicker() and then it simply picks up a value
var ClockVal = document.getElementById("F1").value;
document.getElementById("ICSCLOCK").innerHTML = ClockVal;
The problem I am facing is, this works fine but sometimes in firebug console it give errors like LivePicker is not defined, while LivePicker would be working perfectly fine on the page while sometimes it will give F1 is not defined, while my clock would be working fine. All of these errors appear at page load.
Java applet places the data sequentially, it first place the data and then calls the js function to process it. That works perfectly fine on test pages with minimum HTML and JS but when I integrate it to my application, which uses a lot of components from YUI and a lot of my own JS code (which is now minified obviously), it give these errors. One thing I would like to add, before minification, these errors were a lot likely but after minification of JS and CSS, the page load time is reduced to half and the appearence of these errors are reduced to half as well.
I am suspecting this is due to, on page load, applet tries to manipulate the DOM which is not ready yet. Is there anything, which could stop the applet to wait until the DOM is fully loaded? I tried window.onload and onDOMReady function of YUI, they seem to make no effect at all.
Can any one help please?
you could try using setTimeout to delay execution
https://developer.mozilla.org/en/DOM/window.setTimeout
or the jQuery library could also help out with the ready event on the document object
http://docs.jquery.com/Events/ready#fn
The browser should delay executing the window.onload code until after
the DOM tree is created and after all other external resources are fully loaded and the page is displayed in the browser.
The window.onload should work. Your applet must be running before the onload event.
As a test, can you do the following and see if it changes anything:
create a hidden "set" field in the page with value "false";
on window.onload set the value for the "set" field to "true";
in your applet check the "set" field;
only start doing things in your applet if the "set" field is defined and has a value of "true";
One other thing, don't do a busy waiting in your applet to test for the "set" field. Your applet should take no action if the field is undefined or false. You can reactivate it on window.onload if needed.
This problem was resolved using dpb suggestions in slightly different way. This blog post I wrote should explain every bit to those who are facing similar problem.
Controlling Java applet from Javascript especially if you make round-trips to the web page from applet