I am against this method
If you want that do it your self.
its simple
MyPage extends WebPage
{
private boole firstAttached = false;
onAttach()
{
if (firstAttached) // do something
firstAttached = true
}
}
johan
On 5/4/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
Although I do stil
oh that's right. i totally forgot about that semantics change. is that
already in trunk?
i think this since this is really just for initing components that need
context, under the new semantics we would only need isFirstRender and
isFirstRenderAfterAdd. that seems fairly clean and self-explanato
will we also have isFirstBeforeRender and isFirstBeforeRenderAfterAdd? since
in onattach you cannot modify component hierarchy anymore, and you shouldnt
really be attaching models in onbeforerender.
-igor
On 5/4/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
right.
well, if the component wa
right.
well, if the component wants to check for re-init, the method should
definitely not be called isFirstAttach() because a re-init is not a first
attachment.
i think there's a compelling and very common use case for one-shot
isFirstAttach() that works exactly like a constructor with the r
as of yesterday it is
-igor
On 5/4/07, Ivo van Dongen <[EMAIL PROTECTED]> wrote:
On 5/4/07, James McLaughlin <[EMAIL PROTECTED]> wrote:
>
> fwiw, i've occasionally wanted an onRemove callback in the component
(and
> now behavior :) )
Did I mis something? Is it possible to remove behaviors
On 5/4/07, James McLaughlin <[EMAIL PROTECTED]> wrote:
fwiw, i've occasionally wanted an onRemove callback in the component (and
now behavior :) )
Did I mis something? Is it possible to remove behaviors now? That would be
great, this was something I ran into last week with a timer behavior.
well i dont know
if you need second-phase-init then you are likely doing something that is
"context-sensitive" because this context is the only thing you are missing
in the constructor really.
so when you move things around the context changes, so should the component
reinit itself?
-igor
On
good question. re-adding dynamism seems like a fairly unusual use case (can
you think of any good ones?) so i think the answer is probably no. it seems
like if you have a component that dynamically does things on being re-added
you could manage that case on your own.
igor.vaynberg wrote:
>
fwiw, i've occasionally wanted an onRemove callback in the component (and
now behavior :) ) hierarchy so the object can undo some of its "damage" when
replaced. If we had this, then we could leave that issue to the developer's
discretion. I've had to use the two phase init pattern occassionally, s
so is it a firstattach if you remove a component and then readd it at a
later time?
-igor
On 5/4/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
Although I do still think we should generally discourage two-phase
construction, it is occasionally truly necessary and it seems like it
might
be nic
Although I do still think we should generally discourage two-phase
construction, it is occasionally truly necessary and it seems like it might
be nice to have a method up in Component that uses those component bits to
return whether the component has been attached already. This way, when two
phase
11 matches
Mail list logo
