lol, welcome to the conversation. i have already implemented such a check,
and this whole conversation is about the pros and cons of this check.
-igor
On 1/4/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
For this line they are, but when MyOtherComponent extends MyComponent,
the ballpark changes a bit:
Assume:
public class MyComponent extends Component {
protected void onattachhandler1() {//foo }
protected void onattachhandler2() {//bar}
}
public class MyOtherComponent extends MyComponent {
protected void onattachhandler3() { // beer }
}
then:
public MyOtherComponent() {
add(new IAttachListener() { public void onAttach() {
onatachhandler3(); }
}
is not equivalent to:
public void MyOtherComponent:onAttach() {
onattachhandler3();
}
because it requires you to add a call to super(). This can/will be
forgotten.
If we do so, we could add a detection system in the
Component.onAttach()/onDetach() methods that super is actually called,
with a possibility to disable that check, and would only perform such
a check in development mode (just like the serialization now).
something like:
Component.onAttach() {
if(isAttachCalled() != null) {
setAttachCalled(true);
}
}
Component.isAttachCalled() {
// defaults to true, subclasses that allow overriding can
// return NULL.
return false;
}
somewhere in the request cycle:
if(settings.isAttachCheckEnabled()) {
page.visit(new AttachChecker() { if(!component.isAttachCalled())
throw ... } );
}
Martijn
On 1/4/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> all these method are equivalent, suppose
>
> public class MyComponent extends Component {
> protected void onattachhandler1() {//foo }
> protected void onattachhandler2() {//bar}
> }
>
> now:
> public class MyComponent extends Component {
> protected void onattach() { onattachhandler1(); onattachhandler2(); }
> protected void onattachhandler1() {//foo }
> protected void onattachhandler2() {//bar}
> }
>
> annots:
> public class MyComponent extends Component {
> protected void onattachhandler1() {//foo }
> @OnAttach protected void onattachhandler2() {//bar}
> }
>
> listeners:
> public class MyComponent extends Component {
> public MyComponent(...) {
> add(new IAttachListener() { public void onAttach() {
> onattachhandler1(); onattachhandler2(); }}
> }
>
> protected void onattachhandler1() {//foo }
> protected void onattachhandler2() {//bar}
> }
>
> personally i like the current one, its simpler
>
> the thing is that we should factor out all the behavior that needs to be
> overridable out of the onattach() methods, like i did for the listview
just
> now. and yes, if it is not meant to be overridden then use a different
> component.
>
> -igor
>
>
> On 1/4/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
> >
> > On 1/4/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > > ahh, but then you are back to the exact same problem. how do you
> > override
> > > behavior that was added via an anonymous ILifecycleListener (or
whatever
> > you
> > > call it) :) the solution is the same as for the current onattach()
> > problem,
> > > and for annotations approach - behavior that is meant to be
overridable
> > > needs to be factored out into a separate method.
> >
> > Not completely: the problem we are discussing is not methods that need
> > to be overridden, but overridable methods that are implemented, but
> > still need to be called.
> >
> > With the chain (and the annotations) we avoided that particular aspect
> > of the problem.
> >
> > The thing you are talking about is disabling a particular behavior. In
> > that case, I think creating a new component might be a better
> > solution, as you are truly not extending the original design of a
> > component, but tinkering with the intended behavior to which the
> > component was designed.
> >
> > If you still want to re-use that particular component, then the common
> > functionality should be extracted to a base, without the undesired
> > behavior.
> >
> > Currently the problem is not that some feature needs to be disabled,
> > but that some necessary code has to be called for the component to
> > work correctly. Registering the handlers (through annotations or chain
> > of commands) does solve this particular problem without the need for
> > reading and correctly interpreting javadocs.
> >
> > Martijn
> >
> > --
> > Vote for Wicket at the
> > http://www.thebeststuffintheworld.com/vote_for/wicket
> > Wicket 1.2.4 is as easy as 1-2-4. Download Wicket now!
> > http://wicketframework.org
> >
>
>
--
Vote for Wicket at the
http://www.thebeststuffintheworld.com/vote_for/wicket
Wicket 1.2.4 is as easy as 1-2-4. Download Wicket now!
http://wicketframework.org
