Hi,
since I've been struggling with wicket attaching/detaching for more than a
month (I'm developing some models which rely on being properly detached),
I'll share my thoughts on this issue:-)
> but now that i think about it, i think i would be ok with removing
> onattach() altogether. the reas
any others have an opinion about
http://issues.apache.org/jira/browse/WICKET-151 ?
Eelco
On 1/4/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
sounds pretty good to me. the main other question to ask is how
much code this would break and how easy that would be to detect.
and of course how to educate users about it. any thoughts on those
things?
i dont know how much code it wou
sounds pretty good to me. the main other question to ask is how
much code this would break and how easy that would be to detect.
and of course how to educate users about it. any thoughts on those
things?
igor.vaynberg wrote:
>
> yeah, you got it
>
> attach means you attach any resources you
yeah, you got it
attach means you attach any resources you might need. a better way to think
about it is the opposite of detach() in the model - everyone is familiar
with that one. i honestly do not see many use cases for onattach, most of
the time i use the lazy loading pattern so all i really n
no matter what we decide, we should beef up the javadoc for these
two methods to really detail the intent of their use so people put their
code in the right place in the future.
Jonathan Locke wrote:
>
>
> actually, it's onBeforeRender. this is a hint for sure to users that
> you ought to be
actually, it's onBeforeRender. this is a hint for sure to users that
you ought to be able to muck with the hierarchy in this method.
can you state the proposed semantics in terms of the meanings
of the method names? the code movement is not as important
as transparency of meaning for users. i
ive been discussing with johan offline, and here is what we came up with
there is still a big onattach refactor to do in 2.0. big meaning it will
affect a lot of users.
the contract for onattach/ondetach was that these methods are called before
the framework executes any method on the component,
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 cha
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 {
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();
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 annotation
On 1/4/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
> you can do this with IBehavior, just add onattach/ondetach to it.
However, I see IBehavior more as a plugin for external visible
effects. And it would break api quite a bit :-)
well, all this work is going into the 2.0 branch anyways.
On 1/4/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
On 1/4/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
> Perhaps a really baad idea, but novel in its concept... I know the
> @onAttach annotations were not something worth implementing. But the
> idea of more flexible attach methods is appa
On 1/4/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
Perhaps a really baad idea, but novel in its concept... I know the
@onAttach annotations were not something worth implementing. But the
idea of more flexible attach methods is apparently still compelling.
actually i had @OnAttach and
Perhaps a really baad idea, but novel in its concept... I know the
@onAttach annotations were not something worth implementing. But the
idea of more flexible attach methods is apparently still compelling.
Can we implement a chain of commands for the attach/detach logic (or
any other lifecycle
fwiw i just factored out some things out of the listview's onattach into
onGenerateItems. take a look, tell me if enough has been factored out to
support your usecase.
-igor
On 1/4/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
Then if you really want that then that is the case.
But most of t
yes, what should really be done is that we need to go through the code and
factor out things that happen in onattach into separate method if they are
meant to be overridable.
lets say you override ondetach() and dont call super. are you going to
remember to call detachModels() which is done in co
Then if you really want that then that is the case.
But most of the time that doesn't happen
The current thing is just to restrictive it thing. Just one example in some
code that we have here is that
we have overriden internAttach of ListView because we have a bit more
special build of the list it
well if you allow this then it nullifies what i tried to achieve. the
developers, even core ones, will start doing what i said, making onattach
final and providing an onattach2 because in some instances you have things
that are not meant to be overridible. so we will be back to square one.
-igor
there is one problem of not being able to override some implementation in an
onAttach
and that is that the component builder (maybe even wicket core) doesn't put
that in
an overridable method so that i can nullify it or make my own impl.
Then i can never just override it with my own. And that coul
well the problem is this
lets say onattach() comes with no strings attached
then you have Component->MyComponent
MyComponent overrides onattach and puts something very important into it,
what to do now?
there are two choices: make onattach() final, and provide a break out method
called onAttac
If I commented the problem in the first place, it's because I like to
think
of these 'on...' methods as methods without any specific contract, that
the
framework user can freely overwrite. It's more kind of a suggestion.
yes but this doesn't hold. What happens if you extend an object (yours o
I agree with that. We indeed could invent ourselfs a method that we call from
within onAttach() to solve outr problem, but what if I'm not happy with what
someone else (possibly in some framework implementation) added to the
onAttach().
If I commented the problem in the first place, it's because
Great, it works fine now :-) After the refactorization the attach/detach logic
looks simplified and more robust.
Bendis
Dne středa 03 leden 2007 18:00 Igor Vaynberg napsal(a):
> well it was fixed, and then i broke it again with the attach/detach
> refactor i did :) now its fixed again.
>
> we ar
but this could be a problem if somebody really wants to override behavior of
a component
that is not in its own control. So maybe we should have a special final
protected method that just sets the flag?
That can also be called from the onAttach() instead of calling super?
johan
On 1/3/07, Igor
On Wed, 2006-10-18 at 21:13 -0500, Ryan Sonnek wrote:
> if there's a seperate wicket-bench list I can take this issue there...
>
> I've had issues with wicket-bench-0.4.0 where my javascript (in
> ) was not being loaded on the first page load. It happened
> pretty regularly with firefox, and both
27 matches
Mail list logo
