I have a Java application using the Apache Wicket 6.x; sometimes exception StalePageException is triggered as described below and shows up in the log. However, because there is no feedback to the user, the application behaves unexpectedly causing frustration.
How can I capture the StalePageException and present a message to the user (preferably using a feedback panel) explaining the situation?
Open a stateful page in a tab/window, then copy the url from the
address bar and open it in a new tab/window. Then go back to the first
tab/window and try to click on any stateful link. This will lead to
StalePageException.
It is thrown because Wicket detects that the same page instance has
been rendered between the render of the current page and the click on
the link. Wicket does this because it is not sure whether there are
any changes in the page tree hierarchy between the initial rendering
and the click event. It is even possible that this link is no more
existing in the last version of the page, so this click could lead to
ComponentNotFoundException if StalePageException is not thrown
earlier.
StalePageException just leads to render of the current page. So the
user will see the last version of the page and (s)he will need to
click the link again.
You need to use custom IRequestCycleListener (extend from AbstractRequestCycleListener).
Override #onException() and if the passed exception is StalePageException then you may use Session.get().error("...") to report that to the user. Just make sure you have a FeedbackPanel in the current page.
Would you wanna try a rather simpler approach by capturing the exception instance (lets say e). Then check for the type of this excception. And eventually use one of the inherited methods from java.lang.Throwable to capture the details
if(e instanceof StalePageException ){
e.printStackTrace(); //can use other methods as per desire : getCause, getLocalizedMessage, getMessage, getStackTrace, initCause, printStackTrace
}
Please verify if getting the exception instance is possible for you to highlight in your code.
Related
GXT 3.x only.
Could someone analyse and explain the connection between the three private fields in FileUploadField?
Specifically,
where is the onclick action of the button that would trigger fileinput display? If not where, then how.
How does the fileinput.getValue() get transferred to the text input widget?
If you could answer the above questions, you should be able to answer this one ... (but please don't answer this question if you do not provide answers to the above two questions). Is the following statement true, somewhat true or incidental?
GXT has deliberately made it impossible to trigger button onclick programmatically because Security Concerns should not allow the file input element to be triggered programmatically.
If that is true, (why?) I could still access the button and fileinput elements programmatically, anyway. There's no stopping me or anyone.
EDIT
OK, never mind item 2: fileinput value is transferred to text input at onChange method.
There is none. There is a <input type=file> painted invisibly over top of the 'real' button. When you click on this, the dialog comes up - the click 'hit's the <input type=file> instead of the button, but onBrowserEvent tells the button to behave like it was clicked anyway. As far as I'm aware, this is the only way to gain access to the file system (i.e. the "Choose a file") provided by the browser (at least that supports browsers without the new file api, or flash or another plugin).
The <input type=file> exposes access to the name (which may or may not be complete or even real) to the javascript on the page. This is, as you note, available in a DOM change event from the input itself. Only the file name is available (again, without the file api), and it might have a fake path (i.e. IE) or no path (everyone else).
This is not a security concern that GXT has anything to do with - instead the rube-goldberg layout of the dom of the field is to deal with the browser's security limitations. Using private on the <input> is just making it clear that you shouldn't be access it directly, and does nothing meaningful to prevent you from reading it. If you subclass this, go after getFileInput(), otherwise, use JSNI and the so-called violator pattern to grab a reference to the file field or that method.
Yep - this isn't about security, this is about writing maintainable code. See also https://stackoverflow.com/a/2954949/860630.
I am using a JFormattedTextField for to format integer input for a Swing app. The default behavior for invalid input is to quietly (i.e. no error message) reset the text field to it's prior value. I want to display an error message with JOptionPane before returning focus to the JFormattedTextField.
My original solution was to implement FocusListeners for my text fields. I considered adding instances of the same FocusListener subclass to each one, but have encountered problems since I am using the NetBeans GUI Builder. #HovercraftFullOfEels suggested that I use an InputVerifier. I have implemented the following custom InputVerifier:
public class ValidTextFormatInputVerifier extends InputVerifier {
#Override
public boolean verify(JComponent jc) {
return ((JFormattedTextField)jc).isEditValid();
}
}
While looking into this further, I get the impression that JFormattedTextField uses InputVerifier internally. (I haven't found this explicitly stated anywhere yet, though.) Because of this, my custom InputVerifier seems superfluous.
The bigger issue is that the text field is still reset silently without any error message. I could add a call to JOptionPane.showMessageDialog() here. However this does not seem an appropriate place to display error messages. The InputVerifier does not know the exact nature of the invalid input, nor does it know the format of valid input, which is even more crucial to providing a meaningful error message.
The first solution that comes to mind is to add a constructor which takes a String parameter that contains the error message to display. This seems like I'm putting the error message logic in the wrong place, though.
Is there a common Java idiom for error handling and providing messages to the user? How do you suggest that I design my application to cleanly display error messages? Also, if I decide to design an interface for the software using a different platform (e.g. command-line, mobile, etc.), I want to be able to reuse as much of my existing code-base as possible. (Of course, since this is mostly a UI issue, perhaps that requirement doesn't apply as strongly as I would like here.)
My first opinion is that showing a JOptionPane to the user whenever the text field focus is lost could be very annoying for users. I would display an error message when the user hits the OK button of your form. The error message could contain a list of all error messages or only the first one and focus the element with the error.
Another choice would be to use regular JTextField and write your own custom validators. When focus changes, your IntegerValidator (or other implementation) would validate the input string and the UI could display an error or warning icon next to the field, the same as some web applications do.
I'd have a look at JLayer (Java 7) or JXLayer (Java 6 & below)
This would allow you to decorate the field or form with a verity of different states.
As to when.
I'd start by using some kind of highlighter, Dan suggest using icons, which is a great idea, coupled with JLayer/JXLayer this would reduce the overall effect on the form.
I'd wait until the user tries to submit the form before displaying a dialog & forcing focus back to the invalid fields.
The basic idea would be to allow the user the freedom to move about the form without to much restriction (cause not all people think in a linear manner) but encourage them to correct any possible errors they are producing along the way without having to wait till they submit the form to find the errors (think about the worse web form you've ever used and don't do that)
Obviously, if they try and submit the form with errors, you'll want to display and error message and highlight the first offending field
For examples of JLayer/JXLayer have a look at Validation overlays using JXLayer & How to decorate components
If by mistake user presses the F5 OR
refresh button after login , he should stay on the same page. Right now he is
redirected to login page.
I have used following code to stay on same page.
But I would not like to warn the user on this situation by writing
event.setMessage() in onWindowClosing() method. I just want to make
functionality which will feel the user that nothing has happended even
if by mistake he done browser refresh.
I am looking to avoid unwanted pop-up given by [OR HOW TO HANDLING EVENT ON CANCEL MANUALLY OF CREATED POPUP SO THAT WILL NOT RELOAD i.e. of com.google.gwt.user.client.Window.confirm("Do you really want to exit?")]
Window.addWindowClosingHandler(new Window.ClosingHandler() {
#Override
public void onWindowClosing(ClosingEvent event) {
//how to prevent sending reload request OR [on cancel button MANUALLY]
}});
In some comments above Activities and Places were mentioned as a solution for your problem. And of course it is a nice and modern one. You will find more details on GWT's documentation for these.
But if you do not want to go down that road, another solution is to use the history mechanism provided by GWT. Each "page" (rather part) of you application shall have a specific token. All you have to do then, is to create a History change handler and render the appropriate objects according to the token passed by the user's reload action. If you want to have some "memory" between user's log-outs (but not browser restarts) you can save this token in local storage and use it after user's log-in to direct her to the last page she was at.
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've got a very curious problem in Hibernate that I would like some opinions on. In my code if I do the following:
Go to page A
Click a link on page A to be taken to page B
Click on data item on page B
Exception thrown
I get an error telling me:
failed to lazily initialize a collection of role: XYZ, no session or session was closed
Fair enough. But when I do the same thing but add an alt+tab in the middle, everything is fine. E.g.
Go to page A
Click a link on page A to be taken to page B
Hit ALt+Tab to switch to another application
Hit ALt+Tab to switch back to the web browser
Click on data item on page B
Everything is fine.
I'm a little confused as to how switching focus from my application makes it act as I want it to. Does anyone have any light to shine on the subject? I don't think it's a locking issue as even if I do the second set of steps quicker than the first, still no error.
It's a Seam application using Hibernate 3.3.2.GA & 3.4.0.GA.
It's not really related to switching the applications; maybe your browser updates something during focus lost/gained.
The reason for your issue is this:
In the first request, you load an object and store that in the session. This object contains a collection of some kind.
In the next request, you try to do something with the collection but you forgot to call session.refresh(object), first.
What happens is that the session is automatically closed when the first request is finished. But the backed collection in your object still contains a reference to it (so that it can be loaded automatically when you access it for the first time).
are you using javascript? Maybe an event is firing when you switch back to the browser that somehow clears the bad state?
Does your page complete it's rendering? I have found that sometimes when I get errors, instead of displaying the error, the server simply quits producing output. It outputs the error to the log, but thats about it. I end up with a half completed page. View source and see if you get to the end of the body, perhaps your switching caused the server to get lazy, or your browser to terminate the connection prematurely when the error occured
My advice is to do a unit test to see if you can reproduce the error in other environment isolated from the browser ;)