David Tashima wrote:
Well the way I use it, I persist the same beans that are bound to UI
elements, so when you change UI elements, you're changing the actual
thing that ends up being persisted into the DB.
The tricky part is to 1) close your Hibernate session with a servlet
filter; 2) you have to reassociate the object to the current session
As for the closing, no servlet filter is required...
you can do it with spring as well, spring has mechanims for that
in place which you can introduce on DAO level.
before saving (just b/c the ID of an object corresponds to something
that lives in the database, it won't automatically figure out how to
save stuff).
Yes reassociating is necessary, but the beauty of the hibernate-jsf
combo is, that you just shift the plain database objects around
and even significant name changes on the db side wont affect your
controls, like it usually is a problem with plain relational control
mapping, because you can cover that on the hibernate.xml config file
level in the worst case.
The main problem I faced with the integration of hibernate into
the JSF context was, to figure out how to deliver data
into a data table until somebody gave me the hint of implementing a
hibernated DataModel class.
The main problem with the DataModel is, that the API is just plain awful
in a Hibernate context if you follow the approach of keeping connections
open just for short periods of time.
I basically had to preload the data into a chache due to API constraints
of the datamodel and deliver the Hibernate POJOs from the cache into the
forms (and refill the cache if I run out of objects), and I did not have
a chance to get the current pageSize directly, so that I could
adjust my internal prefetch cache.
The main problem simply is, that the api follows a flow like that:
a) first set the init params, request the number of possible objects
then
call give me an object from the model
increase the internal position counter over a separate object
and so on
If you want to fetch as much objects as possible within one
transaction/session boundary, this approach is plain awful, as I said.
It would have been easier for everybody with a workflow like that:
set the init params, request the size
request objects x-y from the model and rerequest the size
That way you could use paging on the mapper level....
To sum it up, the API for the current JSF datamodel, simply and
plainly stinks (but so does the API for custom controls as well)!
This is JSF after all, once you leave the high level of good components
you basically run into API and code artefact hell at every level :-(
