From 5627c93b187ea5c1b58e8034461a2538a8b45cdb Mon Sep 17 00:00:00 2001 From: Michael Gloegl Date: Tue, 15 Mar 2005 19:02:00 +0000 Subject: [PATCH] Integrating "Road to Hibernate" git-svn-id: https://svn.jboss.org/repos/hibernate/trunk/Hibernate3/doc@6072 1b8cb986-b30d-0410-93ca-fae66ebed9b2 --- reference/en/master.xml | 3 + reference/en/modules/tutorial.xml | 1846 +++++++++++++++++++++++++++++ 2 files changed, 1849 insertions(+) create mode 100644 reference/en/modules/tutorial.xml diff --git a/reference/en/master.xml b/reference/en/master.xml index c684582c0c..b4ea2570f3 100644 --- a/reference/en/master.xml +++ b/reference/en/master.xml @@ -3,6 +3,7 @@ "../support/docbook-dtd/docbookx.dtd" [ + @@ -141,6 +142,8 @@ &quickstart; + + &tutorial; &architecture; diff --git a/reference/en/modules/tutorial.xml b/reference/en/modules/tutorial.xml new file mode 100644 index 0000000000..c25bba8f89 --- /dev/null +++ b/reference/en/modules/tutorial.xml @@ -0,0 +1,1846 @@ + + A Tutorial Introduction to Hibernate + + + Preface + + + This chapter is an introductory tutorial for new users of Hibernate. We start up with a simple command line application using an in-memory database and develop it further in small steps, until we reach a full fledged J2EE-Application using Tomcat and WebWork. + + This tutorial is intended to be for beginning users of Hibernate, but with advanced Java knowledge. It increases slowly in speed, and we hope is as understandable as possible - if you work through it and meet points where you find it difficult to understand, please let us know. + + + + + + Part 1 - The first Hibernate Application + + For the beginning, we will do a very simple console based Hibernate Application. We will use an in-memory database, so we do not have to install any database server. + + + + Let's assume we want to have a small application where we can store events we want to attend and who hosts these events. + + + + So the first thing we will do is set up our development directory and put all the jar-Files we need in it. We have to download the Hibernate distribution from the Hibernate download page. Extract the needed jars from the hibernate archive. We will place them all in a lib directory under the development dir, so your devel directory should now look like this: + + + + + + The first class + + + So the next thing we will do is create a class which represents the events we want to store. This will be just a simple Java Bean, which contains some properties. Let's look at the code: + + + + Some things are noteworthy here: + + + + The id property is a unique id for the Event - all our persistent objects will need such an id. A good idea when building hibernate applications is to keep such unique ids separate from the application logic. This means we will not manipulate the id anywhere in our code, and leave it to Hibernate to care about it. That's why the setter of the id is private, allowing Hibernate to use them (Hibernate may access property get- and set-Methods of all visibilities), but shielding it from us. + + + + We are also using a true Long for the id, not a primitive type long. This will save us a lot of hassles later on - so always use Objects for the id property, never primitive types (If it is possible). + + + + We will place this file in a directory called src in our development folder. The directory should now look like this: + + + +src + +de + +gloegl + +road2hibernate + Event.java]]> + + + + The mapping file + + As we now have our class to store in the database, we must of course tell hibernate how to persist it. This is where the mapping file comes into play. The mapping file tells Hibernate what should stored in the database - and how. + + + + The basic structure of a mapping file looks like this: + + + + + + +]]> + + Between the two hibernate-mapping tags, we will include a class element, where we can declare which class this mapping refers to and to which table in our SQL database the class should be mapped. So step 2 of our mapping document looks like this: + + + + + + + + + + +]]> + + + So what we have done so far is telling hibernate to persist our class Event to the table EVENTS. No we will have to give hibernate the property to use as unique identifier - which is what we have included the id property for. In addition, as we don't want to care about handling this id value, we have to tell hibernate how to generate the ids. Including this, our mapping file looks like this: + + + + + + + + + + + + +]]> + + So what does all this mean? The id element is the declaration of the id property. name="id" is the name of the property - hibernate will use getId and setId to access it. The column attribute tells hibernate which column of the EVENT table will contain the id. The type attribute tells hibernate about the property type - in this case a long. For now the type attribute is not important to us, if you want to know more about it see + + + + The generator element specifies the id generation technique to use - in this case we will use increment, which is a very simple generation method, but which we will use in our small example as it is sufficient here. + + + + Finally we have to include declarations for the persistent properties in the mapping file: + + + + + + + + + + + + + + + +]]> + + + There are a few things noteworthy here. At first, just as with the id element, the name attribute of the property element tells Hibernate which get- and set-methods to use. + + + + However, you will notice that the title property contains a column attribute, however the date attribute does not. This is possible because when the column attribute is left out, Hibernate by default uses the property name as column name. + + + + The next interesting thing is that the title property lacks a type attribute. Again, Hibernate will try to determine the correct type itself if the type attribute is left out. Sometimes however Hibernate just can't do that and we have to specify the type - as it is the case with the date property. Hibernate can't know if the property will map to a date, timestamp or time column in the database, so we have to specify this. + + + + We will place the mapping in a file called Event.hbm.xml right in the directory where our Event class is located. So your directory structure should now look like this: + + + + +src + +de + +gloegl + +road2hibernate + Event.java + Event.hbm.xml]]> + + + Configuration and Database + + As we now have our persistent class and the mapping file it is time to configure Hibernate. Before we do this, we will need a database however, so we go on and get HSQLDB, a java-based in-memory SQL Database, from the HSQLDB website. What we need is the hsqldb.jar from the lib directory of the zip download. We will place it in our lib directory which should now look like this: + + + hsqldb.jar + +src + ]]> + + In addition, we will create a directory data right under our development directory, where hsqldb will store its files. + + + Now Hibernate configuration can be done in an xml file, which we will call hibernate.cfg.xml and place it directly in the src folder of our development directory. This file looks like this: + + + + + + + + org.hsqldb.jdbcDriver + jdbc:hsqldb:data/test + sa + + org.hibernate.dialect.HSQLDialect + true + + org.hibernate.transaction.JDBCTransactionFactory + + + org.hibernate.cache.HashtableCacheProvider + + update + + + + + +]]> + + The first four property elements contain the necessary configuration for the JDBC-Connection Hibernate will use. The dialect property element specifies the SQLdialect Hibernate shall generate. Next we specify that Hibernate shall delegate transactions to the underlying JDBC connection and specify a simple cache provider (this is without effect because we don't use any caching yet). The next property tells hibernate to automatically adjust the tables in the database according to our mappings. Finally we give the path to our mapping file. + + + + Building + + So finally we can start building our first application. For convenience, we create a batch file in our development directory which contains all commands necessary for compilation. Under Windows, this would look like this: + + + + We place this file called build.bat in our development directory. If you are using Linux, you can surely create an equivalent shell script. + + + Finally we create the bin subdirectory of our development directory to place the compiled classes in. + + + + Running + + So now we will create a simple class which will start up Hibernate. It looks like this: + + + + This class just uses a class called HibernateUtil to get a Session instance. HibernateUtil is where all the magic goes on. It uses the so called "ThreadLocal Session Pattern" to keep the current session associated with the current thread. Lets have a look at it: + + + + This class does not only create the SessionFactory in its static initializer, but also has a ThreadLocal variable which holds the Session for the current thread. Make sure you understand the Java concept of a thread-local variable before you try to use this helper. A more complex and powerful HibernateUtil class can be found in CaveatEmptor, http://caveatemptor.hibernate.org/ + + + Place both the EventManager.java and the HibernateUtil.java in the directory where Event.java already is: + + + + Now compile everything by starting build.bat in the development directory. Run the application by running this in the development directory (all in one line): + + + + This should produce the following output: + + + + Let's place this line in a batch file too, so we can run it a little more conveniently. Place it in the development directory, called run.bat (add %1 %2 %3 %4 %5 at the end of the line). + + + + So we are happy that we don't have any errors so far - but we still want to see what Hibernate is doing during startup and want to get rid of those warnings, so we have to configure log4j. This is done by putting the following file called log4j.properties in your src-Directory: + + + + In addition, the following line has to be added to the build.bat: + + + + We won't get into what exactly this all is, in effect it tells log4j to write all log output to the console. + + + Now recompile the application by starting build.bat again, and rerun it - now there should be detailed info what hibernate is doing in your output. + + + + Working with persistence + + As we now finally have configured hibernate and our mappings, we take advantage of hibernate and persist some objects. We will adjust our EventManager class now to do some work with hibernate. + + + At first we modify the main-Method: + + + + So what we do here is read some arguments from the command line, and if the first argument to our application is store, we take the second argument as the title, create a new Date and pass both to the store method, where it gets really interesting: + + + + We simply create a new Event object, and hand it over to Hibernate. Hibernate now takes care of creating the SQL, and sending it to the database. We can even start and stop transactions, which Hibernate will delegate to the JDBC connection. + + + The method hsqlCleanup listed below performs some necessary shutdown code telling HsqlDB to remove all its lock-files and flush its logs. This is not a direct hibernate requirement, so this would not be necessary when using a "real" database. + + + + Please not that all the transaction and session handling code in these examples is extremely unclean, mainly for shortness. Please don't use that in a production app. For a more detailed explanation on how to handle transactions properly see . + + + If we now run the application with run.bat store Party an Event object will be created an persisted to the database. + + + But now we want to list our stored events, so we modify the main method some more: + + + + When the first argument is "list", we call listEvents() and print all Events contained in the returned list. listEvents() is where the interesting stuff happens: + + + + What we do here is using a HQL (Hibernate Query Language) query to load all existing Event objects from the database. Hibernate will generate the appropriate SQL, send it to the database and populate Event objects with the data. You can create more complex querys with HQL of course, which we will see in later chapters. + + + So in this chapter we learned how to setup Hibernate, how to create a mapping for our classes, and how to store and retrieve objects using Hibernate. + + + That's it for the first chapter, in the next part we will replace our ugly build.bat with an ant-based build system. + + + + + Part 2 - Building with Ant + + In this short chapter we will replace the ugly build.bat file we created with a nice little Ant build file. You will need to have Ant installed - get it from the Ant download page. How to install Ant will not be covered here. Please refer to the Ant manual. After you have installed Ant, we can start to create the buildfile. It will be called build.xml and placed directly in the development directory and will replace the build.bat (which you can delete). + + + A basic build file + + A basic build file looks like this: + + + + + + + + ]]> + + The project tags surround the whole buildfile. There are two attributes, the name attribute which gives a name for the project being built, and the default attribute which specifies the default target which will be run if we launch Ant without specifying a target. + + + Inside of the project tags, we have to give at least one target block, where we can tell Ant what to do - in this case, ant will do just nothing. You can now run the build by running ant on the command line inside the development directory. + + + You should get an output like this: + + + + This tells us Ant did run successfully and which build file was used. The default target was run, which is why the compile: part of the output shows us the compile target was executed. We can however give Ant an explicit target to run by calling ant compile from the command line, which will run the compile target. + + + So now we want Ant to actually compile our classes. So we insert the javac task inside the target elements: + + + + + + + + ]]> + + This will tell Ant to launch the java compiler and compile everything it can find under the the src directory and place the generated class files in the bin directory. However if we now run Ant, we will get a lot of compile errors, because the compiler can not find the hibernate classes. So we have to tell the compiler about the classpath to use, just as we did in the old build.bat: + + + + + + + + + + + + + + + ]]> + + This will tell Ant to find all files in the lib directory with .jar as file ending and add them to the classpath used for compilation. If you now run Ant, you should get an output like this: + + ant +Buildfile: build.xml + +compile: + [javac] Compiling 2 source files to C:\hibernateTutorial\part2\bin + +BUILD SUCCESSFUL +Total time: 1 second ]]> + + + Dependant targets + + Great, so now we got ant to compile our two java files. This however still leaves the log4j.properties and the mapping file, which are not copied to the bin directory. We will take care of this now by adding an additional target: + + + + + + + + + + + + + + + + + + + + + + + ]]> + + So this tells ant when it executes the copy-resources target to copy everything it can find in the src directory or in any directories below to the bin directory but exclude all java files anywhere under the src directory (this is what the ** in front of the / means). + + + So if you run Ant now, you will see ... actually nothing. Ant will execute the compile target and not touch our copy-resources target. So what we need to do now is to tell ant it has to execute copy-resources before the compile target - this is what the depends attribute of the target element is for: + + + + + + + + + + + + + + + + + + + + + + + ]]> + + So if you now execute ant you should see output like this: + + + + So Ant has now executed both targets and copied our resources over to the bin directory. You will notice that ant does not print anything under the compile target. Ant notices that no source files have changed and does not compile them again. The same will happen for copy-resources - ant will not copy our files again unless we change them, or remove them from the bin directory. + + + + Using Properties + + So now we have a nice little build script in place. We could well go on from here. You will notice however that our directory names are spread all over the build file. Should we ever want to change them, we would have to change them all over the build file. We will solve this problem by using Ant property declarations: + + + + + + + + + + + + + + + + + + + + + + + + + + + ]]> + + So we can define our properties using the property tag, and can insert them anywhere in the build file using the name we declared for the property surrounded with ${}. Notice the ${basedir} property we use in the property declarations - this is a property predefined by Ant, which contains the path of the directory where Ant is executed. + + + In the next chapter, we will create associations between our classes using java collections. + + + + + Part 3 - Mapping Associations + + As we now have mapped a single object, we are now going to add various object associations. For a starter, we will add users to our application, and store a list of participating users with every event. In addition, we will give each user the possibility to watch various events for updates. Every user will have the standard personal data, including a list of email addresses. + + + Mapping the User class + + For the beginning, our User class will be very simple: + + + + And the mapping in User.hbm.xml: + + + + + + + + + + + + + + + + +]]> + + The hibernate.cfg.xml needs to be adjusted as well to add the new resource: + + + + + + + + org.hsqldb.jdbcDriver + jdbc:hsqldb:data/test + sa + + org.hibernate.dialect.HSQLDialect + true + + org.hibernate.transaction.JDBCTransactionFactory + + + org.hibernate.cache.HashtableCacheProvider + + update + + + + + + +]]> + + + An unidirectional Set-based association + + So far this is only basic hibernate usage. But now we will add the collection of favorite events to the User class. For this we can use a simple java collection - a Set in this case, because the collection will not contain duplicate elements and the ordering is not relevant for us. + + + So our User class now looks like this: + + + + Now we need to tell hibernate about the association, so we adjust the User.hbm.xmlmapping document: + + + + + + + + + + + + + + + + + + + + + ]]> + + As you can see, we tell Hibernate about the set property called favouriteEvents. The set element tells Hibernate that the collection property is a Set. We have to consider what kind of association we have: Every User my have multiple favorite events, but every Event may be a favorite of multiple users. So we have a many-to-many association here, which we tell Hibernate using the many-to-many tag. For many to many associations, we need an association table where hibernate can store the associations. The table name can be configured using the table attribute of the set element. The association table needs at least two columns, one for every side of the association. The column name for the User side can be configured using the key element. The column name for the Event side is configured using the column attribute of the many-to-many element. + + + So the relational model used by hibernate now looks like this: + + | *EVENT_UID | | | + | DATE | | *USER_UID | <--> | *UID | + | EVENTTITLE | |__________________| | AGE | + |_____________| | FIRSTNAME | + | LASTNAME | + |_____________| + ]]> + + + Modifying the association + + As we now have mapped the association, modifying it in EventManager is very easy: + + + + After loading an User and an Event with Hibernate, we can simply modify the collection using the normal collection methods. As you can see, there is no explicit call to session.update() or session.save(), Hibernate automatically detects the collection has been modified and needs to be saved. + + + Sometimes however, we will have a User or an Event loaded in a different session. This is of course possible to: + + + + This time, we need an explicit call to update - Hibernate can't know if the object actually changed since it was loaded in the previous session. So if we have an object from an earlier session, we must update it explicitly. If the object gets changed during session lifecycle we can rely on Hibernates automatic dirty checking. + + + Since Hibernate 2.1 there is a third way - the object can be reassociated with the new session using session.lock(object, LockMode.NONE): + + + + + Collections of Values + + Often you will want to map collections of simple value types - like a collections of Integers or a collection of Strings. We will do this for our User class with a collection of Strings representing email addresses. So we add another Set to our class: + + + + Next we will add the mapping of the Set to our User.hbm.xmlmapping document: + + + + + + + + + + + + + + + + + + + + + + + + + + ]]> + + As you can see, the new set mapping looks a lot like the last one. The difference is the element part, which tells Hibernate that the collection does not contain an association with a mapped class, but a collection of elements of type String. Once again, the table attribute of the set element determines the table name. The key element determines the column name in the USER_EMAILS table which establishes the relation to the USERS table. The column attribute in the element element determines the column name where the String values will be actually stored. + + + So now our relational model looks like this: + + | *EVENT_UID | | | | *ID | + | DATE | | *USER_UID | <--> | *UID | <--> | USER_UID | + | EVENTTITLE | |__________________| | AGE | | EMAIL | + |_____________| | FIRSTNAME | |_____________| + | LASTNAME | + |_____________| + ]]> + + + Using value collections + Using value collections works the same way as we have already seen: + + + As you see, you can use the mapped collection just like every java collection. Hibernates automatic dirty detection will do the rest of the job. For objects from another session - or disconnected objects, as we will call them from now - the same as above aplies. Explicitly update them, or reassociate them before updating using session.lock(object, LockMode.NONE). + + + + Bidirectional associations using Sets + + Next we are going to map a bidirectional association - the User class will contain a list of events where the user participates, and the Event class will contain a list of participating users. So first we adjust our classes: + + + + The mapping for a bidirectional association looks very much like a unidirectional one, except the set elements are mapped for both classes: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ]]> + + As you see, this are normal set mappings in both mapping documents. Notice that the column names in key and many-to-many are swapped in both mapping documents. The most important addition here is the inverse="true" attribute in the set element of the User mapping. + + + What this means is the other side - the Event class - will manage the relation. So when only the Set in the User class is changed, this will not get perstisted. Also when using explicit update for detatched objects, you need to update the one not marked as inverse. Let's see an example: + + + + Using bidirectional mappings + + At first it is important to know that we are still responsible for keeping our associations properly set up on the java side - that means if we add an Event to the eventsJoined Set of an User object, we also have to add this User object to the participatingUsers Set in the Event object. So we will add some convenience methods to the Event class: + + + + Notice that the get and set methods for participatingUsers are now protected - this allows classes in the same package and subclasses to still access the methods, but prevents everybody else from messing around with the collections directly. We should do the same to the getEventsJoined() and setEventsJoined() methods in the User class. + + + Now using the association in EventManager is very easy: + + + + In the next chapter we will integrate Hibernate with Tomcat and WebWork to create a better test environment - as you will notice when you look at the code, the EventManager class is really ugly now. + + + + + Part 4 - Tomcat and WebWork + + In this chapter we will finally get rid of our ugly command-line-based test application and integrate Tomcat, WebWork and Hibernate to create a little web-based application. + + + The first step for you is to install Tomcat - you can download it here. You can find documentation and install instructions for Tomcat here. + + + Restructuring the development directory + At first, we will restructure our working directory, to keep the parts of our application nicely separated: + + + We moved our classes and mappings to the data subdirectory of road2hibernate. Of course we need to adjust our package declaration in the java files and the classnames in the mapping files. + + + In addition, we created various new directories: + + + + + src/de/gloegl/road2hibernate/actions will contain the source code for our WebWork actions. + + + + + config will contain the config files which will later be placed in WEB-INF/config of our web app. + + + + + static-web will contain all static content of our application, like html and image files. + + + + + views will contain our view files which contain the html later displayed to the user. + + + + + As we will use WebWork for our application and Velocity as template engine for the views, you will need to get WebWork from here. You will need the webwork-2.1.7.jar from the WebWork download, and all jar files in the lib/core folder of the WebWork distribution. Place all of them into the lib directory of the development dir. + + + + Configuring WebWork + + Now we will configure our application to use WebWork. At first we need a web.xml which we will place in the config directory: + + + + + Eventmanager + + + webwork + + com.opensymphony.webwork.dispatcher.ServletDispatcher + + 1 + + + + velocity + + com.opensymphony.webwork.views.velocity.WebWorkVelocityServlet + + 10 + + + + webwork + *.action + + + + velocity + *.vm + + + + index.html + + ]]> + + This files contains all the servlets and servlet mappings which WebWork needs to run. + + + In addition, we will need a xwork.xml file, which is placed directly in the src dir: + + + + + + + + + + + ]]> + + This file contains only the declaration of the packages where WebWork will look for its actions. + + + + Updating the build process + + Now we will make our build process place all the files together and generate the appropriate structure for the web application. We update our build.xml: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ... ]]> + + Running this target will create a directory called war, which will contain the web application just like it will later be structured in the war file. After running this target, the war directory will look like this: + + ]]> + + Now we will add Tomcat specific tasks to our build file, so we can directly install our application into Tomcat using Ant. You need to adjust the example to your environment. Modify the build.xml again: + + + + .... + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ... +]]> + + So now startup Tomcat and run ant install from the commandline - this will install the application to Tomcat. Now you should be able to access the eventmanager application by pointing your browser to http://localhost:8080/eventmanager/ - however you will only get a directory listing produced by Tomcat. We will now have to create some content for the application to display. + + + + A first WebWork action + + Our first WebWork action will be very simple - it will do nothing so far but forwarding to a view. We create /src/de/gloegl/road2hibernate/actions/EventList.java: + + + + The class extends ActionSupport but does not override any methods. So this will rely on the default behavior of ActionSupport: The action will forward to the view defined as the SUCCESS view. This is what we still have to do in the xwork.xml file: + + + + + + + + + + + /WEB-INF/views/eventlist.vm + + + ]]> + + This defines an action called eventlist which will be handled by our EventList class. In addition, the success view gets defined. We now have to write the eventlist.vm file, which will be placed in the views folder - Ant will copy it to the correct location. + + + + Event List + + +

