You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Colin Rogers <Co...@objectconsulting.com.au> on 2015/10/01 06:27:08 UTC
Components/Behaviour execution order
Wicketeers,
This question is to do with lifecycle execution order - it's not a bug as such, just a usage question - I hope you can help.
I have component X with an AjaxFormComponentUpdatingBehavior, that triggers updates in Components Y and Z by adding to target.
Y has a generic Behaviour that updates it's data. Z needs to hide or show itself depending on Y's data state.
Y needs to use that generic Behaviour, as it's complex, does loads of stuff and is used throughout the system - so I can't change this.
Originally, in Z's onConfigure() we set the setVisible() depending on Y's state. But that doesn't work as Z's onConfigure() executes after Y's Behaviours onConfigure(). Which is just the way Component.configure() works. Which is fair enough.
So, I figured if Behaviours execute after onConfigure, I simply put the setVisible() code into a Behaviour on Z, and bingo!
Only Y's Behaviour always executes first. Always. Even if I create it second, even if I add Z to their parent container before Y. I can't work out how to affect the order of Components/Behaviour execution.
Note - I did extend the Y's Behaviour to update Z, but as Z has already completed its cycle, the state didn't actually update.
Can anyone help?
Cheers,
Col.
EMAIL DISCLAIMER This email message and its attachments are confidential and may also contain copyright or privileged material. If you are not the intended recipient, you may not forward the email or disclose or use the information contained in it. If you have received this email message in error, please advise the sender immediately by replying to this email and delete the message and any associated attachments. Any views, opinions, conclusions, advice or statements expressed in this email message are those of the individual sender and should not be relied upon as the considered view, opinion, conclusions, advice or statement of this company except where the sender expressly, and with authority, states them to be the considered view, opinion, conclusions, advice or statement of this company. Every care is taken but we recommend that you scan any attachments for viruses.
RE: Components/Behaviour execution order
Posted by Colin Rogers <Co...@objectconsulting.com.au>.
Cool - thanks Seb - I'll look into it...! :)
-----Original Message-----
From: Sebastien [mailto:sebfz1@gmail.com]
Sent: Thursday, 1 October 2015 6:13 PM
To: Patrick Davids <pa...@nubologic.com>
Cc: users@wicket.apache.org
Subject: Re: Components/Behaviour execution order
Hi,
@Patrick
Yes, we had a behavior sequence order issue [1] that we just solved by calling super.onConfigure(component); at the end of #onConfigure.
@Colin
When I've complex cases, I am using the event bus. The key point is my magic AjaxPayload base class, so you can create ZStateChangedAjaxPayload extends AjaxPayload, sent from Z, and caught in Y#onEvent and/or any components/behaviors you want... I don't know if you already used the event bus in the past, but if it's not the case, you will like it! :)
public class AjaxPayload
{
private final AjaxRequestTarget target;
public AjaxPayload(AjaxRequestTarget target)
{
this.target = target;
}
public AjaxRequestTarget getTarget()
{
return this.target;
}
public void reload(Component... components)
{
this.getTarget().add(components);
}
}
Hope this helps,
Sebastien.
[1] https://github.com/sebfz1/wicket-jquery-ui/issues/43
On Thu, Oct 1, 2015 at 8:57 AM, Patrick Davids <patrick.davids@nubologic.com
> wrote:
> Hi Col.,
> sometimes I try to cheat by using onBeforeRender() in such cases to 'fake'
> an order, because its called after onConfigure().
> But this has some restrictions concerning visibility issues of components.
> But in simple dependencies this sometimes works for me.
>
> I think somewhere in wickets jira is an issue for a similar problem,
> to feature defining a kind of order of behaviors.
> Unfort. I'm not able to find it right away.
>
> (@Sebastien: I think, we had such problem someday... do you remember
> maybe?)
>
> best regards
> Patrick
>
>
> Am 01.10.2015 um 06:27 schrieb Colin Rogers:
>
>> Wicketeers,
>>
>> This question is to do with lifecycle execution order - it's not a
>> bug as such, just a usage question - I hope you can help.
>>
>> I have component X with an AjaxFormComponentUpdatingBehavior, that
>> triggers updates in Components Y and Z by adding to target.
>>
>> Y has a generic Behaviour that updates it's data. Z needs to hide or
>> show itself depending on Y's data state.
>>
>> Y needs to use that generic Behaviour, as it's complex, does loads of
>> stuff and is used throughout the system - so I can't change this.
>>
>> Originally, in Z's onConfigure() we set the setVisible() depending on
>> Y's state. But that doesn't work as Z's onConfigure() executes after
>> Y's Behaviours onConfigure(). Which is just the way
>> Component.configure() works. Which is fair enough.
>>
>> So, I figured if Behaviours execute after onConfigure, I simply put
>> the
>> setVisible() code into a Behaviour on Z, and bingo!
>>
>> Only Y's Behaviour always executes first. Always. Even if I create it
>> second, even if I add Z to their parent container before Y. I can't
>> work out how to affect the order of Components/Behaviour execution.
>>
>> Note - I did extend the Y's Behaviour to update Z, but as Z has
>> already completed its cycle, the state didn't actually update.
>>
>> Can anyone help?
>>
>> Cheers,
>> Col.
>> EMAIL DISCLAIMER This email message and its attachments are
>> confidential and may also contain copyright or privileged material.
>> If you are not the intended recipient, you may not forward the email
>> or disclose or use the information contained in it. If you have
>> received this email message in error, please advise the sender
>> immediately by replying to this email and delete the message and any
>> associated attachments. Any views, opinions, conclusions, advice or
>> statements expressed in this email message are those of the
>> individual sender and should not be relied upon as the considered
>> view, opinion, conclusions, advice or statement of this company
>> except where the sender expressly, and with authority, states them to be the considered view, opinion, conclusions, advice or statement of this company.
>> Every care is taken but we recommend that you scan any attachments
>> for viruses.
>>
>>
>
EMAIL DISCLAIMER This email message and its attachments are confidential and may also contain copyright or privileged material. If you are not the intended recipient, you may not forward the email or disclose or use the information contained in it. If you have received this email message in error, please advise the sender immediately by replying to this email and delete the message and any associated attachments. Any views, opinions, conclusions, advice or statements expressed in this email message are those of the individual sender and should not be relied upon as the considered view, opinion, conclusions, advice or statement of this company except where the sender expressly, and with authority, states them to be the considered view, opinion, conclusions, advice or statement of this company. Every care is taken but we recommend that you scan any attachments for viruses.
Re: Components/Behaviour execution order
Posted by Sebastien <se...@gmail.com>.
Hi,
@Patrick
Yes, we had a behavior sequence order issue [1] that we just solved by
calling super.onConfigure(component); at the end of #onConfigure.
@Colin
When I've complex cases, I am using the event bus. The key point is my
magic AjaxPayload base class, so you can create ZStateChangedAjaxPayload
extends AjaxPayload, sent from Z, and caught in Y#onEvent and/or any
components/behaviors you want... I don't know if you already used the event
bus in the past, but if it's not the case, you will like it! :)
public class AjaxPayload
{
private final AjaxRequestTarget target;
public AjaxPayload(AjaxRequestTarget target)
{
this.target = target;
}
public AjaxRequestTarget getTarget()
{
return this.target;
}
public void reload(Component... components)
{
this.getTarget().add(components);
}
}
Hope this helps,
Sebastien.
[1] https://github.com/sebfz1/wicket-jquery-ui/issues/43
On Thu, Oct 1, 2015 at 8:57 AM, Patrick Davids <patrick.davids@nubologic.com
> wrote:
> Hi Col.,
> sometimes I try to cheat by using onBeforeRender() in such cases to 'fake'
> an order, because its called after onConfigure().
> But this has some restrictions concerning visibility issues of components.
> But in simple dependencies this sometimes works for me.
>
> I think somewhere in wickets jira is an issue for a similar problem, to
> feature defining a kind of order of behaviors.
> Unfort. I'm not able to find it right away.
>
> (@Sebastien: I think, we had such problem someday... do you remember
> maybe?)
>
> best regards
> Patrick
>
>
> Am 01.10.2015 um 06:27 schrieb Colin Rogers:
>
>> Wicketeers,
>>
>> This question is to do with lifecycle execution order - it's not a bug as
>> such, just a usage question - I hope you can help.
>>
>> I have component X with an AjaxFormComponentUpdatingBehavior, that
>> triggers updates in Components Y and Z by adding to target.
>>
>> Y has a generic Behaviour that updates it's data. Z needs to hide or show
>> itself depending on Y's data state.
>>
>> Y needs to use that generic Behaviour, as it's complex, does loads of
>> stuff and is used throughout the system - so I can't change this.
>>
>> Originally, in Z's onConfigure() we set the setVisible() depending on Y's
>> state. But that doesn't work as Z's onConfigure() executes after Y's
>> Behaviours onConfigure(). Which is just the way Component.configure()
>> works. Which is fair enough.
>>
>> So, I figured if Behaviours execute after onConfigure, I simply put the
>> setVisible() code into a Behaviour on Z, and bingo!
>>
>> Only Y's Behaviour always executes first. Always. Even if I create it
>> second, even if I add Z to their parent container before Y. I can't work
>> out how to affect the order of Components/Behaviour execution.
>>
>> Note - I did extend the Y's Behaviour to update Z, but as Z has already
>> completed its cycle, the state didn't actually update.
>>
>> Can anyone help?
>>
>> Cheers,
>> Col.
>> EMAIL DISCLAIMER This email message and its attachments are confidential
>> and may also contain copyright or privileged material. If you are not the
>> intended recipient, you may not forward the email or disclose or use the
>> information contained in it. If you have received this email message in
>> error, please advise the sender immediately by replying to this email and
>> delete the message and any associated attachments. Any views, opinions,
>> conclusions, advice or statements expressed in this email message are those
>> of the individual sender and should not be relied upon as the considered
>> view, opinion, conclusions, advice or statement of this company except
>> where the sender expressly, and with authority, states them to be the
>> considered view, opinion, conclusions, advice or statement of this company.
>> Every care is taken but we recommend that you scan any attachments for
>> viruses.
>>
>>
>
Re: Components/Behaviour execution order
Posted by Patrick Davids <pa...@nubologic.com>.
Hi Col.,
sometimes I try to cheat by using onBeforeRender() in such cases to
'fake' an order, because its called after onConfigure().
But this has some restrictions concerning visibility issues of components.
But in simple dependencies this sometimes works for me.
I think somewhere in wickets jira is an issue for a similar problem, to
feature defining a kind of order of behaviors.
Unfort. I'm not able to find it right away.
(@Sebastien: I think, we had such problem someday... do you remember maybe?)
best regards
Patrick
Am 01.10.2015 um 06:27 schrieb Colin Rogers:
> Wicketeers,
>
> This question is to do with lifecycle execution order - it's not a bug as such, just a usage question - I hope you can help.
>
> I have component X with an AjaxFormComponentUpdatingBehavior, that triggers updates in Components Y and Z by adding to target.
>
> Y has a generic Behaviour that updates it's data. Z needs to hide or show itself depending on Y's data state.
>
> Y needs to use that generic Behaviour, as it's complex, does loads of stuff and is used throughout the system - so I can't change this.
>
> Originally, in Z's onConfigure() we set the setVisible() depending on Y's state. But that doesn't work as Z's onConfigure() executes after Y's Behaviours onConfigure(). Which is just the way Component.configure() works. Which is fair enough.
>
> So, I figured if Behaviours execute after onConfigure, I simply put the setVisible() code into a Behaviour on Z, and bingo!
>
> Only Y's Behaviour always executes first. Always. Even if I create it second, even if I add Z to their parent container before Y. I can't work out how to affect the order of Components/Behaviour execution.
>
> Note - I did extend the Y's Behaviour to update Z, but as Z has already completed its cycle, the state didn't actually update.
>
> Can anyone help?
>
> Cheers,
> Col.
> EMAIL DISCLAIMER This email message and its attachments are confidential and may also contain copyright or privileged material. If you are not the intended recipient, you may not forward the email or disclose or use the information contained in it. If you have received this email message in error, please advise the sender immediately by replying to this email and delete the message and any associated attachments. Any views, opinions, conclusions, advice or statements expressed in this email message are those of the individual sender and should not be relied upon as the considered view, opinion, conclusions, advice or statement of this company except where the sender expressly, and with authority, states them to be the considered view, opinion, conclusions, advice or statement of this company. Every care is taken but we recommend that you scan any attachments for viruses.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org