<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?

I’ve since learned of two ways to deal with this situation:

1. Use ListDataModel

I asked another JSF Expert, Dan Allen (author of Seam in Action) and here’s what he told me:

@ManagedBean
@SessionScoped // chosen for convenience, really it should be view-scoped or conversation-scoped (299)
public class FeatureList
{
	private DataModel features;
 
	public DataModel getFeatures() 
	{ 
		return features; 
	}
 
	public String load() 
	{
		List l = new ArrayList();
		l.add(new Feature("One"));
		l.add(new Feature("Two"));
		features = new ListDataModel(l);
	}
 
	public void action()
	{
		System.out.println("You clicked on the button in the row with feature " 
			+ ((Feature) features.getRowData()).getName());
	}
}

@DataModelSelection Feature selectedFeature;

From Dan’s email, I learned that you could place a List of objects in a ListDataModel wrapper, effectively binding the state of the list to the UI. With that done, you can manipulate the data in an action-method, being able to retrieve the selected row index, object itself, and continue as you would expect with your programming.

2. Upgrade to an advanced EL (EL2) Jar

Probably my favorite solution – you can use EL2 method invocation, provided either by Seam, or Sun’s reference implementation, and pass the desired objects directly to methods in your JSP/Facelet code. It’s coming standard in J2EE 6, but why wait?

This method is simple, intuitive, and enables much more powerful and reusable Beans to handle page code, reducing redundancy in Model classes and business logic.

Note how I pass the current var object directly to the method via EL:

<h:commandButton id="add" value="Add Task" 
    action="#{itemController.addItemNote(currentItemBean.item, addNoteBean.newNote)}">

And here’s the Backing Bean code:

@ManagedBean
@RequestScoped
public class ItemController
{
    public String addTask(final Item item, final Note note)
    {
        ItemService.addNote(item, note);
        return "pretty:viewItem";
        // this return statement is a PrettyFaces JSF bookmarking navigation id
    }

For instructions on how to: include EL2 in a JSF project go here.

For more information on JSF SEO and Bookmarking, take a look at PrettyFaces: URL rewriting extension for JSF.

If you are at all confused by these examples, feel free to leave a comment, and I’ll do my best to help.

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

• You can pass a value-binding into a component.
• You can assign a listener to a specific input field/button inside a custom component.
• You can pass facets into components and use them conditionally.
• You can attach validators to specific input fields/buttons of components.
• You can pass nested children into components and use them conditionally.
• In EzComp, namespaces are created automatically by convention — no more taglibs
• You can include CSS or JS files from packaged jars — a big issue when using shared libraries of components.
• Standard support for Ajax — no javascript required (<f:ajax />).

Without all of this, with JSP or Facelets 1.2, you eventually need to write components in Java, which means a lot of time-consuming work. Having gone down that road, and then experienced EzComp, I’ve seen a time-saving of about 10x, with a lot more power to create really interactive and rich components through Ajax. Instead of 3-4 files required to make a component, you now have 1 — the component.

Moral of the Story: If you are considering an upgrade from JSP, go right to JSF2 — it’s stable enough to begin development.

Also, be sure to check out the developer blags for more updates on JSF2:

• Ed Burns
• Ryan Lubke
• Jim Driscoll

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.

Getting started with Hibernate can be tricky, but here’s a step-by-step tutorial that explains exactly what needs to be done to enable your application for hibernate. This chapter covers very basic mapping and persistence.

Download the following archives: (or use this Maven POM)

• Hibernate Core (3.3.0_CR1)
• Hibernate Annotations (3.4.0_CR1)
• HSQLDB (1.8.0.10), a lightweight in-memory RDBMS (or use the database of your choice)

Instructions:

• Extract the archives and copy necessary JAR files into your project (or if you are using Maven, this is already taken care for you -> example POM):
  It may seem like quite a few jars, it might not, but this is the minimal set to have a working Hibernate Annotations 3.4.0 application. All of the following files should be contained in your downloads.
  

Hibernate Annotations
hibernate-annotations.jar
hibernate-commons-annotations.jar
jta.jar (JTA, javax.transaction)

Hibernate Core
hibernate-core.jar (or hibernate3.jar)
ejb3-persistence.jar (javax.persistence)
antlr.jar (2.7.6)
commons-collections.jar (3.1)
dom4j.jar (1.6.1)
slf4j-api.jar (1.4.2)
cglib.jar (v2)
asm.jar (v3)

HSQLDB
hsqldb.jar

• Add the JARs to your project’s classpath.
• Copy and paste the following source files into your project. We’re going to use some canned configurations in order to get all of this working.

log4j.properties

(Optional) Put this file on your classpath, or in your source folder. Hibernate uses log4j to print output, so if we want to see detailed results, you should set this up.

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
 
log4j.rootLogger=warn, stdout
log4j.logger.org.hibernate=info
log4j.logger.org.hibernate.type=info
log4j.logger.org.hibernate.tool.hbm2ddl=debug
log4j.logger.org.hibernate.transaction=debug

—-

MockObject.java

It’s time to create our first object. Notice that this is a simple POJO with two fields: id and version. The id field is a required field, but before you complain, there is a philosophy of database design that dictates every entity table should have its own id column; some disagree with this, but I’ve found it a very convenient practice. Try it out before you pass judgment.

In order to map an object, a few things always need to be done:

• The class must be annotated with @javax.persistence.Entity
• The class must have a @javax.persistence.Id column
• The class must have a default (or undefined) constructor method. This means it must have a constructor that has no arguments.
• The @Version column is how Hibernate performs optimistic locking. If a record has been modified by another transaction, your transaction’s version will be out of date, and an exception will be thrown.
• By default, all fields in your class will be persisted to the database if possible. If there is a field that should not be recorded in the database, mark that field with the @Transient annotation.
• To add new columns in the database, simply add new fields in your object.

import java.io.Serializable;
 
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.Table;
import javax.persistence.Version;
 
@Entity
@Table(name = "mock_objects")
public class MockObject implements Serializable
{
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    @Column(name = "id", updatable = false, nullable = false)
    private Long id = null;
 