Successful

+ + ]]> + + As you see, this is just a simple HTML file - we will modify it to include dynamic content later on. Now run ant reload. Now you should be able to test the action by pointing your browser to http://localhost:8080/eventmanager/eventlist.action - you should see the "Success" headline in your browser. + + + + The "Open Session in View" pattern + + When using such features as lazy loading, Hibernate needs an open session. To do this easily in a web application we will use a simple pattern. We will create a servlet filter which will manage our session and close it at the end of the web request. Also we improve our HibernateUtil class to include transaction handling per-thread: + + + + We can now use this methods to do all Session and Transaction handling in a Servlet Filter called SessionManager: + + + + Let's look at what is done here: The HibernateUtil class will store a Hibernate session in a ThreadLocal variable. A ThreadLocal will contain an instance of a variable once for every thread. So if there are two parallel Threads executing, the ThreadLocal will contain two session. In SessionManager, the doFilter method will be invoked on every request. It will let the request go on by calling chain.doFilter(). After the request processing finished and chain.doFilter() returns, it retrieves the Session for the current thread from the ThreadLocal and closes it. It also commits the transaction - if the transaction was already committed or rolled back, HibernateUtil will simply do nothing. + + + Our Actions can invoke the static currentSession() method of the HibernateUtil class to get a Session - if it is invoked multiple times during one thread, the same session will be used every time. + + + The HibernateUtil.rollbackTransaction() method can be invoked by our Actions to have the transaction rolled back. + + + Also in the destroy() method of the filter, we once again do our hsqldb-housekeeping work. + + + We have to modify the classpath in our build.xml compile target to get this to work: + + + + + + + + + + + + + + ]]> + + Finally, we have to configure the filter in the web.xml: + + + + + Eventmanager + + + sessionmanager + de.gloegl.road2hibernate.util.SessionManager + + + + sessionmanager + action + + + + action + webwork.dispatcher.ServletDispatcher + 1 + + + + velocity + webwork.view.velocity.WebWorkVelocityServlet + + + + action + *.action + + + + velocity + *.vm + + + + index.html + +]]> + + + Accessing Hibernate from the action + + So now we have set up our supporting framework, we can finally start to use Hibernate for loading data in our action: + + + + We simply retrieve the session from our HibernateUtil, and load the list of Events using session.find(). Then we assign it to an attribute of our action. Now we can use this attribute from our eventlist.vmview: + + + + Event List + + +

