these are all sensitive methods where an override can break a contract, so i dont know what your chances are. the thing to do is to create a jira issue and then we can discuss/vote on it on the list.
personally i do not like making add/remove nonfinal, but maybe we can provide additional hooks. i have mixed feelings about set* methods. -igor On 9/26/07, Sam Hough <[EMAIL PROTECTED]> wrote: > > > Igor, > > What are my chances of getting setVisible, setEnabled, add, addOrReplace > and > remove, removeAll made non-final? > > I'd like to hook into them to track dirty components... The best > alternative > I've come up with so far is to iterate through all the components and keep > a > copy of their old state :( Nice in that it will be smart about > setVisible(false); setVisible(true) but not sure that is worth it. > > btw I still love Wicket and the kids even if my true love, that can never > be, is GWT. AjaxFallbackX works very nicely. > > > igor.vaynberg wrote: > > > > looks reasonable. > > > > -igor > > > > > > On 9/12/07, Sam Hough <[EMAIL PROTECTED]> wrote: > >> > >> > >> Would RequestCycle be the place to keep track of dirty widgets? > >> > >> Presumably Session can be shared by more than one session and my be > used > >> by > >> multiple threads at the same time? > >> > >> > >> > >> Sam Hough wrote: > >> > > >> > Apologies in advance as I'm a newbie harking on about my pet topic > >> again > >> > but... > >> > > >> > Taking the example of TabbedPanel and AjaxTabbedPanel (only in > >> extensions > >> > but a common UI concept) I think it shows why it would be good to use > >> the > >> > factory pattern to generate elemental widgets (like button, panel etc > >> > assuming people want AjaxFallbackButton or Button) and automatically > >> track > >> > dirty components. > >> > > >> > I first got this bee in my bonnet about higher level application code > >> > because I didn't think I should be messing about working out which > >> > components were dirty when I just want the result of pressing a > button > >> to > >> > fiddle with the model and change the ui state a bit. However looking > at > >> > *TabbedPanel I think it would also make sense for pure UI components. > >> > Using inheritance to add Ajax to TabbedPanel means any other > variations > >> > also have to be doubled (e.g. AjaxFancyTabbedPanel and > FancyTabbedPanel > >> > etc). Perhaps the bigger problem is that if a Panel that is meant to > be > >> > inside a TabbedPanel and needs to alter another component (e.g. > update > >> > navigation component) the TabbedPanel has to ask it for changes. > >> > Presumably a component should be self contained as possible so it > >> doesn't > >> > matter what other component it is contained within. > >> > > >> > Factory pattern is a pain but presumably many people don't want the > >> > overhead of AjaxFallbackXXX. It would also make it possible to > program > >> > against interfaces which might give more power to Igor, Eelco etc > >> > > >> > Please don't get me wrong GWT is still my true love but Wicket is a > >> > fabulous framework taking us out of the dark ages of struts. > >> > > >> > > >> > > >> > >> -- > >> View this message in context: > >> > http://www.nabble.com/auto-dirty-and-widget-factory-tf4421187.html#a12640270 > >> 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#a12895965 > Sent from the Wicket - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
