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
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
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
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
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();
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
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
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
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
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
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
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
12 matches
Mail list logo
