I don't think we all agree about Spring's role in Wicket. It's fine to
say that Spring will open and close Hibernate transactions if you want
to use it, but that's not a good reason to delete projects that do the
same thing without Spring.
Nathan
Igor Vaynberg wrote:
irt spring+hibernate+wicket:
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] <mailto:[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
<http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click>
_______________________________________________
Wicket-user mailing list
[email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
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
