here is a "rad" version of phonebook. just wicket and hibernate. i had to only write two small classes to implement a session-per-request pattern, see wicket.contrib.phonebook.web.h3 package. are those two classes the "framework" we need?

On 11/20/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
as far as i can see 90% of wicket.contrib.data.model in wicket-contrib-data is about creating a database-backed list for the listview. same can be solved much more elegantly with the dataview.

What does wicket-contrib-hibernate get me besides a shiny object model that stores more in the session then some small pojos? The biggest flop, though, is that i still have to provide all the plumbing myself - if anything, a hibernate framework should solve that.

Maybe calling it obsolete was a bit too harsh, i apologize if i hurt anyone's feelings. But can we point to it and say that this is our official way to do RAD integration with hibernate? i honestly hope no one would. That is why in my previous email i asked for a concrete list of features/requirements so that we can put something together that will please most people, call it official, and put this issue to rest once and for all.


-Igor




On 11/20/05, Eelco Hillenius < [EMAIL PROTECTED]> wrote:
I don't agree with wicket-contrib-data being obsolete. What happened
is that I created some basic Hibernate support classes last year, and
that other people commented that they didn't like them so much, and
wanted to add alternatives. From there it grew into the bunch a quasi
related classes it is now. I still think classes like
HibernateObjectModel are pretty useable. You may argue about how
elegant the choices as hibernate session delegate etc are, and you may
even argue that it is not best practice to bind to Hibernate in your
view layer. But not every project has to display the perfect
seperation of (service) layers and these classes gives users the
opportunity to go for a more RAD approach. Depending on how much Phil
(and did other people work on that project?) wants to keep, we could
do a clean-up and keep only the classes we still think are usuable.

We don't have to promote the project as best practices, but saying
it's obsolete goes a bit too far.

Eelco


On 11/20/05, Igor Vaynberg < [EMAIL PROTECTED]> wrote:
> wicket-contrib-data and wicket-contrib-data-hibernate do not provide any
> form of transaction management. furthermore, they are obsolete due to
> repeater package (what used to be wicket-contrib-dataview) in
> wicket-extensions.
>
> 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.


-------------------------------------------------------
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_idv28&alloc_id845&opclick
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user


Attachment: phonebook-h3only-1.0-SNAPSHOT-src.jar
Description: application/java-archive

Reply via email to