If it's largely internal, just change instead of deprecating.
My 2c Eelco On 4/29/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
no harm. IMO deprecating them is the saver and hence better solution, but that is only my opinon and I wonder what others think. I didn't want to push it. Juergen On 4/29/06, Johan Compagner <[EMAIL PROTECTED]> wrote: > so no deprication? > What is the harm in depricating them? > > johan > > > > On 4/29/06, Juergen Donnerstag < [EMAIL PROTECTED]> wrote: > > > Currently when you add a panel which markup has <wicket:head> and > <body onLoad=".."> wicket will automatically add an attributemodifier > (AM) to the <body> MarkupContainer. When you now remove that Panel or > replace it with whatever the AM will remain attached to the <body> > container (we've got a bug open for that), which of course is wrong. > > While trying to fix it: > The AM is attached to the body, but the Panel is the relevant > component. Hence, if we want to remove or disable the AM we must > provide it the panel component and test in newValue() whether the > Panel still has a parent/page. If not, it has been removed or > replaced. This requires to change the signiature of > BodyContainer.addOn(Un)LoadModifier(String/Model) to include the > Panel. Instead changing it, we can as well provide additional ones in > BodyContainer (no need to change/break the API). > > We could add Component.remove(IBehavior) (which has been requested on > the list recently). That is easy enough, but trying to remove the AM > in AttributeModifier.rendered(Component) causes an exception as it is > called inside an AM-Iterator. Hence, I went with AM.setEnable(false) > which however means that the AM keeps maintains a reference to a > Component which was removed and which memory could be garbage > collected if there wasn't anymore reference to it. To avoid that and > to allow the component to be GCed, I put it into a WeakReference. > > I've created a test case and I think it works. > > Because using the methods without the extra component parameter is > kind dangerous, I wonder if we should deprecate them or rather make > the javadoc very explicit. They are dangerous as only the new ones > properly disable the AM which of course is only required if the > component gets removed or replaced. For 1.2 I suggest we go with the > additional methods and javadoc. Is that ok? > > Juergen > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmdlnk&kid0709&bid&3057&dat1642 > _______________________________________________ > Wicket-develop mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmdlnk&kid0709&bid&3057&dat1642 _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642 _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