    @Version
    @Column(name = "version")
    private int version = 0;
 
    public Long getId()
    {
        return id;
    }
 
    public int getVersion()
    {
        return version;
    }
}

—-

HibernateUtil.java

HibernateUtil is a convenience class that automates configuration, and provides your application access to the active Session. This is where you tell Hibernate about your MockObject class, and where you get a handle to an object that will save, update, delete and etc. your objects.

import org.hibernate.SessionFactory;
import org.hibernate.cfg.AnnotationConfiguration;
 
public class HibernateUtil
{
    private static final SessionFactory sessionFactory;
 
    static
    {
        try
        {
            AnnotationConfiguration config = new AnnotationConfiguration();
            config.setProperty("hibernate.dialect", "org.hibernate.dialect.HSQLDialect");
            config.setProperty("hibernate.connection.driver_class", "org.hsqldb.jdbcDriver");
            config.setProperty("hibernate.connection.url", "jdbc:hsqldb:mem:demodb");
            config.setProperty("hibernate.connection.username", "sa");
            config.setProperty("hibernate.connection.password", "");
            config.setProperty("hibernate.connection.pool_size", "1");
            config.setProperty("hibernate.connection.autocommit", "true");
            config.setProperty("hibernate.cache.provider_class", "org.hibernate.cache.NoCacheProvider");
            config.setProperty("hibernate.hbm2ddl.auto", "create-drop");
            config.setProperty("hibernate.show_sql", "true");
            config.setProperty("hibernate.transaction.factory_class", "org.hibernate.transaction.JDBCTransactionFactory");
            config.setProperty("hibernate.current_session_context_class", "thread");
 
            // Add your mapped classes here:
            config.addAnnotatedClass(MockObject.class);
 
            sessionFactory = config.buildSessionFactory();
        }
        catch (Throwable ex)
        {
            System.err.println("Initial SessionFactory creation failed." + ex);
            throw new ExceptionInInitializerError(ex);
        }
    }
 
    public static SessionFactory getSessionFactory()
    {
        return sessionFactory;
    }
}

—-

HibernateDemo.java

Our driver class is very simple; it does the following things:

• Get a handle to Hibernate Session
• Create and persist two new MockObjects
• Print out the generated IDs
  

import org.hibernate.Transaction;
import org.hibernate.classic.Session;
 
public class HibernateDemo
{
    public static void main(String[] args)
    {
        Session session = HibernateUtil.getSessionFactory().getCurrentSession();
        Transaction transaction = session.beginTransaction();
 
        MockObject object0 = new MockObject();
        MockObject object1 = new MockObject();
        session.save(object0);
        session.save(object1);
 
        transaction.commit();
 
        System.out.println("Object 0");
        System.out.println("Generated ID is: " + object0.getId());
        System.out.println("Generated Version is: " + object0.getVersion());
 
        System.out.println("Object 1");
        System.out.println("Generated ID is: " + object1.getId());
        System.out.println("Generated Version is: " + object1.getVersion());
    }
}

And here we are. When you run HibernateDemo, you should have a fully functional Hibernate enabled HSQL database with one table. Play around with adding new fields to your object.

Your output should look something like this:

Object 0
Generated ID is: 1
Generated Version is: 0
Object 1
Generated ID is: 2
Generated Version is: 0

—-

Considering the Forces:

I’d like to note, here, that we’re doing a lot of configuration in the code itself. This is OK if you are relatively sure that you won’t need to be making changes to your data model or back-end configuration very frequently. However, if you know that this is going to happen, I strongly suggest using XML configuration files instead, and you should also consider using traditional Hibernate with XML object-relational mappings. If you build all configuration into your code, every time you change the configuration, you’ll have to recompile / rebuild parts of your system. It’s much easier just to edit a file. However, unless you’re sure, just cross that bridge when you come to it.

A few more things to remember:

Take your time. Don’t give up. Ask questions. READ the forums and documentation.

Hibernate is BIG. It’s a very powerful, very complex tool. It took me a long time to get even a simple object relationship working the way I wanted to. The learning curve is not small, and you will probably be frustrated for a while. I have, however, come to the point where I see so much benefit, that I feel it was completely worth my time to learn.

Configuration is everything. Hibernate can do anything you want: You can use it to tie in to existing database schema; you can use it to run plain SQL queries or stored procedures.

Good luck.

References:

1. Hibernate’s Standard Tutorial
2. Hibernate Annotations Reference

This article is part of a series: Guide to Hibernate Annotations

• Enhanced internal navigation/redirects. Returning “pretty:” from a JSF action method, or Pretty action method will cause a redirect to the current page. Effectively a refresh.
• Added the <pretty:link> component.
• Added attribute to Pretty action method configuration, allowing targeting of action methods to specific JSF phases in the lifecycle.

View the documentation here, for PrettyFaces.

—-

PrettyFaces is an OpenSource JSF extension which enables creation of bookmarkable, pretty URLs made easy. Our goal was to solve this problem as simply as possible, while still enabling a useful set of functions such as: page-load actions, integration with faces navigation, dynamic view-id assignment, and managed parameter parsing. All of this without introducing unnecessary coupling.