You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Igor Vaynberg <ig...@gmail.com> on 2008/03/27 08:43:30 UTC
WICKET-1391: anyone got any better ideas?
ive just attached a draft patch to WICKET-1391. its kinda hacky, so i
want to see if anyone can come up with a more elegant way to do this.
-igor
Re: WICKET-1391: anyone got any better ideas?
Posted by Jonathan Locke <jo...@gmail.com>.
right.
are there other useful applications for this in 1.5?
btw, these transparent auto components have been saving my life at my work.
i've been able to really extend wicket very far in terms of mobile devices
with only one tiny change to core.
Johan Compagner wrote:
>
> I think there is, make really a transparant container
> But that is some work and not something for 1.3
>
> On 3/28/08, Jonathan Locke <jo...@gmail.com> wrote:
>>
>>
>> right. not only that, but the children can't go away because they might
>> become visible again.
>>
>> i guess i don't see any way around the flag you were talking about.
>>
>>
>> igor.vaynberg wrote:
>> >
>> > because enclosure itself does not have children
>> >
>> > -igor
>> >
>> >
>> > On Thu, Mar 27, 2008 at 8:33 PM, Jonathan Locke
>> > <jo...@gmail.com> wrote:
>> >>
>> >>
>> >> okay. sorry, i'm kinda playing catch up here...
>> >>
>> >> one last (maybe ignorant) question. so, when the invisible enclosure
>> is
>> >> removed at the end of rendering, couldn't it/wicket just remove all
>> of
>> >> its
>> >> children then? if the enclosure contents never rendered, why leave
>> >> components in there? this would reduce state as well.
>> >>
>> >> if i'm still not getting it, maybe we can talk on ##wicket tomorrow
>> to
>> >> avoid
>> >> more list emails.
>> >>
>> >> jon
>> >>
>> >>
>> >>
>> >>
>> >> igor.vaynberg wrote:
>> >> >
>> >> > well, yes! but the problem is when the form is submitted the
>> enclosure
>> >> > is no longer there, because it is auto. further it is not in the
>> >> > hierarchy, whatever is inside is driven by markup only...
>> >> >
>> >> > -igor
>> >> >
>> >> >
>> >> > On Thu, Mar 27, 2008 at 8:17 PM, Jonathan Locke
>> >> > <jo...@gmail.com> wrote:
>> >> >>
>> >> >>
>> >> >> yeah, but didn't the original bug come from a form component that
>> >> got a
>> >> >> value set on it when it was in an invisible enclosure? if the
>> >> traversal
>> >> >> knew about these transparent enclosures, it could check their
>> >> visibility
>> >> >> (they wouldn't be transparent to the traversal). then those form
>> >> >> components
>> >> >> inside the enclosure would never be seen in form processing.
>> isn't
>> >> that
>> >> >> more correct? or am i still missing something?
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> igor.vaynberg wrote:
>> >> >> >
>> >> >> > On Thu, Mar 27, 2008 at 6:53 PM, Jonathan Locke
>> >> >> > <jo...@gmail.com> wrote:
>> >> >> >>
>> >> >> >>
>> >> >> >> i'm definitely jumping into the middle of this, but isn't the
>> >> >> problem
>> >> >> >> that
>> >> >> >> the form component traversal is going into an auto markup
>> >> container
>> >> >> >> that's
>> >> >> >> not visible? can't we change our traversal code to fix this?
>> >> or am
>> >> >> i
>> >> >> >> missing some key point?
>> >> >> >
>> >> >> > a) auto components only exist during render phase
>> >> >> > b) enclosure is transparent so it is not in the hierarchy, it
>> is
>> >> to a
>> >> >> side
>> >> >> >
>> >> >> > -igor
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> igor.vaynberg wrote:
>> >> >> >> >
>> >> >> >> > ive just attached a draft patch to WICKET-1391. its kinda
>> >> hacky,
>> >> >> so i
>> >> >> >> > want to see if anyone can come up with a more elegant way
>> to
>> >> do
>> >> >> this.
>> >> >> >> >
>> >> >> >> > -igor
>> >> >> >> >
>> >> >> >> >
>> >> >> >>
>> >> >> >> --
>> >> >> >> View this message in context:
>> >> >> >>
>> >> >>
>> >>
>> http://www.nabble.com/WICKET-1391%3A-anyone-got-any-better-ideas--tp16323672p16344172.html
>> >> >> >> Sent from the Wicket - Dev mailing list archive at
>> Nabble.com.
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> --
>> >> >> View this message in context:
>> >> >>
>> >>
>> http://www.nabble.com/WICKET-1391%3A-anyone-got-any-better-ideas--tp16323672p16345070.html
>> >> >>
>> >> >>
>> >> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/WICKET-1391%3A-anyone-got-any-better-ideas--tp16323672p16345212.html
>> >>
>> >>
>> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/WICKET-1391%3A-anyone-got-any-better-ideas--tp16323672p16346365.html
>> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context: http://www.nabble.com/WICKET-1391%3A-anyone-got-any-better-ideas--tp16323672p16354808.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: WICKET-1391: anyone got any better ideas?
Posted by Nino Saturnino Martinez Vazquez Wael <ni...@jayway.dk>.
That would be really coool:)
Johan Compagner wrote:
> I think there is, make really a transparant container
> But that is some work and not something for 1.3
>
> On 3/28/08, Jonathan Locke <jo...@gmail.com> wrote:
>
>> right. not only that, but the children can't go away because they might
>> become visible again.
>>
>> i guess i don't see any way around the flag you were talking about.
>>
>>
>> igor.vaynberg wrote:
>>
>>> because enclosure itself does not have children
>>>
>>> -igor
>>>
>>>
>>> On Thu, Mar 27, 2008 at 8:33 PM, Jonathan Locke
>>> <jo...@gmail.com> wrote:
>>>
>>>> okay. sorry, i'm kinda playing catch up here...
>>>>
>>>> one last (maybe ignorant) question. so, when the invisible enclosure is
>>>> removed at the end of rendering, couldn't it/wicket just remove all of
>>>> its
>>>> children then? if the enclosure contents never rendered, why leave
>>>> components in there? this would reduce state as well.
>>>>
>>>> if i'm still not getting it, maybe we can talk on ##wicket tomorrow to
>>>> avoid
>>>> more list emails.
>>>>
>>>> jon
>>>>
>>>>
>>>>
>>>>
>>>> igor.vaynberg wrote:
>>>> >
>>>> > well, yes! but the problem is when the form is submitted the enclosure
>>>> > is no longer there, because it is auto. further it is not in the
>>>> > hierarchy, whatever is inside is driven by markup only...
>>>> >
>>>> > -igor
>>>> >
>>>> >
>>>> > On Thu, Mar 27, 2008 at 8:17 PM, Jonathan Locke
>>>> > <jo...@gmail.com> wrote:
>>>> >>
>>>> >>
>>>> >> yeah, but didn't the original bug come from a form component that
>>>> got a
>>>> >> value set on it when it was in an invisible enclosure? if the
>>>> traversal
>>>> >> knew about these transparent enclosures, it could check their
>>>> visibility
>>>> >> (they wouldn't be transparent to the traversal). then those form
>>>> >> components
>>>> >> inside the enclosure would never be seen in form processing. isn't
>>>> that
>>>> >> more correct? or am i still missing something?
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> igor.vaynberg wrote:
>>>> >> >
>>>> >> > On Thu, Mar 27, 2008 at 6:53 PM, Jonathan Locke
>>>> >> > <jo...@gmail.com> wrote:
>>>> >> >>
>>>> >> >>
>>>> >> >> i'm definitely jumping into the middle of this, but isn't the
>>>> >> problem
>>>> >> >> that
>>>> >> >> the form component traversal is going into an auto markup
>>>> container
>>>> >> >> that's
>>>> >> >> not visible? can't we change our traversal code to fix this?
>>>> or am
>>>> >> i
>>>> >> >> missing some key point?
>>>> >> >
>>>> >> > a) auto components only exist during render phase
>>>> >> > b) enclosure is transparent so it is not in the hierarchy, it is
>>>> to a
>>>> >> side
>>>> >> >
>>>> >> > -igor
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >>
>>>> >> >>
>>>> >> >>
>>>> >> >>
>>>> >> >> igor.vaynberg wrote:
>>>> >> >> >
>>>> >> >> > ive just attached a draft patch to WICKET-1391. its kinda
>>>> hacky,
>>>> >> so i
>>>> >> >> > want to see if anyone can come up with a more elegant way to
>>>> do
>>>> >> this.
>>>> >> >> >
>>>> >> >> > -igor
>>>> >> >> >
>>>> >> >> >
>>>> >> >>
>>>> >> >> --
>>>> >> >> View this message in context:
>>>> >> >>
>>>> >>
>>>>
>>>>
>> http://www.nabble.com/WICKET-1391%3A-anyone-got-any-better-ideas--tp16323672p16344172.html
>>
>>>> >> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>>> >> >>
>>>> >> >>
>>>> >> >
>>>> >> >
>>>> >>
>>>> >> --
>>>> >> View this message in context:
>>>> >>
>>>>
>>>>
>> http://www.nabble.com/WICKET-1391%3A-anyone-got-any-better-ideas--tp16323672p16345070.html
>>
>>>> >>
>>>> >>
>>>> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>>> >>
>>>> >>
>>>> >
>>>> >
>>>>
>>>> --
>>>> View this message in context:
>>>>
>>>>
>> http://www.nabble.com/WICKET-1391%3A-anyone-got-any-better-ideas--tp16323672p16345212.html
>>
>>>> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>>>
>>>>
>>>>
>>>
>> --
>> View this message in context:
>> http://www.nabble.com/WICKET-1391%3A-anyone-got-any-better-ideas--tp16323672p16346365.html
>> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>
>>
>>
>
>
>
--
-Wicket for love
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
Re: WICKET-1391: anyone got any better ideas?
Posted by Johan Compagner <jc...@gmail.com>.
I think there is, make really a transparant container
But that is some work and not something for 1.3
On 3/28/08, Jonathan Locke <jo...@gmail.com> wrote:
>
>
> right. not only that, but the children can't go away because they might
> become visible again.
>
> i guess i don't see any way around the flag you were talking about.
>
>
> igor.vaynberg wrote:
> >
> > because enclosure itself does not have children
> >
> > -igor
> >
> >
> > On Thu, Mar 27, 2008 at 8:33 PM, Jonathan Locke
> > <jo...@gmail.com> wrote:
> >>
> >>
> >> okay. sorry, i'm kinda playing catch up here...
> >>
> >> one last (maybe ignorant) question. so, when the invisible enclosure is
> >> removed at the end of rendering, couldn't it/wicket just remove all of
> >> its
> >> children then? if the enclosure contents never rendered, why leave
> >> components in there? this would reduce state as well.
> >>
> >> if i'm still not getting it, maybe we can talk on ##wicket tomorrow to
> >> avoid
> >> more list emails.
> >>
> >> jon
> >>
> >>
> >>
> >>
> >> igor.vaynberg wrote:
> >> >
> >> > well, yes! but the problem is when the form is submitted the enclosure
> >> > is no longer there, because it is auto. further it is not in the
> >> > hierarchy, whatever is inside is driven by markup only...
> >> >
> >> > -igor
> >> >
> >> >
> >> > On Thu, Mar 27, 2008 at 8:17 PM, Jonathan Locke
> >> > <jo...@gmail.com> wrote:
> >> >>
> >> >>
> >> >> yeah, but didn't the original bug come from a form component that
> >> got a
> >> >> value set on it when it was in an invisible enclosure? if the
> >> traversal
> >> >> knew about these transparent enclosures, it could check their
> >> visibility
> >> >> (they wouldn't be transparent to the traversal). then those form
> >> >> components
> >> >> inside the enclosure would never be seen in form processing. isn't
> >> that
> >> >> more correct? or am i still missing something?
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> igor.vaynberg wrote:
> >> >> >
> >> >> > On Thu, Mar 27, 2008 at 6:53 PM, Jonathan Locke
> >> >> > <jo...@gmail.com> wrote:
> >> >> >>
> >> >> >>
> >> >> >> i'm definitely jumping into the middle of this, but isn't the
> >> >> problem
> >> >> >> that
> >> >> >> the form component traversal is going into an auto markup
> >> container
> >> >> >> that's
> >> >> >> not visible? can't we change our traversal code to fix this?
> >> or am
> >> >> i
> >> >> >> missing some key point?
> >> >> >
> >> >> > a) auto components only exist during render phase
> >> >> > b) enclosure is transparent so it is not in the hierarchy, it is
> >> to a
> >> >> side
> >> >> >
> >> >> > -igor
> >> >> >
> >> >> >
> >> >> >
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> igor.vaynberg wrote:
> >> >> >> >
> >> >> >> > ive just attached a draft patch to WICKET-1391. its kinda
> >> hacky,
> >> >> so i
> >> >> >> > want to see if anyone can come up with a more elegant way to
> >> do
> >> >> this.
> >> >> >> >
> >> >> >> > -igor
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >> --
> >> >> >> View this message in context:
> >> >> >>
> >> >>
> >>
> http://www.nabble.com/WICKET-1391%3A-anyone-got-any-better-ideas--tp16323672p16344172.html
> >> >> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> View this message in context:
> >> >>
> >>
> http://www.nabble.com/WICKET-1391%3A-anyone-got-any-better-ideas--tp16323672p16345070.html
> >> >>
> >> >>
> >> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/WICKET-1391%3A-anyone-got-any-better-ideas--tp16323672p16345212.html
> >>
> >>
> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/WICKET-1391%3A-anyone-got-any-better-ideas--tp16323672p16346365.html
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>
Re: WICKET-1391: anyone got any better ideas?
Posted by Jonathan Locke <jo...@gmail.com>.
right. not only that, but the children can't go away because they might
become visible again.
i guess i don't see any way around the flag you were talking about.
igor.vaynberg wrote:
>
> because enclosure itself does not have children
>
> -igor
>
>
> On Thu, Mar 27, 2008 at 8:33 PM, Jonathan Locke
> <jo...@gmail.com> wrote:
>>
>>
>> okay. sorry, i'm kinda playing catch up here...
>>
>> one last (maybe ignorant) question. so, when the invisible enclosure is
>> removed at the end of rendering, couldn't it/wicket just remove all of
>> its
>> children then? if the enclosure contents never rendered, why leave
>> components in there? this would reduce state as well.
>>
>> if i'm still not getting it, maybe we can talk on ##wicket tomorrow to
>> avoid
>> more list emails.
>>
>> jon
>>
>>
>>
>>
>> igor.vaynberg wrote:
>> >
>> > well, yes! but the problem is when the form is submitted the enclosure
>> > is no longer there, because it is auto. further it is not in the
>> > hierarchy, whatever is inside is driven by markup only...
>> >
>> > -igor
>> >
>> >
>> > On Thu, Mar 27, 2008 at 8:17 PM, Jonathan Locke
>> > <jo...@gmail.com> wrote:
>> >>
>> >>
>> >> yeah, but didn't the original bug come from a form component that
>> got a
>> >> value set on it when it was in an invisible enclosure? if the
>> traversal
>> >> knew about these transparent enclosures, it could check their
>> visibility
>> >> (they wouldn't be transparent to the traversal). then those form
>> >> components
>> >> inside the enclosure would never be seen in form processing. isn't
>> that
>> >> more correct? or am i still missing something?
>> >>
>> >>
>> >>
>> >>
>> >> igor.vaynberg wrote:
>> >> >
>> >> > On Thu, Mar 27, 2008 at 6:53 PM, Jonathan Locke
>> >> > <jo...@gmail.com> wrote:
>> >> >>
>> >> >>
>> >> >> i'm definitely jumping into the middle of this, but isn't the
>> >> problem
>> >> >> that
>> >> >> the form component traversal is going into an auto markup
>> container
>> >> >> that's
>> >> >> not visible? can't we change our traversal code to fix this?
>> or am
>> >> i
>> >> >> missing some key point?
>> >> >
>> >> > a) auto components only exist during render phase
>> >> > b) enclosure is transparent so it is not in the hierarchy, it is
>> to a
>> >> side
>> >> >
>> >> > -igor
>> >> >
>> >> >
>> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> igor.vaynberg wrote:
>> >> >> >
>> >> >> > ive just attached a draft patch to WICKET-1391. its kinda
>> hacky,
>> >> so i
>> >> >> > want to see if anyone can come up with a more elegant way to
>> do
>> >> this.
>> >> >> >
>> >> >> > -igor
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> --
>> >> >> View this message in context:
>> >> >>
>> >>
>> http://www.nabble.com/WICKET-1391%3A-anyone-got-any-better-ideas--tp16323672p16344172.html
>> >> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/WICKET-1391%3A-anyone-got-any-better-ideas--tp16323672p16345070.html
>> >>
>> >>
>> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/WICKET-1391%3A-anyone-got-any-better-ideas--tp16323672p16345212.html
>>
>>
>> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context: http://www.nabble.com/WICKET-1391%3A-anyone-got-any-better-ideas--tp16323672p16346365.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: WICKET-1391: anyone got any better ideas?
Posted by Igor Vaynberg <ig...@gmail.com>.
because enclosure itself does not have children
-igor
On Thu, Mar 27, 2008 at 8:33 PM, Jonathan Locke
<jo...@gmail.com> wrote:
>
>
> okay. sorry, i'm kinda playing catch up here...
>
> one last (maybe ignorant) question. so, when the invisible enclosure is
> removed at the end of rendering, couldn't it/wicket just remove all of its
> children then? if the enclosure contents never rendered, why leave
> components in there? this would reduce state as well.
>
> if i'm still not getting it, maybe we can talk on ##wicket tomorrow to avoid
> more list emails.
>
> jon
>
>
>
>
> igor.vaynberg wrote:
> >
> > well, yes! but the problem is when the form is submitted the enclosure
> > is no longer there, because it is auto. further it is not in the
> > hierarchy, whatever is inside is driven by markup only...
> >
> > -igor
> >
> >
> > On Thu, Mar 27, 2008 at 8:17 PM, Jonathan Locke
> > <jo...@gmail.com> wrote:
> >>
> >>
> >> yeah, but didn't the original bug come from a form component that got a
> >> value set on it when it was in an invisible enclosure? if the traversal
> >> knew about these transparent enclosures, it could check their visibility
> >> (they wouldn't be transparent to the traversal). then those form
> >> components
> >> inside the enclosure would never be seen in form processing. isn't that
> >> more correct? or am i still missing something?
> >>
> >>
> >>
> >>
> >> igor.vaynberg wrote:
> >> >
> >> > On Thu, Mar 27, 2008 at 6:53 PM, Jonathan Locke
> >> > <jo...@gmail.com> wrote:
> >> >>
> >> >>
> >> >> i'm definitely jumping into the middle of this, but isn't the
> >> problem
> >> >> that
> >> >> the form component traversal is going into an auto markup container
> >> >> that's
> >> >> not visible? can't we change our traversal code to fix this? or am
> >> i
> >> >> missing some key point?
> >> >
> >> > a) auto components only exist during render phase
> >> > b) enclosure is transparent so it is not in the hierarchy, it is to a
> >> side
> >> >
> >> > -igor
> >> >
> >> >
> >> >
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> igor.vaynberg wrote:
> >> >> >
> >> >> > ive just attached a draft patch to WICKET-1391. its kinda hacky,
> >> so i
> >> >> > want to see if anyone can come up with a more elegant way to do
> >> this.
> >> >> >
> >> >> > -igor
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> View this message in context:
> >> >>
> >> http://www.nabble.com/WICKET-1391%3A-anyone-got-any-better-ideas--tp16323672p16344172.html
> >> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/WICKET-1391%3A-anyone-got-any-better-ideas--tp16323672p16345070.html
> >>
> >>
> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
> >>
> >>
> >
> >
>
> --
> View this message in context: http://www.nabble.com/WICKET-1391%3A-anyone-got-any-better-ideas--tp16323672p16345212.html
>
>
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>
Re: WICKET-1391: anyone got any better ideas?
Posted by Jonathan Locke <jo...@gmail.com>.
okay. sorry, i'm kinda playing catch up here...
one last (maybe ignorant) question. so, when the invisible enclosure is
removed at the end of rendering, couldn't it/wicket just remove all of its
children then? if the enclosure contents never rendered, why leave
components in there? this would reduce state as well.
if i'm still not getting it, maybe we can talk on ##wicket tomorrow to avoid
more list emails.
jon
igor.vaynberg wrote:
>
> well, yes! but the problem is when the form is submitted the enclosure
> is no longer there, because it is auto. further it is not in the
> hierarchy, whatever is inside is driven by markup only...
>
> -igor
>
>
> On Thu, Mar 27, 2008 at 8:17 PM, Jonathan Locke
> <jo...@gmail.com> wrote:
>>
>>
>> yeah, but didn't the original bug come from a form component that got a
>> value set on it when it was in an invisible enclosure? if the traversal
>> knew about these transparent enclosures, it could check their visibility
>> (they wouldn't be transparent to the traversal). then those form
>> components
>> inside the enclosure would never be seen in form processing. isn't that
>> more correct? or am i still missing something?
>>
>>
>>
>>
>> igor.vaynberg wrote:
>> >
>> > On Thu, Mar 27, 2008 at 6:53 PM, Jonathan Locke
>> > <jo...@gmail.com> wrote:
>> >>
>> >>
>> >> i'm definitely jumping into the middle of this, but isn't the
>> problem
>> >> that
>> >> the form component traversal is going into an auto markup container
>> >> that's
>> >> not visible? can't we change our traversal code to fix this? or am
>> i
>> >> missing some key point?
>> >
>> > a) auto components only exist during render phase
>> > b) enclosure is transparent so it is not in the hierarchy, it is to a
>> side
>> >
>> > -igor
>> >
>> >
>> >
>> >>
>> >>
>> >>
>> >>
>> >> igor.vaynberg wrote:
>> >> >
>> >> > ive just attached a draft patch to WICKET-1391. its kinda hacky,
>> so i
>> >> > want to see if anyone can come up with a more elegant way to do
>> this.
>> >> >
>> >> > -igor
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/WICKET-1391%3A-anyone-got-any-better-ideas--tp16323672p16344172.html
>> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/WICKET-1391%3A-anyone-got-any-better-ideas--tp16323672p16345070.html
>>
>>
>> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context: http://www.nabble.com/WICKET-1391%3A-anyone-got-any-better-ideas--tp16323672p16345212.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: WICKET-1391: anyone got any better ideas?
Posted by Igor Vaynberg <ig...@gmail.com>.
well, yes! but the problem is when the form is submitted the enclosure
is no longer there, because it is auto. further it is not in the
hierarchy, whatever is inside is driven by markup only...
-igor
On Thu, Mar 27, 2008 at 8:17 PM, Jonathan Locke
<jo...@gmail.com> wrote:
>
>
> yeah, but didn't the original bug come from a form component that got a
> value set on it when it was in an invisible enclosure? if the traversal
> knew about these transparent enclosures, it could check their visibility
> (they wouldn't be transparent to the traversal). then those form components
> inside the enclosure would never be seen in form processing. isn't that
> more correct? or am i still missing something?
>
>
>
>
> igor.vaynberg wrote:
> >
> > On Thu, Mar 27, 2008 at 6:53 PM, Jonathan Locke
> > <jo...@gmail.com> wrote:
> >>
> >>
> >> i'm definitely jumping into the middle of this, but isn't the problem
> >> that
> >> the form component traversal is going into an auto markup container
> >> that's
> >> not visible? can't we change our traversal code to fix this? or am i
> >> missing some key point?
> >
> > a) auto components only exist during render phase
> > b) enclosure is transparent so it is not in the hierarchy, it is to a side
> >
> > -igor
> >
> >
> >
> >>
> >>
> >>
> >>
> >> igor.vaynberg wrote:
> >> >
> >> > ive just attached a draft patch to WICKET-1391. its kinda hacky, so i
> >> > want to see if anyone can come up with a more elegant way to do this.
> >> >
> >> > -igor
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/WICKET-1391%3A-anyone-got-any-better-ideas--tp16323672p16344172.html
> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
> >>
> >>
> >
> >
>
> --
> View this message in context: http://www.nabble.com/WICKET-1391%3A-anyone-got-any-better-ideas--tp16323672p16345070.html
>
>
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>
Re: WICKET-1391: anyone got any better ideas?
Posted by Jonathan Locke <jo...@gmail.com>.
yeah, but didn't the original bug come from a form component that got a
value set on it when it was in an invisible enclosure? if the traversal
knew about these transparent enclosures, it could check their visibility
(they wouldn't be transparent to the traversal). then those form components
inside the enclosure would never be seen in form processing. isn't that
more correct? or am i still missing something?
igor.vaynberg wrote:
>
> On Thu, Mar 27, 2008 at 6:53 PM, Jonathan Locke
> <jo...@gmail.com> wrote:
>>
>>
>> i'm definitely jumping into the middle of this, but isn't the problem
>> that
>> the form component traversal is going into an auto markup container
>> that's
>> not visible? can't we change our traversal code to fix this? or am i
>> missing some key point?
>
> a) auto components only exist during render phase
> b) enclosure is transparent so it is not in the hierarchy, it is to a side
>
> -igor
>
>
>
>>
>>
>>
>>
>> igor.vaynberg wrote:
>> >
>> > ive just attached a draft patch to WICKET-1391. its kinda hacky, so i
>> > want to see if anyone can come up with a more elegant way to do this.
>> >
>> > -igor
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/WICKET-1391%3A-anyone-got-any-better-ideas--tp16323672p16344172.html
>> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context: http://www.nabble.com/WICKET-1391%3A-anyone-got-any-better-ideas--tp16323672p16345070.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: WICKET-1391: anyone got any better ideas?
Posted by Igor Vaynberg <ig...@gmail.com>.
On Thu, Mar 27, 2008 at 6:53 PM, Jonathan Locke
<jo...@gmail.com> wrote:
>
>
> i'm definitely jumping into the middle of this, but isn't the problem that
> the form component traversal is going into an auto markup container that's
> not visible? can't we change our traversal code to fix this? or am i
> missing some key point?
a) auto components only exist during render phase
b) enclosure is transparent so it is not in the hierarchy, it is to a side
-igor
>
>
>
>
> igor.vaynberg wrote:
> >
> > ive just attached a draft patch to WICKET-1391. its kinda hacky, so i
> > want to see if anyone can come up with a more elegant way to do this.
> >
> > -igor
> >
> >
>
> --
> View this message in context: http://www.nabble.com/WICKET-1391%3A-anyone-got-any-better-ideas--tp16323672p16344172.html
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>
Re: WICKET-1391: anyone got any better ideas?
Posted by Jonathan Locke <jo...@gmail.com>.
i'm definitely jumping into the middle of this, but isn't the problem that
the form component traversal is going into an auto markup container that's
not visible? can't we change our traversal code to fix this? or am i
missing some key point?
igor.vaynberg wrote:
>
> ive just attached a draft patch to WICKET-1391. its kinda hacky, so i
> want to see if anyone can come up with a more elegant way to do this.
>
> -igor
>
>
--
View this message in context: http://www.nabble.com/WICKET-1391%3A-anyone-got-any-better-ideas--tp16323672p16344172.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: WICKET-1391: anyone got any better ideas?
Posted by Igor Vaynberg <ig...@gmail.com>.
+1 for an additional flag. then we have 3 things to check: isvisible,
isrenderallowed, isthisnewflagwhatchamajjigit
i still say we should have one method that does this check on
component that is public instead of only doing the proper check in
isvisibleinhierarchy()
-igor
On Thu, Mar 27, 2008 at 12:23 PM, Johan Compagner <jc...@gmail.com> wrote:
> making isVisible final will break many things thats not really an option
> But isVisible is just what it is.. It controls the state if the component
> has to render itself..
> Whats so strange about that.
>
> Of course we could introduce yet another flag so that we have 3 of them that
> defines if the component can be rendered or not
>
> isVisible is more or less the user/developers property
> isRenderedAllowed is security
>
> so yes using those is not really nice.
>
> johan
>
>
> On Thu, Mar 27, 2008 at 8:16 PM, Bruno Borges <br...@gmail.com>
> wrote:
>
>
>
> > Yeah Igor... I think isVisible should *not* be considered as an option to
> > control wether a componet is going to be displayed or not. This method
> > should only present if a component *is* visible or *is not*. This means:
> > isVisible tells the current component's state.
> >
> > To fix this:
> >
> > - make isVisible final
> > - introduce another method (e.g. isRenderAllowed)
> > or
> > - let isVisible ovewritable
> > - introduce another method (e.g. isRendered)
> >
> > Both options have their advantagens and disadvantages.
> >
> > On Thu, Mar 27, 2008 at 2:20 PM, Igor Vaynberg <ig...@gmail.com>
> > wrote:
> >
> > > well, the problem here is a bit more complicated.
> > >
> > > what if the user overrides isivisible. i think what we want here is
> > > another flag, kind of like isrenderallowed, but something that we can
> > > push...thoughts?
> > >
> > > -igor
> > >
> > >
> > > On Thu, Mar 27, 2008 at 8:47 AM, Johan Compagner <jc...@gmail.com>
> > > wrote:
> > > > the problem with setVisible is that it is a version change..
> > > > So if we disable that quickly before changing the variable then its
> > > fine by
> > > > me to change that
> > > > That can be default behavior by the way if you ask me
> > > >
> > > > component.setVersioned(false)
> > > > component.doWhatYouWant()
> > > > component.setVersioned(true)
> > > >
> > > >
> > > > johan
> > > >
> > > >
> > > > On Thu, Mar 27, 2008 at 9:05 AM, Igor Vaynberg <
> > igor.vaynberg@gmail.com
> > > >
> > > >
> > > >
> > > > wrote:
> > > >
> > > > > i guess all this nastiness stems from the facts that we resolve
> > > > > enclosures at render time and at that time we restrict calls to
> > > > > setvisible() because we consider it a hierarchy change.
> > > > >
> > > > > if we relax that at least for isvisible() calls then inside the
> > > > > enclosureresolver all we have to do is iterate over its direct
> > > > > children and call setvisible(false) on them if enclosure is hidden.
> > > > >
> > > > > -igor
> > > > >
> > > > >
> > > > > On Thu, Mar 27, 2008 at 12:43 AM, Igor Vaynberg <
> > > igor.vaynberg@gmail.com>
> > > > > wrote:
> > > > > > ive just attached a draft patch to WICKET-1391. its kinda hacky,
> > so
> > > i
> > > > > > want to see if anyone can come up with a more elegant way to do
> > > this.
> > > > > >
> > > > > > -igor
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Bruno Borges
> > blog.brunoborges.com.br
> > +55 1185657739
> >
> > "The glory of great men should always be
> > measured by the means they have used to
> > acquire it."
> > - Francois de La Rochefoucauld
> >
>
Re: WICKET-1391: anyone got any better ideas?
Posted by Johan Compagner <jc...@gmail.com>.
making isVisible final will break many things thats not really an option
But isVisible is just what it is.. It controls the state if the component
has to render itself..
Whats so strange about that.
Of course we could introduce yet another flag so that we have 3 of them that
defines if the component can be rendered or not
isVisible is more or less the user/developers property
isRenderedAllowed is security
so yes using those is not really nice.
johan
On Thu, Mar 27, 2008 at 8:16 PM, Bruno Borges <br...@gmail.com>
wrote:
> Yeah Igor... I think isVisible should *not* be considered as an option to
> control wether a componet is going to be displayed or not. This method
> should only present if a component *is* visible or *is not*. This means:
> isVisible tells the current component's state.
>
> To fix this:
>
> - make isVisible final
> - introduce another method (e.g. isRenderAllowed)
> or
> - let isVisible ovewritable
> - introduce another method (e.g. isRendered)
>
> Both options have their advantagens and disadvantages.
>
> On Thu, Mar 27, 2008 at 2:20 PM, Igor Vaynberg <ig...@gmail.com>
> wrote:
>
> > well, the problem here is a bit more complicated.
> >
> > what if the user overrides isivisible. i think what we want here is
> > another flag, kind of like isrenderallowed, but something that we can
> > push...thoughts?
> >
> > -igor
> >
> >
> > On Thu, Mar 27, 2008 at 8:47 AM, Johan Compagner <jc...@gmail.com>
> > wrote:
> > > the problem with setVisible is that it is a version change..
> > > So if we disable that quickly before changing the variable then its
> > fine by
> > > me to change that
> > > That can be default behavior by the way if you ask me
> > >
> > > component.setVersioned(false)
> > > component.doWhatYouWant()
> > > component.setVersioned(true)
> > >
> > >
> > > johan
> > >
> > >
> > > On Thu, Mar 27, 2008 at 9:05 AM, Igor Vaynberg <
> igor.vaynberg@gmail.com
> > >
> > >
> > >
> > > wrote:
> > >
> > > > i guess all this nastiness stems from the facts that we resolve
> > > > enclosures at render time and at that time we restrict calls to
> > > > setvisible() because we consider it a hierarchy change.
> > > >
> > > > if we relax that at least for isvisible() calls then inside the
> > > > enclosureresolver all we have to do is iterate over its direct
> > > > children and call setvisible(false) on them if enclosure is hidden.
> > > >
> > > > -igor
> > > >
> > > >
> > > > On Thu, Mar 27, 2008 at 12:43 AM, Igor Vaynberg <
> > igor.vaynberg@gmail.com>
> > > > wrote:
> > > > > ive just attached a draft patch to WICKET-1391. its kinda hacky,
> so
> > i
> > > > > want to see if anyone can come up with a more elegant way to do
> > this.
> > > > >
> > > > > -igor
> > > > >
> > > >
> > >
> >
>
>
>
> --
> Bruno Borges
> blog.brunoborges.com.br
> +55 1185657739
>
> "The glory of great men should always be
> measured by the means they have used to
> acquire it."
> - Francois de La Rochefoucauld
>
Re: WICKET-1391: anyone got any better ideas?
Posted by Bruno Borges <br...@gmail.com>.
Yeah Igor... I think isVisible should *not* be considered as an option to
control wether a componet is going to be displayed or not. This method
should only present if a component *is* visible or *is not*. This means:
isVisible tells the current component's state.
To fix this:
- make isVisible final
- introduce another method (e.g. isRenderAllowed)
or
- let isVisible ovewritable
- introduce another method (e.g. isRendered)
Both options have their advantagens and disadvantages.
On Thu, Mar 27, 2008 at 2:20 PM, Igor Vaynberg <ig...@gmail.com>
wrote:
> well, the problem here is a bit more complicated.
>
> what if the user overrides isivisible. i think what we want here is
> another flag, kind of like isrenderallowed, but something that we can
> push...thoughts?
>
> -igor
>
>
> On Thu, Mar 27, 2008 at 8:47 AM, Johan Compagner <jc...@gmail.com>
> wrote:
> > the problem with setVisible is that it is a version change..
> > So if we disable that quickly before changing the variable then its
> fine by
> > me to change that
> > That can be default behavior by the way if you ask me
> >
> > component.setVersioned(false)
> > component.doWhatYouWant()
> > component.setVersioned(true)
> >
> >
> > johan
> >
> >
> > On Thu, Mar 27, 2008 at 9:05 AM, Igor Vaynberg <igor.vaynberg@gmail.com
> >
> >
> >
> > wrote:
> >
> > > i guess all this nastiness stems from the facts that we resolve
> > > enclosures at render time and at that time we restrict calls to
> > > setvisible() because we consider it a hierarchy change.
> > >
> > > if we relax that at least for isvisible() calls then inside the
> > > enclosureresolver all we have to do is iterate over its direct
> > > children and call setvisible(false) on them if enclosure is hidden.
> > >
> > > -igor
> > >
> > >
> > > On Thu, Mar 27, 2008 at 12:43 AM, Igor Vaynberg <
> igor.vaynberg@gmail.com>
> > > wrote:
> > > > ive just attached a draft patch to WICKET-1391. its kinda hacky, so
> i
> > > > want to see if anyone can come up with a more elegant way to do
> this.
> > > >
> > > > -igor
> > > >
> > >
> >
>
--
Bruno Borges
blog.brunoborges.com.br
+55 1185657739
"The glory of great men should always be
measured by the means they have used to
acquire it."
- Francois de La Rochefoucauld
Re: WICKET-1391: anyone got any better ideas?
Posted by Igor Vaynberg <ig...@gmail.com>.
On Thu, Mar 27, 2008 at 12:16 PM, Johan Compagner <jc...@gmail.com> wrote:
> isnt it possible that we have a transparent resolver or something like that
> that is the closure?
> so that that one can be set visible or not
> and then we dont have to touch the children those are just one step deeper
> (but not really)
you kinda hit the nail on the head: the enclosure IS an auto component
that IS a transparent resolver
the problem with this is that:
it is auto - so it only exists during render time (autos are removed
in detach())
it is a transparent resolver - that means it is not a parent of the
components that are inside the enclosure markup.
i was thinking about changing it. making it a non-auto
webmarkupcontainer that is not transparent, and actually rewiring the
children properly, but that can get hairy also in case users expect
getparent() to return a certain thing...
-igor
>
> johan
>
>
> On Thu, Mar 27, 2008 at 6:20 PM, Igor Vaynberg <ig...@gmail.com>
>
>
> wrote:
>
> > well, the problem here is a bit more complicated.
> >
> > what if the user overrides isivisible. i think what we want here is
> > another flag, kind of like isrenderallowed, but something that we can
> > push...thoughts?
> >
> > -igor
> >
> >
> > On Thu, Mar 27, 2008 at 8:47 AM, Johan Compagner <jc...@gmail.com>
> > wrote:
> > > the problem with setVisible is that it is a version change..
> > > So if we disable that quickly before changing the variable then its
> > fine by
> > > me to change that
> > > That can be default behavior by the way if you ask me
> > >
> > > component.setVersioned(false)
> > > component.doWhatYouWant()
> > > component.setVersioned(true)
> > >
> > >
> > > johan
> > >
> > >
> > > On Thu, Mar 27, 2008 at 9:05 AM, Igor Vaynberg <igor.vaynberg@gmail.com
> > >
> > >
> > >
> > > wrote:
> > >
> > > > i guess all this nastiness stems from the facts that we resolve
> > > > enclosures at render time and at that time we restrict calls to
> > > > setvisible() because we consider it a hierarchy change.
> > > >
> > > > if we relax that at least for isvisible() calls then inside the
> > > > enclosureresolver all we have to do is iterate over its direct
> > > > children and call setvisible(false) on them if enclosure is hidden.
> > > >
> > > > -igor
> > > >
> > > >
> > > > On Thu, Mar 27, 2008 at 12:43 AM, Igor Vaynberg <
> > igor.vaynberg@gmail.com>
> > > > wrote:
> > > > > ive just attached a draft patch to WICKET-1391. its kinda hacky, so
> > i
> > > > > want to see if anyone can come up with a more elegant way to do
> > this.
> > > > >
> > > > > -igor
> > > > >
> > > >
> > >
> >
>
Re: WICKET-1391: anyone got any better ideas?
Posted by Johan Compagner <jc...@gmail.com>.
isnt it possible that we have a transparent resolver or something like that
that is the closure?
so that that one can be set visible or not
and then we dont have to touch the children those are just one step deeper
(but not really)
johan
On Thu, Mar 27, 2008 at 6:20 PM, Igor Vaynberg <ig...@gmail.com>
wrote:
> well, the problem here is a bit more complicated.
>
> what if the user overrides isivisible. i think what we want here is
> another flag, kind of like isrenderallowed, but something that we can
> push...thoughts?
>
> -igor
>
>
> On Thu, Mar 27, 2008 at 8:47 AM, Johan Compagner <jc...@gmail.com>
> wrote:
> > the problem with setVisible is that it is a version change..
> > So if we disable that quickly before changing the variable then its
> fine by
> > me to change that
> > That can be default behavior by the way if you ask me
> >
> > component.setVersioned(false)
> > component.doWhatYouWant()
> > component.setVersioned(true)
> >
> >
> > johan
> >
> >
> > On Thu, Mar 27, 2008 at 9:05 AM, Igor Vaynberg <igor.vaynberg@gmail.com
> >
> >
> >
> > wrote:
> >
> > > i guess all this nastiness stems from the facts that we resolve
> > > enclosures at render time and at that time we restrict calls to
> > > setvisible() because we consider it a hierarchy change.
> > >
> > > if we relax that at least for isvisible() calls then inside the
> > > enclosureresolver all we have to do is iterate over its direct
> > > children and call setvisible(false) on them if enclosure is hidden.
> > >
> > > -igor
> > >
> > >
> > > On Thu, Mar 27, 2008 at 12:43 AM, Igor Vaynberg <
> igor.vaynberg@gmail.com>
> > > wrote:
> > > > ive just attached a draft patch to WICKET-1391. its kinda hacky, so
> i
> > > > want to see if anyone can come up with a more elegant way to do
> this.
> > > >
> > > > -igor
> > > >
> > >
> >
>
Re: WICKET-1391: anyone got any better ideas?
Posted by Igor Vaynberg <ig...@gmail.com>.
well, the problem here is a bit more complicated.
what if the user overrides isivisible. i think what we want here is
another flag, kind of like isrenderallowed, but something that we can
push...thoughts?
-igor
On Thu, Mar 27, 2008 at 8:47 AM, Johan Compagner <jc...@gmail.com> wrote:
> the problem with setVisible is that it is a version change..
> So if we disable that quickly before changing the variable then its fine by
> me to change that
> That can be default behavior by the way if you ask me
>
> component.setVersioned(false)
> component.doWhatYouWant()
> component.setVersioned(true)
>
>
> johan
>
>
> On Thu, Mar 27, 2008 at 9:05 AM, Igor Vaynberg <ig...@gmail.com>
>
>
> wrote:
>
> > i guess all this nastiness stems from the facts that we resolve
> > enclosures at render time and at that time we restrict calls to
> > setvisible() because we consider it a hierarchy change.
> >
> > if we relax that at least for isvisible() calls then inside the
> > enclosureresolver all we have to do is iterate over its direct
> > children and call setvisible(false) on them if enclosure is hidden.
> >
> > -igor
> >
> >
> > On Thu, Mar 27, 2008 at 12:43 AM, Igor Vaynberg <ig...@gmail.com>
> > wrote:
> > > ive just attached a draft patch to WICKET-1391. its kinda hacky, so i
> > > want to see if anyone can come up with a more elegant way to do this.
> > >
> > > -igor
> > >
> >
>
Re: WICKET-1391: anyone got any better ideas?
Posted by Johan Compagner <jc...@gmail.com>.
the problem with setVisible is that it is a version change..
So if we disable that quickly before changing the variable then its fine by
me to change that
That can be default behavior by the way if you ask me
component.setVersioned(false)
component.doWhatYouWant()
component.setVersioned(true)
johan
On Thu, Mar 27, 2008 at 9:05 AM, Igor Vaynberg <ig...@gmail.com>
wrote:
> i guess all this nastiness stems from the facts that we resolve
> enclosures at render time and at that time we restrict calls to
> setvisible() because we consider it a hierarchy change.
>
> if we relax that at least for isvisible() calls then inside the
> enclosureresolver all we have to do is iterate over its direct
> children and call setvisible(false) on them if enclosure is hidden.
>
> -igor
>
>
> On Thu, Mar 27, 2008 at 12:43 AM, Igor Vaynberg <ig...@gmail.com>
> wrote:
> > ive just attached a draft patch to WICKET-1391. its kinda hacky, so i
> > want to see if anyone can come up with a more elegant way to do this.
> >
> > -igor
> >
>
Re: WICKET-1391: anyone got any better ideas?
Posted by Igor Vaynberg <ig...@gmail.com>.
i guess all this nastiness stems from the facts that we resolve
enclosures at render time and at that time we restrict calls to
setvisible() because we consider it a hierarchy change.
if we relax that at least for isvisible() calls then inside the
enclosureresolver all we have to do is iterate over its direct
children and call setvisible(false) on them if enclosure is hidden.
-igor
On Thu, Mar 27, 2008 at 12:43 AM, Igor Vaynberg <ig...@gmail.com> wrote:
> ive just attached a draft patch to WICKET-1391. its kinda hacky, so i
> want to see if anyone can come up with a more elegant way to do this.
>
> -igor
>