The PrettyFaces team is pleased to announce the release of PrettyFaces 3.3.0. PrettyFaces is an OpenSource Servlets extension with enhanced support for JavaServer Faces – JSF 1.1, 1.2 and 2.0 – enabling creation of bookmark-able, pretty URLs. PrettyFaces solves the “RESTful URL” problem elegantly, including features such as: page-load actions, seamless integration with faces navigation, dynamic view-id assignment, managed parameter parsing, and configuration-free compatibility with other web frameworks.
Features & Enhancements:
- Performance improvements when running JSF 2.0 in project stage ‘development’
- Regular expression performance improvements provided by Yann Simon.
- Ambiguous View IDs are now resolved automatically when using pretty:mappingIds in action method navigation, <h:link> and <h:button> component outcomes
- Ambiguous View IDs may now be resolved manually for outbound URL rewrites by adding ‘?com.ocpsoft.mappingId=…’ to URLs before calling HttpServletResponse.encodeURL(…)
- Dynaview URLs* are now resolved during rendering of links and navigation cases, and are now as functional as traditional mappings.
- Fixed bug that caused path parameter validators to be ignored (#102)
- Handle java.lang.ClassFormatError during initialization of bean name resolvers (#101)
- Also check Weld 1.1.x specific servlet context attribute while search for BeanManager
- Mapping inheritance now working correctly for mappings using the same viewId
– Previously, DynaView URLs would only function on inbound requests, and once the method was evaluated, the value would be processed and then abandoned. For example, when rendering <h:link /> components, users would actually see the dynaview method definition rendered as their url! That is not a good experience, so in resolving the problem, we simple evaluate the dynaview method a second time (or as many times as necessary) in order to render the desired link target. And we do this using…
I was recently asked the question, “Is it possible to create a modular JSF application, where JAR-files act as plug-ins and allow xhtml views, images, css, navigation rules, and managed beans to be added as modules to the application?”
The answer to this question is, “of course
,” but there is no pre-set way of accomplishing such a task, so you’ll have to be a little creative. I’ve come up with a conceptual architecture that “would work,” if properly implemented, but keep in mind that this is just something I threw together in a few minutes of thinking about the problem.
It is amazing what can be done in exactly one year’s time. January 17th will have been the 2nd anniversary since Lincoln Baxter and I started OcpSoft. It’s been one seriously fun, and wild, ride with JavaServer Faces
and the open-source community. I want to take a moment to talk about my partner’s success story and what he has accomplished in just one
JSF2 is an amazing web-framework, and as part of our initiative to engage the community, Dan Allen, Andy Schwartz, Kito Mann, the rest of the Expert Group, and I have been putting together a “JSF Root Node” (as Ed Burns put it.) A website to be the first place people go to when they think of JSF.
So, a little while ago I was attempting to use JSF’s Facelets <ui:repeat> tag, as a replacement for <h:dataTable>, but difficulty came when I needed to process actions on individual records of each row.
<ui:repeat> allows iteration over a List of Array of items, but it does not provide a method of discovering the “selected” or “actioned” row; there’s no way to discover the row the user is interacting with. Or is there?
So, one of the best ways I know of to tell a user that they should be waiting for something to finish, is by setting the cursor to ‘wait’. It’s how desktop applications do it. It’s how the operating system does it… it’s how ajax should probably do it (if you want to solve the user wait interaction globally.)
With JSF2, it’s easy to accomplish!
If you are manipulating any FacesContext when doing any kind of Sevlet Forwards – such as from a filter
– you MUST release() any FacesContext you’ve created. The consequences of forgetting this are potentially dire.
So you’ve got Spring Security up and running. Great! Now you’ve got a login page, and you just added a form on the global page menu to allow users to Login from any public page. There’s just one problem. When they log-in from a public page, they’re redirected to the default-login-url! Your users will have to re-navigate to the page they were already viewing when they logged in, or maybe they’ll just use the much dreaded “Back” button. That’s not a good interaction, but we have a solution.
Several things that make life painful with Facelets are fixed with JSF2 & EzComp
. Take a look at some of the nicer things to come:
A correction has been made to the post: http://ocpsoft.com/java/acegi-spring-security-jsf-login-page/
, fixing an issue where FacesMessages were not being displayed on failed authentications.