Dan is absolutely correct when he says that wicket should never touch hibernate directly. all the hibernate-related logic should stay inside spring and be exposed directly through a dao object or through a service facade. i think wicket-contrib-data and wicket-contrib-data-hibernate should be taken out of cvs as they do not display good programming practices in general. i thought Phil was going to do that, but i guess he never got around to it, are you reading Phil?
take a look at wicket-phonebook in wicket-stuff, its an extremely simple crud application that uses the above technologies. it also has excellent javadoc thanks to Gwyn.
irt general dao:
if you are talking about pulling out data from the database to display, such dao already exists and is documented. look up: IDataProvider in wicket-extensions. it is used by the DataView component which is also in the extensions. to see a demo of these look in wicket-phonebook or wicket-examples - repeaters. the repeater examples build upon each other from a simple looping view to a fully database driven datatable component.
irt spring integration:
spring integration doesn't come easy with a framework like wicket. unlike servlets which are fairly static singletons wicket applications consist of a lot of volatile objects with varying life cycles. this makes keeping dependencies difficult especially because objects are often serialized. there are basically two approaches: simpler approach is to keep all your dependencies in wicket's singleton Application object and let everything else look up dependencies from there, the other approach is more sophisticated - it involves creating proxies for dependencies that can be serialized and retain enough information to be able to look up the dependency when they are deserialized (possibly in another vm). i recently wrote up an article on this in the wiki that describes the two ways: http://www.wicket-wiki.org.uk/wiki/index.php/Spring i haven't had much time to spend on it so its rough around the edges. people should feel free to fix it, it is a wiki after all.
irt detaching:
the whole idea of detaching objects is to reduce session state. if you have a pretty big object that you are using as a model, why keep it in session when you can only keep the id and load the object when it is fist accessed. if you are using the object as a model for the form, then you don't need to reattach/lock it, just use hibernate merge instead of saveorupdate. see wicket-phonebook for both use cases.
irt trail tutorial:
if someone can come up with a scope/spec for a small wicket+hibernate+spring application / trail breakdown i can put one together as long as other people promise to write documentation, some javadoc, and dress up the html templates.
-Igor
On 11/17/05, Dan Gould <[EMAIL PROTECTED]> wrote:
Sam Gendler wrote:
...
> The nice thing is that if
> examples use a fairly generic DAO abstraction, it should be possible
> to provide nice examples that aren't dependant upon any particular
> suite of technologies. Just describe the DAO interface and then use
> those them to access standard POJOs. Obviously, most folks will
> probably be doing a Hibernate/Spring thing, so addressing best
> practices for combin ing those technologies with Wicket is enormously
> valuable, but it should be secondary to providing generic best
> practices for dealing with DAO access, detachability, etc.
...
> 1. hibernate/spring integration (separate from wicket)
> 2. hibernate/spring/wicket best practices
Sam -- all of what you propose sounds excellent.
[The tradional example has been the pet shop, but nowadays, I think a
blogging system is a nice worked example for a web framework.]
I haven't had a chance to look at Igor, et al's new Spring integration,
but here are a few bits of advice from my experiments with
Wicket/Spring/Hibernate:
- If you're using Spring to manage your DAOs, you don't need to look at
wicket-contrib-hibernate.
- Spring and Hiberate already integrate together really easily. Take a
look at org.springframework.orm.hibernate3.LocalSessionFactoryBean. They
should have plenty of examples, but if you need a more complete
spring.xml, let me know and I'll send you one.
- To map Hibernate sessions to requests, Spring AOP's
OpenSessionInViewInterceptor makes everything automatic. Here's what I
use:
<!-- The openSessionInViewInterceptor is for Wicket requests; the HibernateInterceptor
is for business objects -->
<bean name="openSessionInViewInterceptor"
class="org.springframework.orm.hibernate3.support.OpenSessionInViewInterceptor ">
<property name="sessionFactory"><ref bean="sessionFactory"/></property>
<property name="flushModeName"><value>FLUSH_AUTO</value></property>
</bean>
- For an example of Transaction Templates, take a look at
http://blog.exis.com/colin/archives/2004/07/31/concise-transaction-definitions-spring-11/
- If you can get to the DAOs from your pages or models and your Sessions
are managed correctly, using them with Wicket is very easy.
- I'm not yet sure what the best practice for detatching is. If you have
relatively small objects and plety of RAM, you could use hibernate's
lock() function to attach to the current Hibernate session. Most likely,
though, having your models keep the id of the object and loading them from the
DAO maks the most sense.
Good luck,
Dan
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
