You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Sam Hough <sa...@redspr.com> on 2007/10/01 13:35:49 UTC

Re: auto dirty and widget factory

Can I use:
Component.checkHierarchyChange(final Component c) 
or should that really have been marked final?

On the "what if they don't call super". Has anybody seen anywhere some
annotation that insists that people who override that method call super?
Seems like a common problem. I have often spent time wondering why my
servlet wasn't getting config because I was stupid... @Override is really
nice but maybe need an annotation for super class method? e.g.
@MustCallSuper



Johan Compagner wrote:
> 
> i think thatwe will change the interface of the change tracker but we
> will keep it at some level for page versions (and abusing dirty() for
> that doesn't have my vote) But something like:
> Page.componentChanged(Component) looks nice to me and then auto dirty
> of components is also possible
> 
> On 9/29/07, Martijn Dashorst <ma...@gmail.com> wrote:
>> The jury is still out on the change tracker. It will at least be part
>> of Wicket 1.3 and our JDK 1.5 release, as that one should only be
>> about generics (at least that is still the plan). So it will be there
>> for at least 1.3 and the next one.
>>
>> If your application is still dependent on that functionality, then
>> raise the concern when we are going to remove it. If we have usecases
>> for a particular functionality, then we are not going to remove it on
>> a whim. According to this thread, at least Johan is quite keen to keep
>> it in place :)
>>
>> Please note also that maybe in the version after the generics version,
>> we may come up with a way to do what you want, and provide that
>> functionality out-of-the-box. But currently we are trying to finalize
>> a release and ship it.
>>
>> Martijn
>>
>> On 9/29/07, Sam Hough <sa...@redspr.com> wrote:
>> >
>> > 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 <sa...@redspr.com> 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 <jc...@gmail.com> 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 <ee...@gmail.com> wrote:
>> > >> >> >
>> > >> >> > On 9/26/07, Johan Compagner <jc...@gmail.com> 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: users-unsubscribe@wicket.apache.org
>> > >> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> > >> >> >
>> > >> >> >
>> > >> >>
>> > >> >
>> > >> >
>> ---------------------------------------------------------------------
>> > >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > >> > For additional commands, e-mail: users-help@wicket.apache.org
>> > >> >
>> > >> >
>> > >> >
>> > >>
>> > >> --
>> > >> 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: users-unsubscribe@wicket.apache.org
>> > >> For additional commands, e-mail: users-help@wicket.apache.org
>> > >>
>> > >>
>> > >
>> > >
>> >
>> > --
>> > 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: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>>
>>
>> --
>> Buy Wicket in Action: http://manning.com/dashorst
>> Apache Wicket 1.3.0-beta3 is released
>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12977564
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org