Events

+
    + #foreach( $event in $events ) +
  • $event.title
    • + #end +
+ +]]> + + Using the velocity template language, we simply iterate over the events, and print their titles. Now that our infrastructure is in place, you see how easy it is to create actions and views. If you now call http://localhost:8080/eventmanager/eventlist.action, you will see most likely nothing - because we have no events in the database. So we will create another action to create events. + + + But at first we will finally create an index.html file, where we link our actions - place it in the static-web subdirectory of the project: + + + + Hibernate Event Manager + + + +

Hibernate Event Manager

+ + + +]]> + + Next, we will create the NewEvent action: + + + + As you see, this action has two doXXX() methods. The reason is we will use WebWorks ability to invoke different methods of the action class. Lets have a look at the xwork.xml first: + + + + + + + + + + + + /WEB-INF/views/eventlist.vm + + + + index.html + /WEB-INF/views/newEventForm.vm + + +]]> + + So we have now a new action called newevent. This action has two results, the success result (which is returned by the execute() method) and the input result (which is returned by the doEnter() method). If you look at the index.html you will notice the link to "newevent!enter.action" - this tells WebWork to invoke the enter() method in the action. The submit-target of our form however will just link to "newevent.action", invoking the default execute() method. + + + Finally we need to code the newEventForm.vm view file we specified, again in the views directory: + + + + Event List + + +

New Event

+
+ + + + + + + + +
Title:
+
+ +]]> + + If you now go to http://localhost:8080/eventmanager now, you should get an index page from where you can create new Events and list them. + + + Thats it for this tutorial, if you want to dive in deeper into Hibernate, read on for the reference manual. + + + + + + \ No newline at end of file