also, this discussion did not have much to do with spring itself, but with the fact that it isnt the greatest idea to tightly couple your persistence layer with your ui layer, because that forces your business logic to live inside the ui. i am familiar with spring so that is what i chose to build the example of how not to do that, same functionality can be accomplished with a slew of other technologies.
so far all i see is whining that we should have a wicket/hibernate integration framework, but no one has actually pointed out what features/functionality it should provide. so how about something more concrete? and an explanation of why wicket - a user interface framework - should provide transaction management services.
-Igor
On 11/18/05, Nathan Hamblen <[EMAIL PROTECTED]> wrote:
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
