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
