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.
Related
My JSP project is the back-end of a fairly simple site with the purpose to show many submissions which I want to present on the website. They are organized in categories, basically similar to a typical forum.
The content is loaded entirely from a database since making separate files for everything would be extremely redundant.
However, I want to give the users the possibility to navigate properly on my site and also give unique links to each submission.
So for example a link can be: site.com/category1/subcategory2/submission3.jsp
I know how to generate those links, but is there a way to automatically redirect all the theoretically possible links to the main site.com/index.jsp ?
The Java code of the JSP needs access to the original link of course.
Hope someone has an idea..
Big thanks in advance! :)
Alright, in case someone stumbles across this one day...
The way I've been able to solve this was by using a Servlet. Eclipse allows their creation directly in the project and the wizard even allows you to set the url-mapping, for example /main/* so you don't have to mess with the web.xml yourself.
The doGet function simply contains the redirection as follows:
request.getRequestDispatcher("/index.jsp").forward(request,response);
This kind of redirection unfortunately causes all relative links in the webpage to fail. This can be solved by hardlinking to the root directory for example though. See the neat responses here for alternatives: Browser can't access/find relative resources like CSS, images and links when calling a Servlet which forwards to a JSP
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
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
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
We have a Seam application that uses rich:effects in several places. They all worked fine until we decided to replace our old school menus with rich:panelMenu components.
At that point all the effects stopped working. It's clear that the inclusion of the rich:panelMenu items is the culprit, as the effects come back to life if we remove the menus from the header file (included in the main template, above the place where the body is inserted).
We're using Seam 2.2.0 GA with richfaces 3.3.2.SR1 and both rich:effect and rich:panelMenu seem to come from the same library. In both cases, the relevant javascript files seem to be included in the same order (judging by the script tags at the top of the page), and the only notable difference seems to be some additional local javascript segments the menu tags introduce.
The javascript error I get is this:
Effect[A.type] is not a constructor
Thanks in advance for any suggestions/pointers.
Are there other RichFaces componentes in that page? When you insert rich:panelMenu, it will trigger to load jQuery/Prototype over that page. Are you using another version of jQuery/Prototype for your old school menus?
Check which jQuery version are you using. Open Firefug console (Firebug is an extension to Firefox) and write this (with and without rich:panelMenu):
jQuery().jquery
Another option: maybe your JavaScript's menu is overriding some JavaScript from jQuery/Prototype (used by rich:panelMenu).