I've figured a weird issue with Wicket 1.5.x. All of the sudden, wicket started to append a number that increases to every url which looks like mydomain.com/home?1. For every Bookmarkable link I click, wicket sends a redirect to the browser increasing that number. Same happens for when trying to clean the url and calling mydomain.com/home I end up with another redirect and an increased number.
What's even worse is that on Google App Engine the version number when clicking a link increase by the factor of two which also seems to cause issues with submitting forms which simply do.. well.. nothing!?
I've tried to play around with setVersioned(false)/true and setStatelessHint(false)/true without any result. What could that be, how to get rid of it and how can it influence my app not working on GAE?
thanks a bunch
Alex
EDIT:
It looks like wicket is always incrementing the version for my page as my base page is stateful (shows user's name if any in a model). But nothing changes on the site yet clicking i.e. my Bookmarkable Link to my home site increases it's page id with every click so if the user clicks 10x times on the home link his history is polluted with 10 entries of the exactly same page as nothing has changed.. this doesn't make any sense at all so I am curious how to fix that without loosing being stateful!?
The number represents the version of the page. It appears when the page is stateful (thus the server must track its state).
It takes a little more than set the stateless hint to make a page stateless. You must avoid any component that holds state on the server side, and use stateless alternatives (StatelessForm instead of Form, StatelessLink instead of Link).
I answered this question with an example of a stateless page: Is it difficult to make a mainly stateless web application with Wicket?
There is a Jira ticket: setVersioned(false) should force single Page Version about this issue. The question has also been discussed in the mailing list. Expected complications: Page Reload on Submit of non-versioned Page
Related
I have a quick question , I created some test cases using chrome driver on a Friday , today I returned and all test cases have failed ,when I checked I see that all the elements ID's or xpaths have changed , My question is why did this happen? I also need to know does this happen often?
Thank you
Please Check your web pages which are used for testing,
Element ID or Xpath changes mainly due to the frameworks which is used for the web page development. (i.e) like ExtJS based applications will basically generate dynamic ids. So if any components/elements are added to the web pages, it will automatically re-generate their ids.
Please refer to this SO post.
My question is why did this happen? -- Possibly reason in this scenarios could be :
UI of Web Page has changed, so that your XPATHs are failing.
Your XPATH may contains alphanumeric characters(or may be too long absolute path), which is not a good web locating strategy. You may want to switch to different locators for stability.
I also need to know does this happen often? -- It can happen at any point of time. (Lots of Web applications are changing their user Interface to give good user experience)
The Application you are working is dynamic. everytime you refresh a page or sends some data to server, the dynamic element changes it attribute values. I recommend you go with dynamic xpaths. you will find many learning sites to break the ice!!
Hope this helps!!
This issue may have to do with a very specific Domino version (see below), so I start with a few technical details:
Server in question is a virtualized Windows 2008 R2 64bit machine. Domino release is
IBM Domino (r) Server (64 Bit) (Release 9.0.1FP4 HF70 for Windows/64)
The latest JVM security patch (9.0.1.4 dated 20150724) is installed.
I may be wrong but I feel that the issue started after we installed the latest patches (FP4 HF70 and JVM):
On an Xpage I have a very simple "Refresh" type button just triggering a partial refresh on an xp:panel (id="pnMainContainer") surrounding the bigger part of my page. Amongst other components there is a tabbed panel inside pnMainContainer. This is set to open with the first of three tabs upon loading the page.
Assuming that I have the third tab open, usually if I click the Refresh button tab #3 stays open, and its contents are freshed as expected.
Sometimes however, after I left the page open for a several minutes (can't really say how long, maybe somewhere around half an hour), the refresh obviously is returning to its initial state, showing the first tab instead of the one that was open before, and emptying all editable fields that were filled before.
When that happens I see the following warning appear on the console:
HTTP JVM: WARNING: CLFAD####W: State data not available for /myPage
because no control tree was found in the cache.
I am aware of this post here: Xpages document changing document mode?, and although I don't use Xagents in my application I tried setting my page's viewState property to nostate. This apparently didn't help solve the problem.
One more detail that might be helpful is the fact that the page in question makes use of a managedBean bound to the viewScope.
Any ideas what could be causing this, and - moreover - how to change this behaviour?
Update 2015-09-10: following #Paul's suggestions below I set my application's session timeout to 120 minutes last night (xsp.session.timeout=120). This morning I tried again: loaded the page in question then let it sit there for approx. 45 minutes. After that time hit my partial refresh button. Result: page is reloaded to its initial state, and server console is showing the same warning as yesterday.
For completeness sake here's the entire contant of my application's xsp.properties as it is at the moment:
xsp.error.page.default=true
xsp.library.depends=com.ibm.xsp.extlib.library
xsp.resources.aggregate=true
xsp.theme=oneuiv3.0.2
xsp.session.timeout=120
xsp.application.timeout=120
xsp.persistence.mode=basic
Is there probably something in there that would be causing this behaviour?
Some more details: did some more testing and found the following details:
with the above mentioned xsp.properties caching appears to be stable for quite a while as long as I let the pages just sit there
as soon as I make any kind of adjustments somewehere on my page or in related codes (SSJS libs, managed beans, or the page itself) cache needs to be rebuilt as the state of my page is lost (even after a few seconds). It doesn't matter at all whether "Build automatically" is turned on in Designer or not
Tried setting page persistence from xsp.persistence.mode=basic to xsp.persistence.mode=file. This results in a "java.io.NotSerializableException" as soon as I open tab #3 which makes use of internal properties of a managedBean that is registered at a viewScope level
Built a very simple app on the same server with just a few partial refesh buttons: result is that page state is never lost for pages from this test application
As long as the cache is lost only when I update design I don't really care. But I'm afraid that this might escalate if many users are starting to access the pages.
Anything else I could do to improve performance?
viewState="nostate" basically means don't store the component tree or scoped variables for this page server-side. That's why you use it for XAgents, which will never be partially refreshed.
The key data is:
1) How quickly the XPages session is set to timeout. Once that times out, you'll lose state data. I don't think keepSessionAlive control helps here.
2) Whether other tabs are being opened in the browser. There are other XPages properties that determine the number of pages stored in memory / disk. The maximum is stored for the whole browser session and, once you hit the maximum, the earliest is dropped from memory, hence the same message (and the other reason for setting nostate on XAgents.
It sounds like the first is the cause. Note that XPages session timeout and http timeout are separate timeouts. The first is when the state data for the current session is removed and is application-specific (because each XPages app has a separate runtime JVM), the second when a subsequent request to the browser will prompt for authentication.
I was wondering how to preserve an application when the user leave the application completly by going to another site (for example when the user logs into the application and then goes to nytimes.com and then comes back to the application some components go missing). To preserve the application on a refresh you can use the #PreserveOnRefresh annotation, but this does not preserve the application when you leave it. The header, menu and footer are disappearing. These three components are have their own class and are only declared in the main ui. Each view (or page) has its own class (which sit between the menu and the footer). Everything works fine until the user leaves the webpage and comes back the header, menu, and footer disapear So my question is how to preserve my vaadin application when the user leaves it and comes back?
Well, there could be problem with serialization and deserialization from session. Make sure you have implemented Serialization interface for your own classes.
Have you tried to repaint the missing components? They should be set to setImmediate(false) during repaintRequest.
Anyway, ordinary Vaadin application works without problem after returning back from other url. So good luck.
To solve this situation you can add a listener to the navigator which will get the uri to the page you are going to and check your permissions. If you do not have permission it will keep you on the same page and give you a notification saying that you are not allowed to go to this page. If they are allowed you will proceed to direct them to that page.
What components are missing when you go back to the application? Vaadin applicaction lives as long as web session. If I go to nytimes.com and then go back before the web session ends, the Vaadin application will survive (if it has #PreserveOnRefresh) or will be renewed
In my Java EE application page, I have header.jsp, a side menu.jsp, a body.jsp and footer.jsp. The side menu contains the jQuery dynatree plugin. When a user clicks a menu item from the tree, the body should be changed with the appropriate page (also a .jsp). I am using tiles framework, where I am importing all js code in layout.jsp page. I want to achieve an effect replicating a frameset, but without actually using a frameset. I think framesets are difficult to be managed and take time to load.
Can anyone suggest how I can approach this problem? If I use AJAX to fetch each page when dynatree node is activated, then I have to manually update the page. If I use an IFRAME in body.jsp, then I have to reimport all plugin js code as the frame will not be able to access js functionality on the main page.
I want efficient html page management.
Since you are using jQuery, you should be able to use AJAX in combination with the live method of applying events (see the docs or here). This method is called "event delegation", and even though jQuery will do it for you like magic, you should understand what is happening. Depending on what version of jQuery you are using, you might use delegate instead of live - essentially the same thing.
Framesets are actually deprecated in HTML5 -- you should avoid using them because soon they will not be supported at all in newer user agents. See http://www.useit.com/alertbox/9612.html for a lengthy discussion that should hopefully dissuade you from considering that approach.
The IFRAME approach is a hack. You might be able to make it work, but you're hammering a square peg into a round hole.
Bottom line, if you don't want to directly deep link to inner pages, AJAX is the best and preferred solution. In combination with event delegation, it really is superior to any older or hacky solution. And, be sure to use the idea of "progressive enhancement" -- if someone clicks those links and has javascript turned off, the content should still load. That means you start with regular direct links, then add the fancy stuff on to it for those users that have javascript enabled. Otherwise, you close a percentage of users off from anything past your home page.
When you use AJAX for your navigation, you still need to plan for a user that doesn't understand the difference between when they click a link on your site or any other site. They'll use the browser's "back" button and end up back at Google instead of on the last page! That's because their navigation through your site does not look like unique pages to their browser. There are tools in newer browsers to deal with this, but the details are a little beyond the scope of this answer. Check out this article on MDN for more info on manipulating the browser history.
Documentation
jQuery's live - http://api.jquery.com/live/
jQuery's delegate - http://api.jquery.com/delegate/
David Walsh on event delegation - http://davidwalsh.name/event-delegate
Jakob Nielsen on Framesets - http://www.useit.com/alertbox/9612.html
MDN on Browser History Modification - https://developer.mozilla.org/en/DOM/Manipulating_the_browser_history
jQuery for Designers blog with a sample use-case for delegate - http://jqueryfordesigners.com/simple-use-of-event-delegation/
Wikipedia article about progressive enhancement - http://en.wikipedia.org/wiki/Progressive_enhancement
For my particular project, I'm using Facelets (1.1.14), MyFaces (1.2.3), and Spring Web Flow (2.0.3). My IDE is JDeveloper 10.1.3.3. My browser is IE6 (work requirement).
Okay...ran into a very weird issue today. Normally, when I'm using Facelets, I can make whatever changes I want to my xhtml file, refresh my browser window, and see the changes immediately. I've got Facelets development set to true, and Facelets refresh period set to 1.
Up to this afternoon, I've had no problem with Facelets refreshes on this project. However, just this afternoon, I starting finding that changes to css styles and classes did not appear when I refreshed the page. Then I started seeing similar issues with other page elements. In some cases the changes never appear. At other times, I can refresh the page after a little while has passed and the changes have been reflected.
What happened to my Facelets page refreshes? It's like they've gone all sticky. I'm used to immediate changes on page refresh without complications. Has anyone run into this before? Any solutions or suggestions?
EDIT
The issue has something to do with Spring Web Flow. One of my pages is pure Facelets, and it's reflecting changes on refresh immediately. My other xhtml pages are invoked as view states in my flow definitions, and show the symptoms described above. Still, they were working fine just a day or two ago...
EDIT
Ok, I've been able to isolate the symptom, but I still don't know its cause.
It seems that whenever I have a facelets xhtml file that is rendered as a view-state of a flow and has an h:form element, then I get odd behavior when I make changes to the JSF elements on my page and refresh my browser. This includes not showing changes in their styles or style classes.
Changes to regular HTML elements (like changing the style of an input element) seem to work fine. Changing the h:form to a regular HTML form allow for immediate changes on page refresh, even on JSF elements. When I view the page when I'm not executing a flow (just using Facelets), then I never encounter any problems, even when using an h:form.
Please tell me someone has encountered this before, and has some solution. Anyone?
If you have entry of facelets.REFRESH_PERIOD -1 in your web.xml , this is causing the problem. Just cross check it by removing this entry.
I'm not sure if this applies to Web Flow, but I do know that with Spring MVC, you have an option of having your controller implement the LastModified interface, which allows Spring to send the browser the "Last-Modified" HTTP header.
Servlets typically don't set this HTTP header value, causing browsers to request a new copy of the files each time, however, if the "Last-Modified" header is set, browsers know not to retrieve the contents of a URL if it hasn't been modified since the page was last retrieved.
I suspect your Web Flow "controller" (pardon my abuse of terminology, I'm not familiar with Web Flow) is setting the "Last-Modified" header, while your regular Facelets page is not.
For what it's worth, I think setting Last-Modified is generally a good idea, unless your page is dynamic.