I would be happy with a 90% solution that was very simple and that was what I was after. Something like the change tracker would be lovely but it seems in doubt if that will even exist for long. I won't raise this issue again.
Thanks for your time. Johan Compagner wrote: > > i have told you now i think at least 3 times > only be able to override those methods WONT i repeat again WONT help you > completely > those are not the only events that could get a component to be dirty. > there are lots more especially when you also take into account the none > core > stuff. > > Something like the change tracker is the way to go. > > > johan > > > > On 9/29/07, Sam Hough <[EMAIL PROTECTED]> wrote: >> >> >> Errr. Should I take from all this not to use the page versioning and that >> I >> shouldn't hold my breath for final being removed from anywhere? >> >> I know you are all sick of this topic, poor old Eelco, but seems like a >> simple, efficient and flexible way for me to add hooks is to extend >> objects. >> If you mark methods as "extend at own risk" and I go down a stupid route >> that is my own stupidity. At least I can get something reasonable working >> in >> the short term even if it can be done better later. I'm a good boy so I >> have >> lots of unit and functional tests to catch mistakes later. >> >> Sorry that I'm struggling with the wicket way. To add to my confusion I'd >> rather onClick, onSubmit etc were interfaces so I could choose if I >> wanted >> them in the component (to reduce numbers of objects) or anywhere I like. >> >> >> Matej Knopp-2 wrote: >> > >> > On 9/27/07, Johan Compagner <[EMAIL PROTECTED]> wrote: >> >> the problem is that that still not really does auto dirty.. >> >> Because where does it end? just add/remove/visitble/enable? >> >> The nice thing is we have already something like that: thats page >> >> versioning >> >> with the undo/change map. >> > Don't get too attached to it :) We should remove it in the next >> > version, doesn't make much sense for 2nd level cache session store :) >> > >> > -Matej >> > >> >> If we extend that a little bit then we could have something like >> >> componentChanged(component) on a page (or somekind of listener) >> >> and that component did trigger it self what ever did happen on it >> >> (getting a >> >> child, settting the visibility, or setting an internal none wicket >> core >> >> property) >> >> >> >> johan >> >> >> >> >> >> >> >> On 9/26/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: >> >> > >> >> > On 9/26/07, Johan Compagner <[EMAIL PROTECTED]> wrote: >> >> > > but this discussion is not just about getter/setters (i don't care >> >> about >> >> > > those) >> >> > > but also for add and remove.. then we are getting into some other >> >> stuff >> >> > >> >> > Yes. Getters/ setters are less tricky. Though I'm still not breaking >> >> > in sweat when I imagine removing final on add and remove. >> >> > >> >> > Eelco >> >> > >> >> > >> --------------------------------------------------------------------- >> >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> > For additional commands, e-mail: [EMAIL PROTECTED] >> >> > >> >> > >> >> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12954673 >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > -- View this message in context: http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12955648 Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
