Looking for real-world experiences:

• How has PrettyFaces helped you or your team?
• What would you change if you could (you can)?
• If you would like to share, show us your work of art!

Email to: lincoln@ocpsoft.com

Thank you!

PS – In addition: If you’d like to be added to our new “People using PrettyFaces” page, also send a logo and a short description of your product or company!

A new version of PrettyFaces for JSF1.1 (historical support) is now available for download. This version is feature-complete, but we are looking for feedback on compatibility and functionality that may be broken with various implementations, so please post comments!

It should be noted that JSF is now on version 2.0, and PrettyFaces 2.0.x should be used. E.g: PrettyFaces 1.2.x should be used with JSF 1.2.

1.1.0: jar, src

New versions of PrettyFaces for JSF1.2 and JSF2.0 are now available for download:

1.2.4_GA: jar, src

2.0.1_GA: jar, src

Minor Release: 20090613

1. Fixed non-redirecting faces-navigation integration.
2. Enhanced null handling for mis-configured viewIds
3. Now supports browsers with cookies disabled

Version 1.2.3_GA: binary, source, documentation (stable)
Minor Release: 20090415

1. Added optional <action onPostback=”false”> boolean flag to prevent action methods from being called on form postback. Defaults to true;
2. Added optional <query-param decode=”false”> to prevent java.net.URLDecode.decode() from being called on a specific managed query-parameter. Defaults to true;
3. Added unit tests for several critical classes.
4. Minor to moderate refactoring of PrettyFilter/PrettyContext

Version 1.2.3_RC2: binary, source, documentation (stable)
Minor Release: 20090331

1. Servlet forwards are working

Version 1.2.3_RC1: binary, source, documentation (stable)
Minor Release: 20090319

1. Managed query-params now accept multiple parameters of the same name: E.g.: String[] names — would accept a list of parameters (with the same name) from the request
2. Enhanced configuration loading — PrettyFaces now looks for /META-INF/pretty-config.xml by default, in addition to accepting a comma-separated list of user config-files in the web.xml init param: com.ocpsoft.pretty.CONFIG_FILES — submitted by Aleksei Valikov
3. JSP support for standard attributes on the pretty:link tag has been fixed. The pretty link will now accept style=’mystyle’ and other attributes — from Derek Hollis at OcpSoft

Setting up PrettyFaces is simple.

0. Get PrettyFaces.

This step is pretty straight-forward, right? Extract necessary JAR files into your /WEB-INF/lib directory, or include a maven dependency in your pom.xml

<dependency>
	<!-- For JSF1.1 -->
	<groupId>com.ocpsoft</groupId>
	<artifactId>ocpsoft-pretty-faces</artifactId>
	<version>1.1.0</version>
</dependency>
<dependency>
	<!-- For JSF1.2 -->
	<groupId>com.ocpsoft</groupId>
	<artifactId>ocpsoft-pretty-faces</artifactId>
	<version>1.2.6_RC1</version>
</dependency>
<dependency>
	<!-- For JSF2.0 -->
	<groupId>com.ocpsoft</groupId>
	<artifactId>ocpsoft-pretty-faces</artifactId>
	<version>2.0.2_GA</version>
</dependency>

1. Add the <filter> and <filter-mapping> to /WEB-INF/web.xml

PrettyFilter does most of the work. Without it, not much would happen.

<filter>
	<filter-name>Pretty Filter</filter-name>
	<filter-class>com.ocpsoft.pretty.PrettyFilter</filter-class>
