Re: [Wicket-user] Re: There must be some docs somewhere?
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. I wasn't looking for a binding between wicket and a persistence layer. However, given that ever increasing numbers of projects are using ORM frameworks, which are all too likely to allow lazy initialization of relationships, it would be nice to have a best practices solution to the problem of closing an open session or transaction that is necessary in order to allow lazy instantiation. In reality, such a solution is unlikely to involve binding anything other than a config file to Spring/Hibernate, something like a servlet-plugin in web.xml, for instance. My point isn't that this is necessarily a difficult problem to solve, but that it would be nice to establish best practices methodology, especially for those who are investigating a new technology and want to get a sense of how it will work with their other tools without having to spend 2 weeks learning a framework. The same goes for the problem of detaching and reattaching to model objects which are dynamically loaded at request time, rather than being stuffed, in their entirety, into a session. This is particularly important when clustering servlet containers and serializing sessions between servers. Such code doesn't need to be bound directly to the ORM framework, but there does need to be some mechanism for business objects to be replaced by some kind of id and then be able to re-instantiate those objects prior to servicing subsequent requests. Wicket apparently has such a mechanism, so why not provide a suggestion about how to use it? And yes, the phonebook example does exactly that with the DetachableContactModel object, but it took me nearly 2 weeks to discover it. Let's face it, if Wicket is going to be taken seriously as as an interface framework for J2EE apps, it is going to have to integrate well with Spring and Hibernate, allowing a developer to extract maximum benefit from those frameworks. Of course, odds are very good that it already does, but that is entirely NOT evident to a new user. Establishing a best practices document not only gives new users a starting point when starting a new project, but it assures them that the integration they desire is readily available. Meanwhile, I'm probably heading off to Tapestry. As much as I like wicket, without viable documentation, I can't risk using it at this stage in its development. I can't bear the thought of a struts-style MVC framework, so Tapestry appears to be the only well documented, mature, J2EE interface framework with a community of developers large enough for me to want to risk using it, even if it is possibly my least favourite component based framework. And folks, please don't neglect the value of solid documentation. Wicket has a ton of potential, but I've seen some very promising open source projects fall by the wayside almost entirely because they weren't accessible enough to users that decisionmakers were willing to gamble on their use. I'll be keeping an eye on wicket's progress, and look forward to the day when I can migrate to the framework. --sam --- 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_idv28alloc_id845op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Re: There must be some docs somewhere?
Hi Sam, I find it unfortunate that you choose another framework, but at least you are moving away from MVC :-). I really appreciate your comments on (the structure of) the documentation. If you have other comments, please provide them, as they will enable us to make Wicket the framework you would like to use ;-). Let's face it, if Wicket is going to be taken seriously as as aninterface framework for J2EE apps, it is going to have to integrate well with Spring and Hibernate, allowing a developer to extractmaximum benefit from those frameworks. A true statement, and it already does :-), but we don't have lots of articles or books on the subject (yet). Of course, odds are very goodthat it already does, but that is entirely NOT evident to a new user. And we will be fixing this (sooner than later). Establishing a best practices document not only gives new users astarting point when starting a new project, but it assures them that the integration they desire is readily available. And folks, please don't neglect the value of solid documentation. And we are working on that, thanks to you we know now that the structure should be improved, and that there should be some article on how to use Wicket with Hibernate, and Spring. Don't be a stranger. You are not the only one taking a look at Wicket, but you are among the few that actually gave feedback. I find that very valuable. Thanks. Martijn
Re: [Wicket-user] Re: There must be some docs somewhere?
I think before writting a how-to doc it would be intresting for all what is a good-practice for setting up hibernate/spring/wicket. So I'd like to ask what is your best practice to for hibernate/spring/wicket? I currently first take basicly the same hibernate/spring setup as in wicket-contrib-examples-hibernate3 (pretty basic) - with session per request. Than write getters in the Applicaton for the spring-beans. The getters wrap the spring-beans using the wicket-contrib-spring LazyInitProxyFactory (wicket-contrib-spring). Than use for all Entity Models the (a bit modified) HibernateModel (wicket-contrib-data-hibernate3) and the HibernateDataProvider. My DAO implements IHibernateDAO. (That's all I use from the contrib-data packages). Than use for all non pageable lists an OrderedRepeatingView. This is IMO the most straight to use without much models and indirection - otherwise a DataView. Christian On Sun, 20 Nov 2005 15:19:51 -0800, 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. 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
Re: [Wicket-user] Re: There must be some docs somewhere?
Than use for all non pageable lists an OrderedRepeatingView. This is IMOthe most straight to use without much models and indirection - otherwise a DataView.dont know how useful an ordered repeating view would be for database driven lists since it doesnt refresh its children every request like dataview, so be careful there. -Igor
Re: [Wicket-user] Re: There must be some docs somewhere?
dont know how useful an ordered repeating view would be for database
driven
lists since it doesnt refresh its children every request like dataview,
so
be careful there.
I have my own subclass:
MyORView extends OrdereredRepeatingView{
void internalOnBeginRequest(){
removeAll();
populate();
}
abstract populate();
WebMarkupContainer addContainer(IModel model){
WebMarkupContainer cont = new WebMarkupContainer(newChildId(),model);
add(cont);
return cont;
}
}
And than it is easy:
add(new MyORView(id){
void populate(){
ListProduct list = _productsDAO.loadProducts();
for(Product prod:list){
Model model = new HibernateModel(prod,_hibernateDAO);
WebMarkupContainer cont = addContainer(new
CompoundPropertyModel(model));
cont.add(new Label(name));
}
}
});
-Igor
--
Christian Essl
___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
---
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=7628alloc_id=16845op=click
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Re: There must be some docs somewhere?
Whatever. I must be starting to suffer from that famous open source fatigue; I'm getting tired of that integration stuff. I'd hope there would be more emphasis on core issues. Anyway, if there's a bunch of people that agree on method x, and at least one core developer regards that as a 'best practice', I'm fine with deleting the rest for clarity. And once we have that, let's finally put out an 'official release' and promote it as such. Eelco 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_idv28alloc_id845opclick ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net 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_idv28alloc_id845op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Re: There must be some docs somewhere?
that would do it :]-IgorOn 11/21/05, Christian Essl [EMAIL PROTECTED] wrote:
dont know how useful an ordered repeating view would be for database driven
lists since it doesnt refresh its children every request like dataview, so be careful there.I have my own subclass:MyORView extends OrdereredRepeatingView{ void internalOnBeginRequest(){
removeAll(); populate(); } abstract populate(); WebMarkupContainer addContainer(IModel model){ WebMarkupContainer cont = new WebMarkupContainer(newChildId(),model); add(cont);
return cont; }}And than it is easy:add(new MyORView(id){ void populate(){ ListProduct list = _productsDAO.loadProducts(); for(Product prod:list){
Model model = new HibernateModel(prod,_hibernateDAO); WebMarkupContainer cont = addContainer(newCompoundPropertyModel(model)); cont.add(new Label(name)); } }
}); -Igor--Christian Essl___Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden:
http://mail.yahoo.de---This SF.Net email is sponsored by the JBoss Inc.Get Certified TodayRegister 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=7628alloc_id=16845op=click
___Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Re: There must be some docs somewhere?
I like it because it always saves you one model and if you just display
data from the db with some links than you do need no models at all. It is
also easy to make it pageable.
A question: is the ItemReuseStrategy (OIR) still needed for forms and
feebackpanels, because it seems also to work with removeAll()?
Christian
On Mon, 21 Nov 2005 10:29:15 -0800, Igor Vaynberg
[EMAIL PROTECTED] wrote:
that would do it :]
-Igor
On 11/21/05, Christian Essl [EMAIL PROTECTED] wrote:
dont know how useful an ordered repeating view would be for database
driven
lists since it doesnt refresh its children every request like
dataview,
so
be careful there.
I have my own subclass:
MyORView extends OrdereredRepeatingView{
void internalOnBeginRequest(){
removeAll();
populate();
}
abstract populate();
WebMarkupContainer addContainer(IModel model){
WebMarkupContainer cont = new WebMarkupContainer(newChildId(),model);
add(cont);
return cont;
}
}
And than it is easy:
add(new MyORView(id){
void populate(){
ListProduct list = _productsDAO.loadProducts();
for(Product prod:list){
Model model = new HibernateModel(prod,_hibernateDAO);
WebMarkupContainer cont = addContainer(new
CompoundPropertyModel(model));
cont.add(new Label(name));
}
}
});
-Igor
--
Christian Essl
___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier
anmelden: http://mail.yahoo.de
---
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=7628alloc_id=16845op=click
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
--
Christian Essl
___
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
---
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=7628alloc_id=16845op=click
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Re: There must be some docs somewhere?
On 11/21/05, Christian Essl [EMAIL PROTECTED] wrote: A question: is the ItemReuseStrategy (OIR) still needed for forms andfeebackpanels, because it seems also to work with removeAll()?really depends on what you are doing.the component handlers are called before the onbeginrequest of the page and its components, so while the event handler is operating on the dataview its items are still intact from the previous request. The items wont be refreshed until after the event handler is done, so no need to keep them around via a strategy. on the other hand, if the event handler modifies the Item ( you want to show feedback in the row or something) and you want that change to still be available during render, you need a strategy to keep the item around otherwise it will be recretead in onbeginrequest handler. does this clear it up?-Igor
Re: [Wicket-user] Re: There must be some docs somewhere?
That clears it up thanks Christian On Mon, 21 Nov 2005 12:04:26 -0800, Igor Vaynberg [EMAIL PROTECTED] wrote: On 11/21/05, Christian Essl [EMAIL PROTECTED] wrote: A question: is the ItemReuseStrategy (OIR) still needed for forms and feebackpanels, because it seems also to work with removeAll()? really depends on what you are doing. the component handlers are called before the onbeginrequest of the page and its components, so while the event handler is operating on the dataview its items are still intact from the previous request. The items wont be refreshed until after the event handler is done, so no need to keep them around via a strategy. on the other hand, if the event handler modifies the Item ( you want to show feedback in the row or something) and you want that change to still be available during render, you need a strategy to keep the item around otherwise it will be recretead in onbeginrequest handler. does this clear it up? -Igor -- Christian Essl ___ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de --- 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=7628alloc_id=16845op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Re: There must be some docs somewhere?
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. 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. -IgorOn 11/18/05, Nathan Hamblen [EMAIL PROTECTED] wrote: I don't think we all agree about Spring's role in Wicket. It's fine tosay that Spring will open and close Hibernate transactions if you wantto use it, but that's not a good reason to delete projects that do the same thing without Spring.NathanIgor 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
Re: [Wicket-user] Re: There must be some docs somewhere?
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_idv28alloc_id845op=click ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