</filter>
<filter-mapping>
	<filter-name>Pretty Filter</filter-name>
	<url-pattern>/*</url-pattern>
	<dispatcher>REQUEST</dispatcher>
	<dispatcher>FORWARD</dispatcher>
	<dispatcher>ERROR</dispatcher>
</filter-mapping>

2. Create the /WEB-INF/pretty-config.xml file

This is where you will map URLs to Faces Views. Read on for details.

<pretty-config
	xmlns="http://ocpsoft.com/prettyfaces-xsd"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://ocpsoft.com/prettyfaces-xsd 
	http://ocpsoft.com/xml/ns/prettyfaces/pretty-1.0.xsd">
	<url-mapping id="login">
		<pattern> /login </pattern>
		<view-id> /faces/login.jsf </view-id>
	</url-mapping>
	<url-mapping id="home">
		<pattern> /home </pattern>
		<query-param name="displayWelcomeMessage">#{homeBean.displayWelcomeMessage}</query-param>
		<view-id> #{homeBean.getViewPath} </view-id>
	</url-mapping>
	<url-mapping id="viewStory">
		<pattern>  /story/#{myBean.currentStoryId}/  </pattern>
		<query-param name="commentText" decode="false">#{myBean.commentText}</query-param>
		<view-id> /faces/story/viewStory.jsf </view-id>
		<action onPostback="false">#{myBean.loadStory}</action>
	</url-mapping>
	<url-mapping id="viewComment">
		<pattern> /story/#{myBean.currentStoryId}/#{myBean.commentId} </pattern>
		<view-id>/faces/story/comment.jsf</view-id>
		<action>#{myBean.loadComment}</action>
	</url-mapping>
</pretty-config>

Url Mappings

Each <url-mapping id=”"> must specify a unique id. And contains the following attributes and elements, in order:

1. <pattern>/blog/article/#{someBean.paramName}</pattern>

   Specify the pattern for which this URL will be matched. This element is required, and has a multiplicity of 1 (only one)

   Any EL expressions #{someBean.paramName} found within the pattern will be processed as value injections. The URL will be parsed and the value found at the location of the EL expression will be injected into the location specified in that EL expression. Note: EL expressions will not match over the ‘/’ character.

   The pattern itself is compiled parsed as a regular expression, meaning that the actual URL matching can be as simple or as complex as desired.

   If further custom URL parsing is required, it is recommended to do this manually via an Action Method: See custom parsing.

2. <query-param name=”key”>#{someBean.queryParamValue}</query-param>

   Defines a managed query parameter of the form http://site.com/url?key=somevalue, where if the parameter exists, the value will be injected into the specified managed bean. This also handles JSF commandLink and AJAX <f:param> values. This element is optional, and has a multiplicity of 0…N (zero or more)

   Attributes:

   1. name — String, required. This is the request value key
   2. decode — boolean, optional (default true), if set to false, this query-param will not be URLDecoded (see java.net.URLDecoder)

3. <view-id>#{someBean.methodName}<view-id>

   Specify the JSF ViewId displayed by this mapping, by either calling an el Method (must return an object for which the toString() method will return the view Id) or by returning a literal String value. This element is required, and has a multiplicity of 1 (only one)

   The ViewId may be any resource located within the current Servlet Context: E.g. PrettyFaces can also forward to a non-Faces servlet.

4. <action>#{someBean.methodName}</action>

   Specify an action method to be called after URL parameters have been parsed and assigned into beans. This element has a multiplicity of 0…N (zero or more)

   Attributes:

   1. phaseId — String, optional (default RESTORE_VIEW) if set to a valid JSF PhaseId, the action will occur immediately before the specified Phase. (see javax.faces.event.PhaseId)

      Valid values for this attribute are: RESTORE_VIEW, APPLY_REQUEST_VALUES, PROCESS_VALIDATIONS, UPDATE_MODEL_VALUES, INVOKE_APPLICATION, RENDER_RESPONSE, ANY_PHASE.

      Note however, that if the phase does not occur, neither will your action method.

   2. onPostback — boolean, optional (default true), if set to false, this action method will not occur on form postback. (see ResponseStateManager.isPostback())

Order of processing:

1. URL pattern parsing, query-parameter handling, and value injection into JSF managed beans.
2. View-Id calculation (if a view Id is dynamic, the el method will be called.)
3. JSF gains control of the request via RequestDispatcher.forward(“/context/faces/viewId.jsf”).
4. Action methods are called before RESTORE_VIEW phase, unless the optional phaseId attribute is specified.

Config Loading:

At application startup time, before any requests are processed, Pretty Faces processes zero or more configuration resources, located according to the following algorithm:

1. Search for classpath resources named META-INF/pretty-config.xml
   in the ServletContext resource paths for this web application, and load each as a configuration resource.
2. Check for the existence of a context initialization parameter named com.ocpsoft.pretty.CONFIG_FILES. If it exists, treat it as a comma-delimited list of context relative resource paths (starting with a /), and load each of the specfied resources.
3. Check for the existence of a web application configuration resource named /WEB-INF/pretty-config.xml, and load it if the resource exists.

3. Advanced Features

3.1 Using Dynamic View ID Capabilities

Dynamic view IDs allow a mapped URL to display content from any JSF view. This is prevents doing redirects which would otherwise destroy information stored in the URL, and also provides some extra functionality for application design.

This pretty-config mapping uses a dynamic view-id:

<pretty-config
	xmlns="http://ocpsoft.com/prettyfaces-xsd"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://ocpsoft.com/prettyfaces-xsd 
	http://ocpsoft.com/xml/ns/prettyfaces/pretty-1.0.xsd">
	<url-mapping id="home">
		<pattern> /home </pattern>
		<query-param name="displayWelcomeMessage">#{homeBean.displayWelcomeMessage}</query-param>
		<view-id> #{homeBean.getViewPath} </view-id>
	</url-mapping>
</pretty-config>

The corresponding backing-bean method must return a JSF ViewID, which will proceed with the faces lifecycle (leaving the URL /home), or a pretty:mappingId. In the case when a pretty:mappingId is returned, PrettyFaces will “switch mappings” and instead treat the request as if it had been sent to the new mappingId, without issuing a browser redirect.

public class ManagedBean
{
    public String getViewPath()
    {
        // This method returns the path of the JSF view to display
        // when the URL /home is accessed.
        if(user.isLoggedIn())
        {
        	// Note: the extension '.jsf' is the mapped faces extension
        	return "/faces/home.jsf";
        }
 
        // The home page can instead display a different view; return
        // the pretty:mappingId of the view you wish to display.
        // Note that this will not cause a redirect, and will not 
        // change the client browser URL.
        // If you wish to issue a redirect, you should use a page
        // load action instead of a dynamic view Id function.
        return "pretty:login";
    }
}

3.2 Using the Managed Query Parameter facility

Managed query parameters allow automatic assignment of values into JSF managed bean fields, instead of parsing and URL Decoding the value manually out of the request object. Examining this sample mapping, we can see that the developer has specified two managed query-parameters. The ‘sortBy’ and ‘itemId’ parameters.

<pretty-config>
	<url-mapping id="itemList">
		<pattern> /items/list </pattern>
		<query-param name="sortBy">#{itemBean.sortByField}</query-param>
		<query-param name="itemId">#{itemBean.currentItemId}</query-param>
		<view-id> /faces/items/list.jsf </view-id>
		<action>#{itemBean.loadItems}</action>
	</url-mapping>
</pretty-config>

The managed bean that accompanies this mapping:

public class ItemBean
{
	private List<Item> items;
	private Integer currentItemId;
	private String sortByField;
 
	public String deleteItem()
	{
		// currentItemId will be automatically populated by
		// PrettyFaces if the parameter was passed in the request
		// (see example JSF page below)
		ItemManager.deleteById(currentItemId);
 
		// Redisplay the current page via redirect.
		return "pretty:"
	}
 
	public void loadItems()
	{
		// The sortByField member will be null if the sortBy
		// query-parameter is not found in the request
		this.items = ItemManager.getSortedItems(sortByField);
	}
 
	//... getters and setters...
}

Example JSF page: Notice the <f:param> tag.

This will generate a link that provides the ‘itemId’ parameter to the request for PrettyFaces to parse.

<c:forEach var="item" items="${itemBean.items}">
	<h:commandLink>
		Delete this item.
		<f:param name="itemId" value="${item.id}" />
	</h:commandLink>
</c:forEach>

3.3 Wiring navigation into JSF action methods

public class PageBean
{
    public String goHome()
    {
        // this will tell pretty to redirect the client to the home-page
        // no parameters are mapped, so this is pretty simple
        return "pretty:home";
    }
 
    public String goHomeAndWelcome()
    {
        // this will tell pretty to redirect the client to the home-page
        // since there is a managed query-parameter defined in the mapping,
        // PrettyFaces will generate the URL, and append the mapped param
        // eg: /home?displayWelcome=true 
        homeBean.displayWelcomeMessage(true);
        return "pretty:home";
    }
 
    public String goViewStory()
    {
        // this will tell pretty to redirect the client to the viewStory page
        // PrettyFaces will generate the URL by extracting any values from
        // the mapping beans and using them to inject back into the pattern
        // therefore, navigation can be controlled by placing a value into
        // the mapped field before PrettyFaces extracts it and generates the URL
	// so... /story/#{myBean.currentStoryId}/ ...becomes... /story/12/ 
 
        viewStoryBean.setCurrentStoryId(12);
        return "pretty:viewStory";
    }
 
    public String doRefreshByRedirect()
    {
        // using the "pretty:" prefix without a mapping-id will cause a
        // redirect to the current page
        return "pretty:";
    }
 
    public String doNormalJSFRender()
    {
        // returning an value without the "pretty:" prefix will fall back to
        // the default JSF navigation handlers
        return "someNavigationCase";
    }
}

3.4 Parsing complex / dynamic-length URLs

Consider the following example configuration and bean: The URL contains many dynamic layers of mysite.com/value/value2/value3/…/valueN, which cannot be specified using a static URL pattern.

Since patterns are regexes, we can use a catch-all pattern, and process the values ourselves.

	<url-mapping id="dynamicUrl">
		<pattern> /blog/categories/.* </pattern>
		<view-id> #{urlParsingBean.parseComplexUrl} </view-id>
	</url-mapping>

Example of a complex URL parser. Remember to URLDecode before using any values from the URL:

public class UrlParsingBean
{
    public String parseComplexUrl() throws UnsupportedEncodingException
    {
        String uri = PrettyContext.getCurrentInstance().getOriginalUri();
        List<String> categoryChain = new ArrayList<String>();
 
        while(uri.length() > 0)
        {
            int index = uri.indexOf('/');
            String value = uri.substring(0, index);
            categoryChain.add(URLDecoder.decode(value, "UTF-8"));
            uri = uri.substring(index);
        }
 
        //now load the data...
 
        return "/blag/viewArticle.jsf";
    }
}

3.5 Accessing PrettyContext through EL

Since a new PrettyContext is generated on each request, and stored into the requestMap, it is possible to access the context object through EL in a JSP, or Facelet.

 
#{prettyContext.currentInstance} <!-- returns the current PrettyContext -->
#{prettyContext.currentInstance.currentMapping.id} <!-- returns the current UrlMapping Id -->
<!-- And so on... -->

4. Rendering HTML Links and URLs

4.1 The pretty:link component

PrettyFaces provides a JSF component to output an HTML link to the page. The link tag requires a mapping-id (specified in the pretty-config.xml,) identifying which link to render.

If the provided mappingId requires any url-pattern-parameters or managed-query-parameters, they can be passed in via the <f:param> tag.

Url pattern parameters can be passed individually, as a java.util.List or as an Array. In the latter two cases, toString() will be called on each of the objects in the list/array. If an empty or null list/array is passed, it will be ignored.

Url pattern parameters do NOT have a name attribute, and are parsed in the order they are passed into the tag. Managed-query-parameters DO have a name attribute, and order is irrelevant.

For Example: The viewComment pattern requires:

<!-- From pretty-config.xml, viewComment mapping-id, above:
 /story/#{myBean.currentStoryId}/#{myBean.commentId}-->
 
<%@ taglib prefix="pretty" uri="http://ocpsoft.com/prettyfaces" %>
 
<pretty:link mappingId="comment">
	<f:param value="#{myBean.currentStoryId}" />
	<f:param value="#{myBean.commentId}" />
	Go to Comment. (This is Link Text)
</pretty:link>

4.2 The pretty:urlbuffer component

PrettyFaces provides a JSF component to generate a URL for use as a page scoped variable through El. This tag requires a mapping-id (specified in the pretty-config.xml)

If the provided mappingId requires any url-pattern-parameters or managed-query-parameters, they can be passed in via the <f:param> tag.

Url pattern parameters can be passed individually, as a java.util.List or as an Array. In the latter two cases, toString() will be called on each of the objects in the list/array. If an empty or null list/array is passed, it will be ignored.

Url pattern parameters do NOT have a name attribute, and are parsed in the order they are passed into the tag. Managed-query-parameters DO have a name attribute, and order is irrelevant.

For Example: The viewItem pattern requires:

<!-- From the managed-query-parameter section above, itemList mapping-id.-->
<pretty:urlbuffer var="itemListUrl" mappingId="itemList">
	<f:param name="itemId" value="22" />
	<f:param name="sortBy" value="price" />
</pretty:urlbuffer>
<h:outputText value="Generated Url Is: #{requestScope.itemListUrl}" />
<!-- /items/list?itemId=22&sortBy=price -->
<br />

This design is intended to reduce complexity and prevent manual manipulation of URLs.

5. Configuring Logging (log4j)

example log4j.properties

### direct log messages to stdout ###
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.Target=System.out
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d{ABSOLUTE} %5p %c{1}:%L - %m%n
 
### set log levels - for more verbose logging change 'info' to 'debug' ###
 
log4j.rootLogger=warn, stdout
 
#this will set PrettyFaces logging level to 'info'
log4j.logger.com.ocpsoft.pretty=info

Finished. Run your application!

You should now have a fully functional PrettyFaces configuration.

“The community was speaking, but until recently, nobody was listening.”

A lot has changed since May 15, 2001, when the first ballot review of the JSF 1.0 framework was just beginning. To this day, Sun’s flagship web-application framwork has been an uncompromising box of tricks and gotchas, with little community adoption. This has been mostly due to its relatively developer-unfriendly nature; however, the second phase is coming, and with JSF2.0 peeking out from the edge of its nest, a new life is beginning to show.

From the start, JSF had mixed support from the community, with opposition from major players like IBM, HP, and the Apache Foundation. Apache voiced strong concerns because of “Sun’s current position that JSRs may not be independently implemented under an open source license.” In addition, they saw, “little value in recreating a technology [Struts] in a closed environment that is already available in an open environment.”¹

Apache’s concerns drew several other players to vote against JSF, but the final vote still passed with a 10-5 margin (Accenture abstained from voting.) With the voting complete a short two weeks later, the first JSF expert group was formed.

Three months after the formation of the expert group, the first JCP community review was complete, and Sun’s new star web-framework was on its way to reality. On the side of the box was a label, which read, “Final release, May 2004: Warranty Void if Removed” It was done, and their hands were off.

But some things that should not have been forgotten, were lost.

Since JSF was engineered by companies like IBM and Oracle, major contractors in the industry, most of the emphasis was placed on creating a modular architecture that could be ‘easily extended’ and broken down into components. While technically sound, and well designed for large companies where developers are part of an assembly line, the community at large found JSF hard to use.

JSF lacked life-cycle extension; there are six defined phases, and if you need to add another one, you’re out of luck. Also lacking was easy component creation — Creating a component in JSF today requires modification of no fewer than four separate files, even more if you use a separate renderer class. You were on your own if you wanted to validate multiple form fields against each other.

Navigation rules were ungainly, and difficult to follow logically without a visual editor. Community documentation was almost a joke. Sun’s mailing list and forum are still the best places to find help. There are some very knowledgeable people, but nowhere to be found is what most developers find most useful: a central, persistent resource for documentation. I like PHP’s model – official documentation with community feedback in comments below.

The lack of bookmarking support is one of the most highly-criticised facets of JSF, which is where I got involved, leading me to create the PrettyFaces URL rewriting extension. If you need to be convinced of the collective dysfunction on this topic, look at the results of a google search for “jsf bookmark”. Yet, at the root of all this was something JSF lacked until very recently – something very important.

A set of ears.

The community was speaking, but until recently, nobody was listening. Blame JCP? Cay Horstmann thinks that the JCP needs to be more open to the community.²

Personally, I’m surprised that JSF wasn’t abandoned completely, which says in my mind, “they got something right.” The framework does a lot for you, but “I can’t figure out how to use it”, “it doesn’t do what I need,” and “everything takes forever.”. This is where we see the light, and JSF2 enters from stage left; a new star performer?

From the very start, JSF2 is different, more open. Ed Burns, Ryan Lubke, Jim Driskoll and other blogging developers can be thanked for engaging the community in a way that Sun has not done before.

Convention over configuration has taught us a lot. We might thank Ruby on Rails, or possibly a collective laziness, but the JSR314 Expert Group has taken it to heart. “EzComp” is JSF’s new component writing system, and yes, it’s “Ez”.

Jim Driscoll explains how to create a “click to edit” AJAX input field, like those so popularly seen on Flickr, or Facebook. (About 30 lines of XHTML, plus JavaScript.) Tag libraries no longer need to be defined manually; they will spring to life as needed, based on the names and interfaces of your components.

JSF2 is showing stunning promise and vision. This is just a small set of changes that will drastically improve the usefulness and adoption of JSF. When a rookie Java web-developer can pick up JSF2.0, in their IDE of choice, and write a small, useful application in a day, that’s when we’ll know they’ve gotten it right. Man, life is good… but.

Where are my bookmarks?

Ahh yes.

After learning about JSF2 in mid-October, I’ve been following very closely the changes and discussions around its new architecture, and how it can be ‘fixed.’ At the top of the wish list, among other contenders like “Fixing Navigation Rules,” and even above “Simplified component development,” is one very near to my heart: “Enhanced support for GET requests.”

I began work on PrettyFaces before learning that JSF2 was in progress, but not before I had evaluated the other options available from the community. Jboss Seam had a UrlRewriting feature, but I found it cumbersome, requiring too much configuration, and the added burden of learning the entire Seam framework was too much for me. RestFaces was an alternative that I tried for a while, but several design choices made it difficult to incorporate in a non-invasive way, and I was left writing lines and lines of code in order to compensate for its (albeit few) shortcomings.

Shocked, disappointment struck when I was contacted by a PrettyFaces user, disheartened, who urged me to contact the JSF2 expert group because they were close to abandoning bookmarking support for the next release, a full five years after the last specification update. How could they be considering omitting such a critical feature? It would surely finish off whatever damage had been done by the first 8 years of JSF’s mis-managed life, and it would be dead forever. “Long live Struts,” Apache would tout.

New life.

But fate struck, and before I could even begin to write emails, begging for reconsideration, I got another pop-up from my inbox.

From: Dan J. Allen – Jan 10, 2:50pm

Lincoln,

Hey there. I have recently joined the JSF EG by way of my employment with Red Hat. My first action was to submit a couple of proposals to make JSF more "website friendly". After all, that is what got me interested in Seam in the first place.

In the most recent proposal, I cited the statements you made in a recent blog post. I have attached that proposal to this e-mail as well as a related proposal. We are listening (at least those of us at Red Hat) and we are trying our best to improve JSF within the boundaries that we have to work (i.e., the JCP). The JSF EG was definitely dysfunctional in the past, but Ed Burns, Red Hat, and a handful of other members have really started to turn things around. Adding pretty URLs is definitely too big of a change at this point given the time constraints, but you may find these two proposals to satisfy many of your other concerns. Feel free to provide feedback to the JSF EG regarding the design changes.

-Dan

Dan is the author of Seam in Action, and from my interactions with him, a brilliant individual. If he isn’t rich already, in heart or on paper, he will be someday.

Struck by two emails on this subject in the same day, I “hurriedly” (from 11pm-2am) typed a response. Someone at RedHat was asking me for my feedback? Talk about an ego trip. My friends at work won’t let me hear the end of it.

The proposal was stunning. While still omitting Pretty URL rewriting, it contained in depth solutions for using query-string parameters (http://url?key=value) to bookmark pages within JSF. It lacked page-load actions, but that would follow, as we talked through the issues, in the next few days.

During the process of reviewing Dan’s proposals, providing feedback where I could, and wishing I weren’t just a part-time contributor, we worked through issues regarding usability, convention over configuration, and strategies for implementing the new functionality that would be required. Two weeks and 91 emails later, we had a draft of the spec, and off it went (via Pete Muir at RedHat) to the Expert Group for review.

The proposal was accepted; Dan’s job got even better. Within a week, he would have to implement his proposed specification, create a sample application, make any necessary changes to the spec, submit it back to the EG, and believe me, it was good.

Things yet to come.

JSF2 is still under review, and all of these changes may yet be changed, but I’m confident that the people in charge have heads on their shoulders, and that they are pointing in the right direction.

I’m impressed. Impressed by Dan Allen, Jim Driscoll, Ryan Lubke, and by Sun for starting to recognize that its developer community is its best chance at survival. JSF2 won’t have everything that we’ve asked for, but it will have the most critical features that the community has asked for. I’m impressed that it’s turning out so well: Component writing is truly easy; pages will be bookmark-able; templating is built in; and annotations are on the way to deprecating faces-config.xml for trivial tasks.

So what can Sun do next? Well. For starters, keep listening. Don’t limit ideas to people on its payroll. JSF2 will be a success if Sun gives users a voice.

The developer blogs are great, but we need a centralized place for core documentation. The site needs to be fast, and you should be able to easily register and contribute. Yes, it will take management and oversight, but we aren’t out to hurt anyone. Dear sun: “We like what you’re doing, and the direction in which we think you might be turning. We’re here to further the cause of software development, and guess what… If you listen to us… we’ll do it for free.”

Whether or not this happens, the future of JSF is in our hands.

–

1http://www.jcp.org/en/jsr/results?id=614

2http://weblogs.java.net/blog/cayhorstmann/archive/2009/01/a_call_to_fix_t.html

Well folks, for those of you who were hoping JSF 2.0 would contain the URL rewriting tools that many had asked for, unfortunately it looks like it’s not going to make it into the official spec. Bookmarking a page, or pages in JSF has been a heavily requested feature, but according to this discussion, is currently out of scope.

But that’s ok…

The PrettyFaces JSF Bookmark extension has been updated for JSF 2.0, and is ready for public preview (download below).

Only minor updates were required, and should be stable, but due to the un-finalized nature of JSF 2.0 itself, the extension may change as well.

Please note:

Parsed parameters are now assigned to Managed Beans after the RESTORE_VIEW phase. Previously this had taken place before the RESTORE_VIEW phase.

Version 1.2.0: binary, source

Major Release: 20081231

1. Added managed query-parameter support for URLs and JSF forms
2. New URL Buffer component makes using dynamic URLs easy
3. URL encoding/decoding now complies with W3C standards
4. Dynamic View Ids now allow returning pretty:navigation strings to display another view without issuing redirect or changing the client browser URL
5. Enhanced exception messages for much of the URL Parsing and Building