Re: Free wicket from component hierarchy hell
> (assuming laziness wasn't it). :) We are not lazy, we are just very busy ;) ** Martin > > > On Thu, Jan 20, 2011 at 5:12 PM, Igor Vaynberg > wrote: >> so you only have one place to fix it in >> >> -igor >> >> On Thu, Jan 20, 2011 at 1:43 PM, James Carman >> wrote: >>> On Thu, Jan 20, 2011 at 3:34 PM, Martin Makundi >>> wrote: The largest production I am responsible for is stuck with 1.4.9 because some of the later releases have not been monotonically improving. So we are stuck with some patches etc. and we haven't had time to refactor to 1.4.x >>> >>> We're stuck on 1.4.9, too, because the markup and hierarchy changed >>> for DataTable and we're using that everywhere with a custom subclass >>> with its own markup. >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
I'm actually looking at it now. The markup changed between 1.4.5 and 1.4.6, so there must be some other reason that I stayed with 1.4.9 (assuming laziness wasn't it). :) On Thu, Jan 20, 2011 at 5:12 PM, Igor Vaynberg wrote: > so you only have one place to fix it in > > -igor > > On Thu, Jan 20, 2011 at 1:43 PM, James Carman > wrote: >> On Thu, Jan 20, 2011 at 3:34 PM, Martin Makundi >> wrote: >>> >>> The largest production I am responsible for is stuck with >>> 1.4.9 because some of the later >>> releases have not been monotonically improving. So we are stuck with >>> some patches etc. and we haven't had time to refactor to 1.4.x >>> >> >> We're stuck on 1.4.9, too, because the markup and hierarchy changed >> for DataTable and we're using that everywhere with a custom subclass >> with its own markup. >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
so you only have one place to fix it in -igor On Thu, Jan 20, 2011 at 1:43 PM, James Carman wrote: > On Thu, Jan 20, 2011 at 3:34 PM, Martin Makundi > wrote: >> >> The largest production I am responsible for is stuck with >> 1.4.9 because some of the later >> releases have not been monotonically improving. So we are stuck with >> some patches etc. and we haven't had time to refactor to 1.4.x >> > > We're stuck on 1.4.9, too, because the markup and hierarchy changed > for DataTable and we're using that everywhere with a custom subclass > with its own markup. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Thu, Jan 20, 2011 at 3:34 PM, Martin Makundi wrote: > > The largest production I am responsible for is stuck with > 1.4.9 because some of the later > releases have not been monotonically improving. So we are stuck with > some patches etc. and we haven't had time to refactor to 1.4.x > We're stuck on 1.4.9, too, because the markup and hierarchy changed for DataTable and we're using that everywhere with a custom subclass with its own markup. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
>> http://apache-wicket.1842946.n4.nabble.com/Free-wicket-from-component-hierarchy-hell-td3027705i160.html >> >> > > If in doubt, there is always >> getMarkupSettings().setAllowComponentAutoHierarchy(false); >> > there will be no such method. >> >> +1 for not making this part of core. I mean for yes making part of core ;) Duh.. it' s getting too late. >> Giannis is in our team yes but Giannis forked this mostly with help from >> Igor. >> >> Yes, we use 1.4 in production. >> > I meant: do you use 1.4 + the patch in production ? We have various projects, some yes some no. The largest production I am responsible for is stuck with 1.4.9 because some of the later releases have not been monotonically improving. So we are stuck with some patches etc. and we haven't had time to refactor to 1.4.x I am having nightmares about future refactorings to 1.5 or 1.6 so I am investing as much as I can on 1.4 ;) >> Meanwhile we can test-drive it in 1.4. >> > Please do and report ;-) Until now, only happy news :) ** Martin >> > >> >> >> >> 2011/1/20 Jeremy Thomerson : >> >> > On Wed, Jan 19, 2011 at 3:55 AM, Martin Makundi < >> >> > martin.maku...@koodaripalvelut.com> wrote: >> >> > >> >> >> Can we bargain about this? Say, also wicket auto ajax enclosure and >> >> >> both into 1.4-x >> >> >> >> >> > >> >> > This made me laugh. What is the other side of the "bargain"? What >> does >> >> the >> >> > giving party get in return? :) >> >> > >> >> > Apache is all about consensus. If the project management committee >> (who >> >> > ultimately has to lead and guide the project) agrees that something is >> >> > useful, beneficial, and not detrimental, they allow it to be added by >> the >> >> > committers. In the case of Wicket, each committer is also on the PMC. >> >> So, >> >> > with several committers against this feature being added to 1.4.x >> (myself >> >> > included) and possibly even 1.5, you must persuade them (us) as to why >> it >> >> is >> >> > needed. >> >> > >> >> > That being said, this has already been a really long thread (over 100 >> >> > messages), so you're up against bad odds. >> >> > >> >> > -- >> >> > Jeremy Thomerson >> >> > http://wickettraining.com >> >> > *Need a CMS for Wicket? Use Brix! http://brixcms.org* >> >> > >> >> >> >> - >> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >> >> >> > >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Thu, Jan 20, 2011 at 9:14 PM, Martin Makundi <
martin.maku...@koodaripalvelut.com> wrote:
> Quote from Igor
>
> http://apache-wicket.1842946.n4.nabble.com/Free-wicket-from-component-hierarchy-hell-td3027705i160.html
>
> > > If in doubt, there is always
> getMarkupSettings().setAllowComponentAutoHierarchy(false);
> > there will be no such method.
>
> +1 for not making this part of core.
>
> >> ..hrm.. putting that aside, did you give it a test drive?
> >
> > Martin, I know you started the thread about this idea last time.
> > I'm wondering do you work together with Giannis and do you use the 1.4 in
> > production ?
>
> Giannis is in our team yes but Giannis forked this mostly with help from
> Igor.
>
> Yes, we use 1.4 in production.
>
I meant: do you use 1.4 + the patch in production ?
>
> > In the beginning I was also against this idea but then I saw Igor's work
> and
> > I started believing in it.
> > Once we release 1.5 final I think we can introduce this in 1.5.{1,2}.
>
> Meanwhile we can test-drive it in 1.4.
>
Please do and report ;-)
>
> **
> Martin
>
> >
> >>
> >> 2011/1/20 Jeremy Thomerson :
> >> > On Wed, Jan 19, 2011 at 3:55 AM, Martin Makundi <
> >> > martin.maku...@koodaripalvelut.com> wrote:
> >> >
> >> >> Can we bargain about this? Say, also wicket auto ajax enclosure and
> >> >> both into 1.4-x
> >> >>
> >> >
> >> > This made me laugh. What is the other side of the "bargain"? What
> does
> >> the
> >> > giving party get in return? :)
> >> >
> >> > Apache is all about consensus. If the project management committee
> (who
> >> > ultimately has to lead and guide the project) agrees that something is
> >> > useful, beneficial, and not detrimental, they allow it to be added by
> the
> >> > committers. In the case of Wicket, each committer is also on the PMC.
> >> So,
> >> > with several committers against this feature being added to 1.4.x
> (myself
> >> > included) and possibly even 1.5, you must persuade them (us) as to why
> it
> >> is
> >> > needed.
> >> >
> >> > That being said, this has already been a really long thread (over 100
> >> > messages), so you're up against bad odds.
> >> >
> >> > --
> >> > Jeremy Thomerson
> >> > http://wickettraining.com
> >> > *Need a CMS for Wicket? Use Brix! http://brixcms.org*
> >> >
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> For additional commands, e-mail: users-h...@wicket.apache.org
> >>
> >>
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
Re: Free wicket from component hierarchy hell
Quote from Igor
http://apache-wicket.1842946.n4.nabble.com/Free-wicket-from-component-hierarchy-hell-td3027705i160.html
> > If in doubt, there is always
> > getMarkupSettings().setAllowComponentAutoHierarchy(false);
> there will be no such method.
+1 for not making this part of core.
>> ..hrm.. putting that aside, did you give it a test drive?
>
> Martin, I know you started the thread about this idea last time.
> I'm wondering do you work together with Giannis and do you use the 1.4 in
> production ?
Giannis is in our team yes but Giannis forked this mostly with help from Igor.
Yes, we use 1.4 in production.
> In the beginning I was also against this idea but then I saw Igor's work and
> I started believing in it.
> Once we release 1.5 final I think we can introduce this in 1.5.{1,2}.
Meanwhile we can test-drive it in 1.4.
**
Martin
>
>>
>> 2011/1/20 Jeremy Thomerson :
>> > On Wed, Jan 19, 2011 at 3:55 AM, Martin Makundi <
>> > martin.maku...@koodaripalvelut.com> wrote:
>> >
>> >> Can we bargain about this? Say, also wicket auto ajax enclosure and
>> >> both into 1.4-x
>> >>
>> >
>> > This made me laugh. What is the other side of the "bargain"? What does
>> the
>> > giving party get in return? :)
>> >
>> > Apache is all about consensus. If the project management committee (who
>> > ultimately has to lead and guide the project) agrees that something is
>> > useful, beneficial, and not detrimental, they allow it to be added by the
>> > committers. In the case of Wicket, each committer is also on the PMC.
>> So,
>> > with several committers against this feature being added to 1.4.x (myself
>> > included) and possibly even 1.5, you must persuade them (us) as to why it
>> is
>> > needed.
>> >
>> > That being said, this has already been a really long thread (over 100
>> > messages), so you're up against bad odds.
>> >
>> > --
>> > Jeremy Thomerson
>> > http://wickettraining.com
>> > *Need a CMS for Wicket? Use Brix! http://brixcms.org*
>> >
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Thu, Jan 20, 2011 at 6:24 PM, Martin Makundi <
martin.maku...@koodaripalvelut.com> wrote:
> http://farm5.static.flickr.com/4089/4968160827_b742a7448a_z.jpg
>
> ..hrm.. putting that aside, did you give it a test drive?
>
Martin, I know you started the thread about this idea last time.
I'm wondering do you work together with Giannis and do you use the 1.4 in
production ?
In the beginning I was also against this idea but then I saw Igor's work and
I started believing in it.
Once we release 1.5 final I think we can introduce this in 1.5.{1,2}.
>
> **
> Martin
>
> 2011/1/20 Jeremy Thomerson :
> > On Wed, Jan 19, 2011 at 3:55 AM, Martin Makundi <
> > martin.maku...@koodaripalvelut.com> wrote:
> >
> >> Can we bargain about this? Say, also wicket auto ajax enclosure and
> >> both into 1.4-x
> >>
> >
> > This made me laugh. What is the other side of the "bargain"? What does
> the
> > giving party get in return? :)
> >
> > Apache is all about consensus. If the project management committee (who
> > ultimately has to lead and guide the project) agrees that something is
> > useful, beneficial, and not detrimental, they allow it to be added by the
> > committers. In the case of Wicket, each committer is also on the PMC.
> So,
> > with several committers against this feature being added to 1.4.x (myself
> > included) and possibly even 1.5, you must persuade them (us) as to why it
> is
> > needed.
> >
> > That being said, this has already been a really long thread (over 100
> > messages), so you're up against bad odds.
> >
> > --
> > Jeremy Thomerson
> > http://wickettraining.com
> > *Need a CMS for Wicket? Use Brix! http://brixcms.org*
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
Re: Free wicket from component hierarchy hell
On Thu, Jan 20, 2011 at 4:41 PM, Giannis Koutsoubos wrote: > > 1.5 port https://github.com/koutsoub/wicket/tree/component_queuing_1.5 > https://github.com/koutsoub/wicket/tree/component_queuing_1.5 Thanks, Giannis! > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Free-wicket-from-component-hierarchy-hell-tp3027705p3226581.html > Sent from the Users forum mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Free wicket from component hierarchy hell
On Thu, Jan 20, 2011 at 11:50 AM, Jim Pinkham wrote: > I still don't think it's necessary, and wonder if it might actually be > counter-productive to have more than one way to learn for new adopters. If > it goes forward, I don't suppose there's much precedent for taking > something > back out, is there? > This is the key for me. I make my living off of teaching Wicket classes. New people to Wicket always make mistakes with models and a few other things. But after the first morning of class, they almost *never* have a problem with component hierarchies. BUT - if we add two ways of building a hierarchy, and one of them is a little "magical", then it gets difficult. It's too bad we don't have mixins in Java - it would be nice to be able to have this feature as an entirely separate jar that could be added. I guess you could do it now, but rather than calling #queue(compToBeQueued) on your component, you'd have to use something like ComponentQueue#queue(component, compToBeQueued). That could store it in metadata like the current implementation (if it hasn't changed since the last time I looked at the code), and then an onbeforerender listener might be able to de-queue everything. I'd have no problem with it being an "add-on" that isn't in the core Component. > What a difficult discussion to have over email - I'm in the -1 camp on this > overall, but I think I do appreciate the admirable motive to innovate, so I > hope the committers will give this serious consideration and then chuck it > in the bin where it ... no, just kidding, ;) and then make a fair > decision. > We never dismiss things off-hand, and will give it consideration. But we have to consider both new and advanced users. I just don't think there's enough of a use-case requirement for it to justify the confusion that I *know* it will cause. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Free wicket from component hierarchy hell
I'm not a committer, just a normal 1.5 user concerned about bloat. For what it's worth, I took a few minutes to actually look at the change (MarkupContainer as you'd expect) and I can see that if you don't use the new queue methods, the only a memory overhead is the *static* QUEUE (nothing extra per component!) so I appreciate that performance-wise anyway, it's a low impact feature you can ignore without penalty. I'm not thrilled about the conceptual impact of adding a new concern to an already large class, but the implementation looks quite nice actually, so my first concern that it might break existing behavior is satisfied. I still don't think it's necessary, and wonder if it might actually be counter-productive to have more than one way to learn for new adopters. If it goes forward, I don't suppose there's much precedent for taking something back out, is there? What a difficult discussion to have over email - I'm in the -1 camp on this overall, but I think I do appreciate the admirable motive to innovate, so I hope the committers will give this serious consideration and then chuck it in the bin where it ... no, just kidding, ;) and then make a fair decision. Thanks, --Jim Pinkham. On Thu, Jan 20, 2011 at 12:24 PM, Martin Makundi < martin.maku...@koodaripalvelut.com> wrote: > http://farm5.static.flickr.com/4089/4968160827_b742a7448a_z.jpg > > ..hrm.. putting that aside, did you give it a test drive? > > ** > Martin > > 2011/1/20 Jeremy Thomerson : > > On Wed, Jan 19, 2011 at 3:55 AM, Martin Makundi < > > martin.maku...@koodaripalvelut.com> wrote: > > > >> Can we bargain about this? Say, also wicket auto ajax enclosure and > >> both into 1.4-x > >> > > > > This made me laugh. What is the other side of the "bargain"? What does > the > > giving party get in return? :) > > > > Apache is all about consensus. If the project management committee (who > > ultimately has to lead and guide the project) agrees that something is > > useful, beneficial, and not detrimental, they allow it to be added by the > > committers. In the case of Wicket, each committer is also on the PMC. > So, > > with several committers against this feature being added to 1.4.x (myself > > included) and possibly even 1.5, you must persuade them (us) as to why it > is > > needed. > > > > That being said, this has already been a really long thread (over 100 > > messages), so you're up against bad odds. > > > > -- > > Jeremy Thomerson > > http://wickettraining.com > > *Need a CMS for Wicket? Use Brix! http://brixcms.org* > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Free wicket from component hierarchy hell
On Thu, Jan 20, 2011 at 11:24 AM, Martin Makundi < martin.maku...@koodaripalvelut.com> wrote: > ..hrm.. putting that aside, did you give it a test drive? > No, I haven't. Because keeping the two hierarchies in sync has never been a problem on any project that I worked on. Typically, the hierarchies are very shallow anyway because of breaking things into panels and reusable components. So, with shallow hierarchies, it really doesn't bring much benefit to the table. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Free wicket from component hierarchy hell
http://farm5.static.flickr.com/4089/4968160827_b742a7448a_z.jpg ..hrm.. putting that aside, did you give it a test drive? ** Martin 2011/1/20 Jeremy Thomerson : > On Wed, Jan 19, 2011 at 3:55 AM, Martin Makundi < > martin.maku...@koodaripalvelut.com> wrote: > >> Can we bargain about this? Say, also wicket auto ajax enclosure and >> both into 1.4-x >> > > This made me laugh. What is the other side of the "bargain"? What does the > giving party get in return? :) > > Apache is all about consensus. If the project management committee (who > ultimately has to lead and guide the project) agrees that something is > useful, beneficial, and not detrimental, they allow it to be added by the > committers. In the case of Wicket, each committer is also on the PMC. So, > with several committers against this feature being added to 1.4.x (myself > included) and possibly even 1.5, you must persuade them (us) as to why it is > needed. > > That being said, this has already been a really long thread (over 100 > messages), so you're up against bad odds. > > -- > Jeremy Thomerson > http://wickettraining.com > *Need a CMS for Wicket? Use Brix! http://brixcms.org* > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Wed, Jan 19, 2011 at 3:55 AM, Martin Makundi < martin.maku...@koodaripalvelut.com> wrote: > Can we bargain about this? Say, also wicket auto ajax enclosure and > both into 1.4-x > This made me laugh. What is the other side of the "bargain"? What does the giving party get in return? :) Apache is all about consensus. If the project management committee (who ultimately has to lead and guide the project) agrees that something is useful, beneficial, and not detrimental, they allow it to be added by the committers. In the case of Wicket, each committer is also on the PMC. So, with several committers against this feature being added to 1.4.x (myself included) and possibly even 1.5, you must persuade them (us) as to why it is needed. That being said, this has already been a really long thread (over 100 messages), so you're up against bad odds. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Free wicket from component hierarchy hell
1.5 port https://github.com/koutsoub/wicket/tree/component_queuing_1.5 https://github.com/koutsoub/wicket/tree/component_queuing_1.5 -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Free-wicket-from-component-hierarchy-hell-tp3027705p3226581.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
Can we bargain about this? Say, also wicket auto ajax enclosure and both into 1.4-x? ** Martin 2011/1/18 Jeremy Thomerson : > I agree. I'm -0 in general, and definitely -1 for 1.4 and -0.9 for 1.5. > > On Tue, Jan 18, 2011 at 3:54 AM, Martijn Dashorst < > martijn.dasho...@gmail.com> wrote: > >> On Tue, Jan 18, 2011 at 10:43 AM, Martin Grigorov >> wrote: >> > Please port the patch to 1.5/trunk and then we can talk about adding it >> in >> > early 1.5.x versions. >> >> I would be wary about adding this to 1.5 as well (that is -1 for 1.5). >> 1.6 will be a fine place for this to get ironed out. >> >> Martijn >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > > -- > Jeremy Thomerson > http://wickettraining.com > *Need a CMS for Wicket? Use Brix! http://brixcms.org* > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
I agree. I'm -0 in general, and definitely -1 for 1.4 and -0.9 for 1.5. On Tue, Jan 18, 2011 at 3:54 AM, Martijn Dashorst < martijn.dasho...@gmail.com> wrote: > On Tue, Jan 18, 2011 at 10:43 AM, Martin Grigorov > wrote: > > Please port the patch to 1.5/trunk and then we can talk about adding it > in > > early 1.5.x versions. > > I would be wary about adding this to 1.5 as well (that is -1 for 1.5). > 1.6 will be a fine place for this to get ironed out. > > Martijn > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Free wicket from component hierarchy hell
On Tue, Jan 18, 2011 at 10:43 AM, Martin Grigorov wrote: > Please port the patch to 1.5/trunk and then we can talk about adding it in > early 1.5.x versions. I would be wary about adding this to 1.5 as well (that is -1 for 1.5). 1.6 will be a fine place for this to get ironed out. Martijn - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
-1 for 1.4.x as well. No need to add this to current wicket. If it is so important, wicket is open source, and you can readily port it yourself. Martijn On Tue, Jan 18, 2011 at 10:43 AM, Martin Grigorov wrote: > I don't take decisions alone but I'd vote -1 for 1.4.x. > > 1.4.x is the stable version and I don't want to compromise it with feature > that is neither a regression nor a security hole. > Please port the patch to 1.5/trunk and then we can talk about adding it in > early 1.5.x versions. > > 1.5-RC1 will be re-released in the next 24 hours. > Please test it and file tickets for regressions. As soon as we release it we > will have time to add new features. > Thanks! > > On Tue, Jan 18, 2011 at 10:25 AM, Martin Makundi < > martin.maku...@koodaripalvelut.com> wrote: > >> Hi! >> >> We would like to see it in 1.4, if possible. >> >> ** >> Martin >> >> 2011/1/18 Martin Grigorov : >> > This wont go in Wicket 1.5. >> > If there are no issues then most probably it will be included in 1.6 >> > Thanks ! >> > >> > On Tue, Jan 18, 2011 at 10:04 AM, Giannis Koutsoubos > >wrote: >> > >> >> >> >> Jira issue https://issues.apache.org/jira/browse/WICKET-3335 >> >> https://issues.apache.org/jira/browse/WICKET-3335 >> >> >> >> -- >> >> View this message in context: >> >> >> http://apache-wicket.1842946.n4.nabble.com/Free-wicket-from-component-hierarchy-hell-tp3027705p3221292.html >> >> Sent from the Users forum mailing list archive at Nabble.com. >> >> >> >> - >> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >> >> >> > >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > -- Become a Wicket expert, learn from the best: http://wicketinaction.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
I vote +1 for also 1.4.x because this feature does not compromise anything, it is just an alternate way of adding components. ** Martin 2011/1/18 Martin Grigorov : > I don't take decisions alone but I'd vote -1 for 1.4.x. > > 1.4.x is the stable version and I don't want to compromise it with feature > that is neither a regression nor a security hole. > Please port the patch to 1.5/trunk and then we can talk about adding it in > early 1.5.x versions. > > 1.5-RC1 will be re-released in the next 24 hours. > Please test it and file tickets for regressions. As soon as we release it we > will have time to add new features. > Thanks! > > On Tue, Jan 18, 2011 at 10:25 AM, Martin Makundi < > martin.maku...@koodaripalvelut.com> wrote: > >> Hi! >> >> We would like to see it in 1.4, if possible. >> >> ** >> Martin >> >> 2011/1/18 Martin Grigorov : >> > This wont go in Wicket 1.5. >> > If there are no issues then most probably it will be included in 1.6 >> > Thanks ! >> > >> > On Tue, Jan 18, 2011 at 10:04 AM, Giannis Koutsoubos > >wrote: >> > >> >> >> >> Jira issue https://issues.apache.org/jira/browse/WICKET-3335 >> >> https://issues.apache.org/jira/browse/WICKET-3335 >> >> >> >> -- >> >> View this message in context: >> >> >> http://apache-wicket.1842946.n4.nabble.com/Free-wicket-from-component-hierarchy-hell-tp3027705p3221292.html >> >> Sent from the Users forum mailing list archive at Nabble.com. >> >> >> >> - >> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >> >> >> > >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
I don't take decisions alone but I'd vote -1 for 1.4.x. 1.4.x is the stable version and I don't want to compromise it with feature that is neither a regression nor a security hole. Please port the patch to 1.5/trunk and then we can talk about adding it in early 1.5.x versions. 1.5-RC1 will be re-released in the next 24 hours. Please test it and file tickets for regressions. As soon as we release it we will have time to add new features. Thanks! On Tue, Jan 18, 2011 at 10:25 AM, Martin Makundi < martin.maku...@koodaripalvelut.com> wrote: > Hi! > > We would like to see it in 1.4, if possible. > > ** > Martin > > 2011/1/18 Martin Grigorov : > > This wont go in Wicket 1.5. > > If there are no issues then most probably it will be included in 1.6 > > Thanks ! > > > > On Tue, Jan 18, 2011 at 10:04 AM, Giannis Koutsoubos >wrote: > > > >> > >> Jira issue https://issues.apache.org/jira/browse/WICKET-3335 > >> https://issues.apache.org/jira/browse/WICKET-3335 > >> > >> -- > >> View this message in context: > >> > http://apache-wicket.1842946.n4.nabble.com/Free-wicket-from-component-hierarchy-hell-tp3027705p3221292.html > >> Sent from the Users forum mailing list archive at Nabble.com. > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> For additional commands, e-mail: users-h...@wicket.apache.org > >> > >> > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Free wicket from component hierarchy hell
Hi! We would like to see it in 1.4, if possible. ** Martin 2011/1/18 Martin Grigorov : > This wont go in Wicket 1.5. > If there are no issues then most probably it will be included in 1.6 > Thanks ! > > On Tue, Jan 18, 2011 at 10:04 AM, Giannis Koutsoubos > wrote: > >> >> Jira issue https://issues.apache.org/jira/browse/WICKET-3335 >> https://issues.apache.org/jira/browse/WICKET-3335 >> >> -- >> View this message in context: >> http://apache-wicket.1842946.n4.nabble.com/Free-wicket-from-component-hierarchy-hell-tp3027705p3221292.html >> Sent from the Users forum mailing list archive at Nabble.com. >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
This wont go in Wicket 1.5. If there are no issues then most probably it will be included in 1.6 Thanks ! On Tue, Jan 18, 2011 at 10:04 AM, Giannis Koutsoubos wrote: > > Jira issue https://issues.apache.org/jira/browse/WICKET-3335 > https://issues.apache.org/jira/browse/WICKET-3335 > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Free-wicket-from-component-hierarchy-hell-tp3027705p3221292.html > Sent from the Users forum mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Free wicket from component hierarchy hell
Jira issue https://issues.apache.org/jira/browse/WICKET-3335 https://issues.apache.org/jira/browse/WICKET-3335 -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Free-wicket-from-component-hierarchy-hell-tp3027705p3221292.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
I've done some work based on Igor's implementation of component queuing. It can be found here : https://github.com/koutsoub/wicket/tree/component-queuing https://github.com/koutsoub/wicket/tree/component-queuing The code is written against the 1.4.x branch, i'm also working on making it compatible with 1.5 trunk Right now the following are supported: queue method extracts hierarchy from markup files using queue and add method together nested queue methods (queue works like add) queue method working on ListItem You can have a look at ComponentQueuingTest.java with some tests with basic usage i'll raise an issue in jira with a patch during weekend Feedback and suggestions are appreciated especially more testing scenarios -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Free-wicket-from-component-hierarchy-hell-tp3027705p3218010.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
you guys are both making an argument against queuing, and against each-other. paradox. -igor On Wed, Nov 10, 2010 at 5:08 AM, Carl-Eric Menzel wrote: > On Wed, 10 Nov 2010 07:31:28 -0500 > James Carman wrote: > >> On Wed, Nov 10, 2010 at 3:49 AM, Carl-Eric Menzel >> wrote: >> > >> > So either there is a difference between the forms (different submit >> > method maybe?), then this move would make a semantic/behavioral >> > difference and needs to be done in code. >> > >> >> As I said, the two forms edit different values on the same object. >> Yes, this change would be a semantic/behavioral change, but you could >> actually do it with just a change in the markup. It wouldn't require >> a change to the code. This is assuming you queue the fields onto the >> containing panel and not onto the contained forms, which is entirely >> possible (and even likely). How many times have you accidentally >> called add() when you meant to call rowItem.add() in a repeater? With >> the queue() method, you wouldn't get an error message saying the >> markup doesn't match. It would just figure it out and you'd be none >> the wiser. > > That's exactly my point :-) > > This is not a good example to allow queuing, because there's no gain. > Either there is an important difference between the two forms, then it > doesn't make sense to queue *above* the forms, or there is no > difference between the forms, then you can just have *one* form and not > need queue at all. > > By "needs to be done in code" I mean that it is not something that > should be doable in markup. > > Carl-Eric > www.wicketbuch.de > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Wed, Nov 10, 2010 at 1:05 AM, Carl-Eric Menzel wrote: > On Tue, 9 Nov 2010 12:16:00 -0800 > Igor Vaynberg wrote: > >> the difficult part is that doing this to complex pages is...difficult. >> in the example above it is easy to see the two components that need to >> be renested. but, in complex pages there can be 20 components that >> need to be renested, and they are probably initially added from a >> bunch of helper methods that attempted to keep the code clean. so, it >> may be difficult to find all 20 componets. queuing can make >> maintenance and refactoring of pages easier. > > I can see how it might make it somewhat easier, but it seems to me that > one is treading on rather thin ice. well. the thin ice part of the argument remains to be proven. when can it cause problems? how about some practical examples? > And speaking of these helper methods: Maybe it's my increasingly > functional style coming from some exposure to Scala, but I really hate > it when these methods add stuff behind my back to anything else than > the component they're returning. you are explicitly telling it to add things behind your back. the queue() method does not replace the add(), its an addition. it operates on a container, so it returns the container back - that makes sense. >> yes, ive had to do it plenty times. ive had to go into pages that were >> already written and ajaxify them. sometimes a table needs to be >> updated via ajax, it needs to be wrapped in a container. other times a >> set of related form fields needs to be updated, its easier to wrap >> them in a container and update it rather then having to add them one >> by one from multiple places. > > But wouldn't such a page be a prime candidate for a proper refactoring > anyway? I'm getting a "quick & dirty" feeling. not at all. adding three or four ajax-zones into an existing page does not warrant a refactor, nor would there be anything to refactor. there was no need for these things before, they are there purely to facilitate the new requirement of making something ajaxy. -igor > >> > IMHO valid use cases have not been provided yet. >> >> we can agree to disagree > > Certainly, especially since you do make some valid arguments. > > Carl-Eric > www.wicketbuch.de > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
i can only hazard a guess, but if i did it would be that "it was the simplest and cleanest solution that made sense". that is always a good starting point. -igor On Wed, Nov 10, 2010 at 6:19 AM, Frank Silbermann wrote: > What were the reasons for requiring the hierarchies to match in the > original design of Wicket? > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Wed, Nov 10, 2010 at 8:08 AM, Carl-Eric Menzel wrote: > > That's exactly my point :-) > > This is not a good example to allow queuing, because there's no gain. > Either there is an important difference between the two forms, then it > doesn't make sense to queue *above* the forms, or there is no > difference between the forms, then you can just have *one* form and not > need queue at all. > > By "needs to be done in code" I mean that it is not something that > should be doable in markup. > Again, the main point I was making is that with queuing, it is possible that the markup can be used to change behavior. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Free wicket from component hierarchy hell
What were the reasons for requiring the hierarchies to match in the original design of Wicket? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Wed, 10 Nov 2010 07:31:28 -0500 James Carman wrote: > On Wed, Nov 10, 2010 at 3:49 AM, Carl-Eric Menzel > wrote: > > > > So either there is a difference between the forms (different submit > > method maybe?), then this move would make a semantic/behavioral > > difference and needs to be done in code. > > > > As I said, the two forms edit different values on the same object. > Yes, this change would be a semantic/behavioral change, but you could > actually do it with just a change in the markup. It wouldn't require > a change to the code. This is assuming you queue the fields onto the > containing panel and not onto the contained forms, which is entirely > possible (and even likely). How many times have you accidentally > called add() when you meant to call rowItem.add() in a repeater? With > the queue() method, you wouldn't get an error message saying the > markup doesn't match. It would just figure it out and you'd be none > the wiser. That's exactly my point :-) This is not a good example to allow queuing, because there's no gain. Either there is an important difference between the two forms, then it doesn't make sense to queue *above* the forms, or there is no difference between the forms, then you can just have *one* form and not need queue at all. By "needs to be done in code" I mean that it is not something that should be doable in markup. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, 9 Nov 2010 12:16:00 -0800 Igor Vaynberg wrote: > the difficult part is that doing this to complex pages is...difficult. > in the example above it is easy to see the two components that need to > be renested. but, in complex pages there can be 20 components that > need to be renested, and they are probably initially added from a > bunch of helper methods that attempted to keep the code clean. so, it > may be difficult to find all 20 componets. queuing can make > maintenance and refactoring of pages easier. I can see how it might make it somewhat easier, but it seems to me that one is treading on rather thin ice. And speaking of these helper methods: Maybe it's my increasingly functional style coming from some exposure to Scala, but I really hate it when these methods add stuff behind my back to anything else than the component they're returning. > yes, ive had to do it plenty times. ive had to go into pages that were > already written and ajaxify them. sometimes a table needs to be > updated via ajax, it needs to be wrapped in a container. other times a > set of related form fields needs to be updated, its easier to wrap > them in a container and update it rather then having to add them one > by one from multiple places. But wouldn't such a page be a prime candidate for a proper refactoring anyway? I'm getting a "quick & dirty" feeling. > > IMHO valid use cases have not been provided yet. > > we can agree to disagree Certainly, especially since you do make some valid arguments. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, 9 Nov 2010 12:17:38 -0800 Igor Vaynberg wrote: > i wonder if queuing can actually replace icomponentresolver and > auto-adding. i wonder if after onbeforerender we can do what unqueing > does now, parse the markup, find any missing components, and insert > them. autocomponents and autoadd() is something ive always disliked > because it doesnt work for anything that needs to stick around across > requests. I was initially opposed to the "liquid hierarchy" idea, and still do not like the original proposal. *This* however makes things much more interesting. I think this may actually be useful. Initial thoughts about this: What about the assumptions in onBeforeRender? What are the consequences of having the queued components available only after that phase? Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Wed, Nov 10, 2010 at 3:49 AM, Carl-Eric Menzel wrote: > > So either there is a difference between the forms (different submit > method maybe?), then this move would make a semantic/behavioral > difference and needs to be done in code. > As I said, the two forms edit different values on the same object. Yes, this change would be a semantic/behavioral change, but you could actually do it with just a change in the markup. It wouldn't require a change to the code. This is assuming you queue the fields onto the containing panel and not onto the contained forms, which is entirely possible (and even likely). How many times have you accidentally called add() when you meant to call rowItem.add() in a repeater? With the queue() method, you wouldn't get an error message saying the markup doesn't match. It would just figure it out and you'd be none the wiser. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, 9 Nov 2010 11:49:32 -0500 James Carman wrote: > > Are you moving a field from one form to another? But that does > > change the semantics, doesn't it? If it doesn't, why are there two > > forms? > > > > Both forms "edit" one particular object (say a Person). They just > edit different values on the same object. Again, I'm not sure this is > the best example, but it's at least plausible. So either there is a difference between the forms (different submit method maybe?), then this move would make a semantic/behavioral difference and needs to be done in code. Or there is no difference at all. Why are there two forms then? Just use one. No offense meant, but this does not seem to be a plausible example to me. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
t;>> textfield.isEnabledInHierachy() will then ofcourse not get to the
>>>>>>>>> parent it is on.
>>>>>>>>> because its parent is the webpage not the body markupcontainer.
>>>>>>>>>
>>>>>>>>> So no this will not resolver from the child to the parent, only the
>>>>>>>>> parent to the child.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Nov 9, 2010 at 19:30, Martin Makundi
>>>>>>>>> wrote:
>>>>>>>>>> How will it work if I call get("body").setEnabled(false); and if
>>>>>>>>>> label
>>>>>>>>>> was a textfield? Would the textfield be still enabled?
>>>>>>>>>>
>>>>>>>>>> **
>>>>>>>>>> Martin
>>>>>>>>>>
>>>>>>>>>> 2010/11/9 Johan Compagner :
>>>>>>>>>>> no ofcourse not
>>>>>>>>>>> The label will then be gone because the body is gone.
>>>>>>>>>>> so the output will be this
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> when the body container is not visible
>>>>>>>>>>>
>>>>>>>>>>> if the label is not visible:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> this solution you just can throw everything in the panel or webpage
>>>>>>>>>>> that is the IComponentResolver for all its childs...
>>>>>>>>>>> Just look at how the code works..
>>>>>>>>>>> IF a component can't be found on its own parent the
>>>>>>>>>>> ComponentResolver
>>>>>>>>>>> will ask all the parents which can be IComponentResolver to render
>>>>>>>>>>> the
>>>>>>>>>>> child..
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Nov 9, 2010 at 19:04, Martin Makundi
>>>>>>>>>>> wrote:
>>>>>>>>>>>> This does not really nest the components logically, does it?
>>>>>>>>>>>>
>>>>>>>>>>>> If you set get("body").setVisible(false) will the label remain
>>>>>>>>>>>> visible?
>>>>>>>>>>>>
>>>>>>>>>>>> **
>>>>>>>>>>>> Martin
>>>>>>>>>>>>
>>>>>>>>>>>> 2010/11/9 Johan Compagner :
>>>>>>>>>>>>> Why are we discussing here already that works in wicket 1.4 if you
>>>>>>>>>>>>> really need it?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> public class HelloWorld extends WebPage implements
>>>>>>>>>>>>> IComponentResolver {
>>>>>>>>>>>>>
>>>>>>>>>>>>> public HelloWorld()
>>>>>>>>>>>>> {
>>>>>>>>>>>>> add(new WebMarkupContainer("body"));
>>>>>>>>>>>>> add(new Label("label","my label"));
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> public boolean resolve(MarkupContainer container,
>>>>>>>>>>>>> MarkupStream markupStream, ComponentTag
>>>>>>>>>>>>> tag) {
>>>>>>>>
Re: Free wicket from component hierarchy hell
, Nov 9, 2010 at 19:30, Martin Makundi
>>>>>>>> wrote:
>>>>>>>>> How will it work if I call get("body").setEnabled(false); and if label
>>>>>>>>> was a textfield? Would the textfield be still enabled?
>>>>>>>>>
>>>>>>>>> **
>>>>>>>>> Martin
>>>>>>>>>
>>>>>>>>> 2010/11/9 Johan Compagner :
>>>>>>>>>> no ofcourse not
>>>>>>>>>> The label will then be gone because the body is gone.
>>>>>>>>>> so the output will be this
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> when the body container is not visible
>>>>>>>>>>
>>>>>>>>>> if the label is not visible:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> this solution you just can throw everything in the panel or webpage
>>>>>>>>>> that is the IComponentResolver for all its childs...
>>>>>>>>>> Just look at how the code works..
>>>>>>>>>> IF a component can't be found on its own parent the ComponentResolver
>>>>>>>>>> will ask all the parents which can be IComponentResolver to render
>>>>>>>>>> the
>>>>>>>>>> child..
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Nov 9, 2010 at 19:04, Martin Makundi
>>>>>>>>>> wrote:
>>>>>>>>>>> This does not really nest the components logically, does it?
>>>>>>>>>>>
>>>>>>>>>>> If you set get("body").setVisible(false) will the label remain
>>>>>>>>>>> visible?
>>>>>>>>>>>
>>>>>>>>>>> **
>>>>>>>>>>> Martin
>>>>>>>>>>>
>>>>>>>>>>> 2010/11/9 Johan Compagner :
>>>>>>>>>>>> Why are we discussing here already that works in wicket 1.4 if you
>>>>>>>>>>>> really need it?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> public class HelloWorld extends WebPage implements
>>>>>>>>>>>> IComponentResolver {
>>>>>>>>>>>>
>>>>>>>>>>>> public HelloWorld()
>>>>>>>>>>>> {
>>>>>>>>>>>> add(new WebMarkupContainer("body"));
>>>>>>>>>>>> add(new Label("label","my label"));
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> public boolean resolve(MarkupContainer container,
>>>>>>>>>>>> MarkupStream markupStream, ComponentTag
>>>>>>>>>>>> tag) {
>>>>>>>>>>>>
>>>>>>>>>>>> Component component = get(tag.getId());
>>>>>>>>>>>> if (component != null)
>>>>>>>>>>>> {
>>>>>>>>>>>> component.render(markupStream);
>>>>>>>>>>>> return true;
>>>>>>>>>>>> }
>>>>>>>>>>>> return false;
>>>>>>>>>>>> }
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>&g
Re: Free wicket from component hierarchy hell
2010/11/9 Johan Compagner :
>>>>>>>>> no ofcourse not
>>>>>>>>> The label will then be gone because the body is gone.
>>>>>>>>> so the output will be this
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> when the body container is not visible
>>>>>>>>>
>>>>>>>>> if the label is not visible:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> this solution you just can throw everything in the panel or webpage
>>>>>>>>> that is the IComponentResolver for all its childs...
>>>>>>>>> Just look at how the code works..
>>>>>>>>> IF a component can't be found on its own parent the ComponentResolver
>>>>>>>>> will ask all the parents which can be IComponentResolver to render the
>>>>>>>>> child..
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Nov 9, 2010 at 19:04, Martin Makundi
>>>>>>>>> wrote:
>>>>>>>>>> This does not really nest the components logically, does it?
>>>>>>>>>>
>>>>>>>>>> If you set get("body").setVisible(false) will the label remain
>>>>>>>>>> visible?
>>>>>>>>>>
>>>>>>>>>> **
>>>>>>>>>> Martin
>>>>>>>>>>
>>>>>>>>>> 2010/11/9 Johan Compagner :
>>>>>>>>>>> Why are we discussing here already that works in wicket 1.4 if you
>>>>>>>>>>> really need it?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> public class HelloWorld extends WebPage implements
>>>>>>>>>>> IComponentResolver {
>>>>>>>>>>>
>>>>>>>>>>> public HelloWorld()
>>>>>>>>>>> {
>>>>>>>>>>> add(new WebMarkupContainer("body"));
>>>>>>>>>>> add(new Label("label","my label"));
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> public boolean resolve(MarkupContainer container,
>>>>>>>>>>> MarkupStream markupStream, ComponentTag tag)
>>>>>>>>>>> {
>>>>>>>>>>>
>>>>>>>>>>> Component component = get(tag.getId());
>>>>>>>>>>> if (component != null)
>>>>>>>>>>> {
>>>>>>>>>>> component.render(markupStream);
>>>>>>>>>>> return true;
>>>>>>>>>>> }
>>>>>>>>>>> return false;
>>>>>>>>>>> }
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Nov 9, 2010 at 16:29, Frank Silbermann
>>>>>>>>>>> wrote:
>>>>>>>>>>>> Progress is made by people who have understanding, not by the
>>>>>>>>>>>> ignorant.
>>>>>>>>>>>> You're not in a position to make suggestions about extending
>>>>>>>>>>>> Wicket if
>>>>>>>>>>>> you don't yet understand how to use the powers it already has.
>>>>>>>>>>>>
>>>>>>>>>>>> -Original Message-
>>>>>>>>>>>> From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com]
>>>>>>>>>>>> Sent: Tuesday, November 09, 2010 9:23 AM
>>>>>>>>>>>> To: users@wicket.apache.org
>>>>>>>>>>>> Subject: Re: Free wicket from component hierarchy hell
>>>>>>>>>>>>
>>>>>>>>>>>>> So instead of asking, "How can we make Wicket different so that my
>>>>>>>>>>>>> problem will go away?" the proper question to try first is, "What
>>>>>>>>>>>>> is
>>>>>>>>>>>> the
>>>>>>>>>>>>> Wicket way of solving my problem?"
>>>>>>>>>>>>
>>>>>>>>>>>> That's not how proggress is made...
>>>>>>>>>>>>
>>>>>>>>>>>> **
>>>>>>>>>>>> Martin
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -
>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>>>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -
>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -
>>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> -
>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> -
>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> -
>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>> -
>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>
>>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
t;>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> this solution you just can throw everything in the panel or webpage
>>>>>>>> that is the IComponentResolver for all its childs...
>>>>>>>> Just look at how the code works..
>>>>>>>> IF a component can't be found on its own parent the ComponentResolver
>>>>>>>> will ask all the parents which can be IComponentResolver to render the
>>>>>>>> child..
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Nov 9, 2010 at 19:04, Martin Makundi
>>>>>>>> wrote:
>>>>>>>>> This does not really nest the components logically, does it?
>>>>>>>>>
>>>>>>>>> If you set get("body").setVisible(false) will the label remain
>>>>>>>>> visible?
>>>>>>>>>
>>>>>>>>> **
>>>>>>>>> Martin
>>>>>>>>>
>>>>>>>>> 2010/11/9 Johan Compagner :
>>>>>>>>>> Why are we discussing here already that works in wicket 1.4 if you
>>>>>>>>>> really need it?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> public class HelloWorld extends WebPage implements
>>>>>>>>>> IComponentResolver {
>>>>>>>>>>
>>>>>>>>>> public HelloWorld()
>>>>>>>>>> {
>>>>>>>>>> add(new WebMarkupContainer("body"));
>>>>>>>>>> add(new Label("label","my label"));
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> public boolean resolve(MarkupContainer container,
>>>>>>>>>> MarkupStream markupStream, ComponentTag tag) {
>>>>>>>>>>
>>>>>>>>>> Component component = get(tag.getId());
>>>>>>>>>> if (component != null)
>>>>>>>>>> {
>>>>>>>>>> component.render(markupStream);
>>>>>>>>>> return true;
>>>>>>>>>> }
>>>>>>>>>> return false;
>>>>>>>>>> }
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Nov 9, 2010 at 16:29, Frank Silbermann
>>>>>>>>>> wrote:
>>>>>>>>>>> Progress is made by people who have understanding, not by the
>>>>>>>>>>> ignorant.
>>>>>>>>>>> You're not in a position to make suggestions about extending Wicket
>>>>>>>>>>> if
>>>>>>>>>>> you don't yet understand how to use the powers it already has.
>>>>>>>>>>>
>>>>>>>>>>> -Original Message-
>>>>>>>>>>> From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com]
>>>>>>>>>>> Sent: Tuesday, November 09, 2010 9:23 AM
>>>>>>>>>>> To: users@wicket.apache.org
>>>>>>>>>>> Subject: Re: Free wicket from component hierarchy hell
>>>>>>>>>>>
>>>>>>>>>>>> So instead of asking, "How can we make Wicket different so that my
>>>>>>>>>>>> problem will go away?" the proper question to try first is, "What
>>>>>>>>>>>> is
>>>>>>>>>>> the
>>>>>>>>>>>> Wicket way of solving my problem?"
>>>>>>>>>>>
>>>>>>>>>>> That's not how proggress is made...
>>>>>>>>>>>
>>>>>>>>>>> **
>>>>>>>>>>> Martin
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -
>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -
>>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> -
>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> -
>>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> -
>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>> -
>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>
>>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
lver
>>>>>>> will ask all the parents which can be IComponentResolver to render the
>>>>>>> child..
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Nov 9, 2010 at 19:04, Martin Makundi
>>>>>>> wrote:
>>>>>>>> This does not really nest the components logically, does it?
>>>>>>>>
>>>>>>>> If you set get("body").setVisible(false) will the label remain visible?
>>>>>>>>
>>>>>>>> **
>>>>>>>> Martin
>>>>>>>>
>>>>>>>> 2010/11/9 Johan Compagner :
>>>>>>>>> Why are we discussing here already that works in wicket 1.4 if you
>>>>>>>>> really need it?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> public class HelloWorld extends WebPage implements IComponentResolver
>>>>>>>>> {
>>>>>>>>>
>>>>>>>>>public HelloWorld()
>>>>>>>>>{
>>>>>>>>>add(new WebMarkupContainer("body"));
>>>>>>>>>add(new Label("label","my label"));
>>>>>>>>>}
>>>>>>>>>
>>>>>>>>>public boolean resolve(MarkupContainer container,
>>>>>>>>>MarkupStream markupStream, ComponentTag tag) {
>>>>>>>>>
>>>>>>>>>Component component = get(tag.getId());
>>>>>>>>>if (component != null)
>>>>>>>>>{
>>>>>>>>>component.render(markupStream);
>>>>>>>>>return true;
>>>>>>>>>}
>>>>>>>>>return false;
>>>>>>>>>}
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, Nov 9, 2010 at 16:29, Frank Silbermann
>>>>>>>>> wrote:
>>>>>>>>>> Progress is made by people who have understanding, not by the
>>>>>>>>>> ignorant.
>>>>>>>>>> You're not in a position to make suggestions about extending Wicket
>>>>>>>>>> if
>>>>>>>>>> you don't yet understand how to use the powers it already has.
>>>>>>>>>>
>>>>>>>>>> -Original Message-
>>>>>>>>>> From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com]
>>>>>>>>>> Sent: Tuesday, November 09, 2010 9:23 AM
>>>>>>>>>> To: users@wicket.apache.org
>>>>>>>>>> Subject: Re: Free wicket from component hierarchy hell
>>>>>>>>>>
>>>>>>>>>>> So instead of asking, "How can we make Wicket different so that my
>>>>>>>>>>> problem will go away?" the proper question to try first is, "What is
>>>>>>>>>> the
>>>>>>>>>>> Wicket way of solving my problem?"
>>>>>>>>>>
>>>>>>>>>> That's not how proggress is made...
>>>>>>>>>>
>>>>>>>>>> **
>>>>>>>>>> Martin
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -
>>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> -
>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> -
>>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> -
>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> -
>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>
>>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
wtf is with all the stupid and, more importantly, broken analogies? if you wouldve kept quiet instead of spouting all this garbage i bet a lot more people wouldve been receptive to the idea. you are digging your own hole. id like to think we are all practical people, so stick to practical points. you want to help yourself? fork my branch, modify the readme to add more examples that illustrate your pain, and create a pull request so i can merge it in. -igor On Tue, Nov 9, 2010 at 1:01 AM, Martin Makundi wrote: > Hi! > >> Coding friction? Yes. Every time I need to look at somebody else's code >> and try to figure out what exactly they did. > > Ah.. so you are trying to solve your problem probably from the wrong > end? If you have bad warriors give them plastic swords so they can > hurt nobody? Training, Coding dojos, Code Reviews, Coding Policies, > Dream teams, ... > >> Please consider the needy ones that would have to deal with this and >> would have to support people who made the mistake of using it :-) > > I don't think there is a substitute for coding skills/talent ;))) > >>> It's just the itchy feeling you get all day long when coding "in the >>> zone". "This unneccessary fuzz is in my way". >> >> If you only write code and never read or need to fix it. > > I understand if you are a consultant it gives you plenty of billable > to code again and again. But my sweetspot is product development and I > need to make flexibly reusable components and unfortunately requiring > html hierarchy to match on different pages makes really messy code on > java side if I try to implement free-from-iherarchy in a manual way (I > must provide various different parent containers to a generic > component so that it can land in the right place). > >> Well that certainly applies the other way around too. It's not for >> everybody, so please don't introduce a new source of bugs into *this* >> toolkit. Also, unless I missed a message (which is possible), so far we >> seem to have a needy *one*, not *ones*. > > Still, I don't think there is a substitute for coding skills/talent ;))) > > ** > Martin > >> >> Carl-Eric >> www.wicketbuch.de >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
;
>>>>>>> 2010/11/9 Johan Compagner :
>>>>>>>> Why are we discussing here already that works in wicket 1.4 if you
>>>>>>>> really need it?
>>>>>>>>
>>>>>>>>
>>>>>>>> public class HelloWorld extends WebPage implements IComponentResolver {
>>>>>>>>
>>>>>>>> public HelloWorld()
>>>>>>>> {
>>>>>>>> add(new WebMarkupContainer("body"));
>>>>>>>> add(new Label("label","my label"));
>>>>>>>> }
>>>>>>>>
>>>>>>>> public boolean resolve(MarkupContainer container,
>>>>>>>> MarkupStream markupStream, ComponentTag tag) {
>>>>>>>>
>>>>>>>> Component component = get(tag.getId());
>>>>>>>> if (component != null)
>>>>>>>> {
>>>>>>>> component.render(markupStream);
>>>>>>>> return true;
>>>>>>>> }
>>>>>>>> return false;
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Nov 9, 2010 at 16:29, Frank Silbermann
>>>>>>>> wrote:
>>>>>>>>> Progress is made by people who have understanding, not by the
>>>>>>>>> ignorant.
>>>>>>>>> You're not in a position to make suggestions about extending Wicket if
>>>>>>>>> you don't yet understand how to use the powers it already has.
>>>>>>>>>
>>>>>>>>> -Original Message-
>>>>>>>>> From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com]
>>>>>>>>> Sent: Tuesday, November 09, 2010 9:23 AM
>>>>>>>>> To: users@wicket.apache.org
>>>>>>>>> Subject: Re: Free wicket from component hierarchy hell
>>>>>>>>>
>>>>>>>>>> So instead of asking, "How can we make Wicket different so that my
>>>>>>>>>> problem will go away?" the proper question to try first is, "What is
>>>>>>>>> the
>>>>>>>>>> Wicket way of solving my problem?"
>>>>>>>>>
>>>>>>>>> That's not how proggress is made...
>>>>>>>>>
>>>>>>>>> **
>>>>>>>>> Martin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -
>>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> -
>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> -
>>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> -
>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> -
>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 12:03 PM, Sven Meier wrote: > Hi, > >> an easy example is: >> >> > wicket:id="last"/> >> >> now the designer wants tds to have a css class based on some >> condition. you now have to add a webmarkupcontainer to represent the >> td and renest first and last labels into it. the container is there >> purely for the design aspect. > > I have to change some Java code anyway, so why should I queue anything rather > than add() the components into the correct hierarchy right away? the difficult part is that doing this to complex pages is...difficult. in the example above it is easy to see the two components that need to be renested. but, in complex pages there can be 20 components that need to be renested, and they are probably initially added from a bunch of helper methods that attempted to keep the code clean. so, it may be difficult to find all 20 componets. queuing can make maintenance and refactoring of pages easier. > >> another usecase is introducing an arbitrary webmarkupcontainer just to >> have a div to repaint via ajax. it is hard to do this when refactoring >> a complex page because you have to find all the components that now >> need to be re-nested into the new container. > > Is this a common example? Did anyone ever have to "just repaint a div via > ajax" without having to change much more Java code? What's complex about this > page thus it's difficult to re-parent some of its components? yes, ive had to do it plenty times. ive had to go into pages that were already written and ajaxify them. sometimes a table needs to be updated via ajax, it needs to be wrapped in a container. other times a set of related form fields needs to be updated, its easier to wrap them in a container and update it rather then having to add them one by one from multiple places. > IMHO valid use cases have not been provided yet. we can agree to disagree -igor > > My 2 cents > > Sven > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
Hi, > an easy example is: > > wicket:id="last"/> > > now the designer wants tds to have a css class based on some > condition. you now have to add a webmarkupcontainer to represent the > td and renest first and last labels into it. the container is there > purely for the design aspect. I have to change some Java code anyway, so why should I queue anything rather than add() the components into the correct hierarchy right away? > another usecase is introducing an arbitrary webmarkupcontainer just to > have a div to repaint via ajax. it is hard to do this when refactoring > a complex page because you have to find all the components that now > need to be re-nested into the new container. Is this a common example? Did anyone ever have to "just repaint a div via ajax" without having to change much more Java code? What's complex about this page thus it's difficult to re-parent some of its components? IMHO valid use cases have not been provided yet. My 2 cents Sven - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
if the label is not visible:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> this solution you just can throw everything in the panel or webpage
> >>>>> that is the IComponentResolver for all its childs...
> >>>>> Just look at how the code works..
> >>>>> IF a component can't be found on its own parent the ComponentResolver
> >>>>> will ask all the parents which can be IComponentResolver to render
> the
> >>>>> child..
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Tue, Nov 9, 2010 at 19:04, Martin Makundi
> >>>>> wrote:
> >>>>>> This does not really nest the components logically, does it?
> >>>>>>
> >>>>>> If you set get("body").setVisible(false) will the label remain
> visible?
> >>>>>>
> >>>>>> **
> >>>>>> Martin
> >>>>>>
> >>>>>> 2010/11/9 Johan Compagner :
> >>>>>>> Why are we discussing here already that works in wicket 1.4 if you
> >>>>>>> really need it?
> >>>>>>>
> >>>>>>>
> >>>>>>> public class HelloWorld extends WebPage implements
> IComponentResolver {
> >>>>>>>
> >>>>>>>public HelloWorld()
> >>>>>>>{
> >>>>>>>add(new WebMarkupContainer("body"));
> >>>>>>>add(new Label("label","my label"));
> >>>>>>>}
> >>>>>>>
> >>>>>>>public boolean resolve(MarkupContainer container,
> >>>>>>>MarkupStream markupStream, ComponentTag tag)
> {
> >>>>>>>
> >>>>>>>Component component = get(tag.getId());
> >>>>>>>if (component != null)
> >>>>>>>{
> >>>>>>>component.render(markupStream);
> >>>>>>>return true;
> >>>>>>>}
> >>>>>>>return false;
> >>>>>>>}
> >>>>>>> }
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Tue, Nov 9, 2010 at 16:29, Frank Silbermann
> >>>>>>> wrote:
> >>>>>>>> Progress is made by people who have understanding, not by the
> ignorant.
> >>>>>>>> You're not in a position to make suggestions about extending
> Wicket if
> >>>>>>>> you don't yet understand how to use the powers it already has.
> >>>>>>>>
> >>>>>>>> -Original Message-
> >>>>>>>> From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com]
> >>>>>>>> Sent: Tuesday, November 09, 2010 9:23 AM
> >>>>>>>> To: users@wicket.apache.org
> >>>>>>>> Subject: Re: Free wicket from component hierarchy hell
> >>>>>>>>
> >>>>>>>>> So instead of asking, "How can we make Wicket different so that
> my
> >>>>>>>>> problem will go away?" the proper question to try first is, "What
> is
> >>>>>>>> the
> >>>>>>>>> Wicket way of solving my problem?"
> >>>>>>>>
> >>>>>>>> That's not how proggress is made...
> >>>>>>>>
> >>>>>>>> **
> >>>>>>>> Martin
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> -
> >>>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> -
> >>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> -
> >>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> -
> >>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>>>> For additional commands, e-mail: users-h...@wicket.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>> -
> >>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>>> For additional commands, e-mail: users-h...@wicket.apache.org
> >>>>
> >>>>
> >>>
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> For additional commands, e-mail: users-h...@wicket.apache.org
> >>
> >>
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
Re: Free wicket from component hierarchy hell
and that is only because i cant do
component.setAuto(false)
right after i call autoAdd()
else it would just stay there :)
and this is then only done to resolve it once with the first render...
On Tue, Nov 9, 2010 at 20:03, Igor Vaynberg wrote:
> it still wont work for a lot of usecases that require proper
> hierarchy. like a form trying to find form submitting component, etc
>
> -igor
>
> On Tue, Nov 9, 2010 at 10:59 AM, Johan Compagner wrote:
>> ok a sample that it also works in with the right parent:
>>
>> public class HelloWorld extends WebPage implements IComponentResolver {
>>
>> final Label label;
>> public HelloWorld()
>> {
>> label = new Label("label", new Model()
>> {
>> �...@override
>> public String getObject() {
>> return "my label: " +
>> label.isEnabledInHierarchy();
>> }
>> });
>> add(new WebMarkupContainer("body").setEnabled(false));
>> add(label);
>> }
>>
>> public boolean resolve(MarkupContainer container,
>> MarkupStream markupStream, ComponentTag tag) {
>>
>> Component component = get(tag.getId());
>> if (component != null)
>> {
>> container.autoAdd(component, markupStream);
>> return true;
>> }
>> return false;
>> }
>> }
>>
>>
>> you will see that it is disabled...
>>
>>
>> On Tue, Nov 9, 2010 at 19:37, Johan Compagner wrote:
>>> textfield.isEnabledInHierachy() will then ofcourse not get to the
>>> parent it is on.
>>> because its parent is the webpage not the body markupcontainer.
>>>
>>> So no this will not resolver from the child to the parent, only the
>>> parent to the child.
>>>
>>>
>>> On Tue, Nov 9, 2010 at 19:30, Martin Makundi
>>> wrote:
>>>> How will it work if I call get("body").setEnabled(false); and if label
>>>> was a textfield? Would the textfield be still enabled?
>>>>
>>>> **
>>>> Martin
>>>>
>>>> 2010/11/9 Johan Compagner :
>>>>> no ofcourse not
>>>>> The label will then be gone because the body is gone.
>>>>> so the output will be this
>>>>>
>>>>>
>>>>>
>>>>> when the body container is not visible
>>>>>
>>>>> if the label is not visible:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> this solution you just can throw everything in the panel or webpage
>>>>> that is the IComponentResolver for all its childs...
>>>>> Just look at how the code works..
>>>>> IF a component can't be found on its own parent the ComponentResolver
>>>>> will ask all the parents which can be IComponentResolver to render the
>>>>> child..
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Nov 9, 2010 at 19:04, Martin Makundi
>>>>> wrote:
>>>>>> This does not really nest the components logically, does it?
>>>>>>
>>>>>> If you set get("body").setVisible(false) will the label remain visible?
>>>>>>
>>>>>> **
>>>>>> Martin
>>>>>>
>>>>>> 2010/11/9 Johan Compagner :
>>>>>>> Why are we discussing here already that works in wicket 1.4 if you
>>>>>>> really need it?
>>>>>>>
>>>>>>>
>>>>>>> public class HelloWorld extends WebPage implements IComponentResolver {
>>>>>>>
>>>>>>> public HelloWorld()
>>>>>>> {
>>>>>>> add(new WebMarkupContainer("body"));
>>>>>>> add(new Label("label","my label"));
>>>>>>> }
>>>>>>>
>>>>>>> public boolean resolve(MarkupContainer container,
>>>>>
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 12:20 AM, Martin Makundi wrote: >> I frankly don't see any way to have this "auto-hierarchy" stuff >> without getting lots of unnecessary ambiguity and sources of bugs. I >> totally agree with what Eelco wrote below, and what someone else said >> about the Python way of having only *one* way to do *one* thing. > > Would you be happy if there was an application level configuration switch: > > getMarkupSettings().setAllowComponentAutoHierarchy(true); like i said, there will be no such switch if this feature moves forward. -igor > > Which is default false? > > This way you can make sure nobody in YOUR project messes things up? > > ** > Martin > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
it still wont work for a lot of usecases that require proper
hierarchy. like a form trying to find form submitting component, etc
-igor
On Tue, Nov 9, 2010 at 10:59 AM, Johan Compagner wrote:
> ok a sample that it also works in with the right parent:
>
> public class HelloWorld extends WebPage implements IComponentResolver {
>
> final Label label;
> public HelloWorld()
> {
> label = new Label("label", new Model()
> {
> �...@override
> public String getObject() {
> return "my label: " +
> label.isEnabledInHierarchy();
> }
> });
> add(new WebMarkupContainer("body").setEnabled(false));
> add(label);
> }
>
> public boolean resolve(MarkupContainer container,
> MarkupStream markupStream, ComponentTag tag) {
>
> Component component = get(tag.getId());
> if (component != null)
> {
> container.autoAdd(component, markupStream);
> return true;
> }
> return false;
> }
> }
>
>
> you will see that it is disabled...
>
>
> On Tue, Nov 9, 2010 at 19:37, Johan Compagner wrote:
>> textfield.isEnabledInHierachy() will then ofcourse not get to the
>> parent it is on.
>> because its parent is the webpage not the body markupcontainer.
>>
>> So no this will not resolver from the child to the parent, only the
>> parent to the child.
>>
>>
>> On Tue, Nov 9, 2010 at 19:30, Martin Makundi
>> wrote:
>>> How will it work if I call get("body").setEnabled(false); and if label
>>> was a textfield? Would the textfield be still enabled?
>>>
>>> **
>>> Martin
>>>
>>> 2010/11/9 Johan Compagner :
>>>> no ofcourse not
>>>> The label will then be gone because the body is gone.
>>>> so the output will be this
>>>>
>>>>
>>>>
>>>> when the body container is not visible
>>>>
>>>> if the label is not visible:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> this solution you just can throw everything in the panel or webpage
>>>> that is the IComponentResolver for all its childs...
>>>> Just look at how the code works..
>>>> IF a component can't be found on its own parent the ComponentResolver
>>>> will ask all the parents which can be IComponentResolver to render the
>>>> child..
>>>>
>>>>
>>>>
>>>> On Tue, Nov 9, 2010 at 19:04, Martin Makundi
>>>> wrote:
>>>>> This does not really nest the components logically, does it?
>>>>>
>>>>> If you set get("body").setVisible(false) will the label remain visible?
>>>>>
>>>>> **
>>>>> Martin
>>>>>
>>>>> 2010/11/9 Johan Compagner :
>>>>>> Why are we discussing here already that works in wicket 1.4 if you
>>>>>> really need it?
>>>>>>
>>>>>>
>>>>>> public class HelloWorld extends WebPage implements IComponentResolver {
>>>>>>
>>>>>> public HelloWorld()
>>>>>> {
>>>>>> add(new WebMarkupContainer("body"));
>>>>>> add(new Label("label","my label"));
>>>>>> }
>>>>>>
>>>>>> public boolean resolve(MarkupContainer container,
>>>>>> MarkupStream markupStream, ComponentTag tag) {
>>>>>>
>>>>>> Component component = get(tag.getId());
>>>>>> if (component != null)
>>>>>> {
>>>>>> component.render(markupStream);
>>>>>> return true;
>>>>>> }
>>>>>> return false;
>>>>>> }
>>>>>> }
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>&
Re: Free wicket from component hierarchy hell
ok a sample that it also works in with the right parent:
public class HelloWorld extends WebPage implements IComponentResolver {
final Label label;
public HelloWorld()
{
label = new Label("label", new Model()
{
@Override
public String getObject() {
return "my label: " +
label.isEnabledInHierarchy();
}
});
add(new WebMarkupContainer("body").setEnabled(false));
add(label);
}
public boolean resolve(MarkupContainer container,
MarkupStream markupStream, ComponentTag tag) {
Component component = get(tag.getId());
if (component != null)
{
container.autoAdd(component, markupStream);
return true;
}
return false;
}
}
you will see that it is disabled...
On Tue, Nov 9, 2010 at 19:37, Johan Compagner wrote:
> textfield.isEnabledInHierachy() will then ofcourse not get to the
> parent it is on.
> because its parent is the webpage not the body markupcontainer.
>
> So no this will not resolver from the child to the parent, only the
> parent to the child.
>
>
> On Tue, Nov 9, 2010 at 19:30, Martin Makundi
> wrote:
>> How will it work if I call get("body").setEnabled(false); and if label
>> was a textfield? Would the textfield be still enabled?
>>
>> **
>> Martin
>>
>> 2010/11/9 Johan Compagner :
>>> no ofcourse not
>>> The label will then be gone because the body is gone.
>>> so the output will be this
>>>
>>>
>>>
>>> when the body container is not visible
>>>
>>> if the label is not visible:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> this solution you just can throw everything in the panel or webpage
>>> that is the IComponentResolver for all its childs...
>>> Just look at how the code works..
>>> IF a component can't be found on its own parent the ComponentResolver
>>> will ask all the parents which can be IComponentResolver to render the
>>> child..
>>>
>>>
>>>
>>> On Tue, Nov 9, 2010 at 19:04, Martin Makundi
>>> wrote:
>>>> This does not really nest the components logically, does it?
>>>>
>>>> If you set get("body").setVisible(false) will the label remain visible?
>>>>
>>>> **
>>>> Martin
>>>>
>>>> 2010/11/9 Johan Compagner :
>>>>> Why are we discussing here already that works in wicket 1.4 if you
>>>>> really need it?
>>>>>
>>>>>
>>>>> public class HelloWorld extends WebPage implements IComponentResolver {
>>>>>
>>>>> public HelloWorld()
>>>>> {
>>>>> add(new WebMarkupContainer("body"));
>>>>> add(new Label("label","my label"));
>>>>> }
>>>>>
>>>>> public boolean resolve(MarkupContainer container,
>>>>> MarkupStream markupStream, ComponentTag tag) {
>>>>>
>>>>> Component component = get(tag.getId());
>>>>> if (component != null)
>>>>> {
>>>>> component.render(markupStream);
>>>>> return true;
>>>>> }
>>>>> return false;
>>>>> }
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Nov 9, 2010 at 16:29, Frank Silbermann
>>>>> wrote:
>>>>>> Progress is made by people who have understanding, not by the ignorant.
>>>>>> You're not in a position to make suggestions about extending Wicket if
>>>>>> you don't yet understand how to use the powers it already has.
>>>>>>
>>>>>> -Original Message-
>>>>>> From: Martin Makundi [mailto:martin.maku...@koodarip
Re: Free wicket from component hierarchy hell
Ok, I think one the main point in Igor's proposal was to overcome this
particular problem in addition to few others:
https://github.com/ivaynberg/wicket/tree/component-queuing
**
Martin
2010/11/9 Johan Compagner :
> textfield.isEnabledInHierachy() will then ofcourse not get to the
> parent it is on.
> because its parent is the webpage not the body markupcontainer.
>
> So no this will not resolver from the child to the parent, only the
> parent to the child.
>
>
> On Tue, Nov 9, 2010 at 19:30, Martin Makundi
> wrote:
>> How will it work if I call get("body").setEnabled(false); and if label
>> was a textfield? Would the textfield be still enabled?
>>
>> **
>> Martin
>>
>> 2010/11/9 Johan Compagner :
>>> no ofcourse not
>>> The label will then be gone because the body is gone.
>>> so the output will be this
>>>
>>>
>>>
>>> when the body container is not visible
>>>
>>> if the label is not visible:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> this solution you just can throw everything in the panel or webpage
>>> that is the IComponentResolver for all its childs...
>>> Just look at how the code works..
>>> IF a component can't be found on its own parent the ComponentResolver
>>> will ask all the parents which can be IComponentResolver to render the
>>> child..
>>>
>>>
>>>
>>> On Tue, Nov 9, 2010 at 19:04, Martin Makundi
>>> wrote:
>>>> This does not really nest the components logically, does it?
>>>>
>>>> If you set get("body").setVisible(false) will the label remain visible?
>>>>
>>>> **
>>>> Martin
>>>>
>>>> 2010/11/9 Johan Compagner :
>>>>> Why are we discussing here already that works in wicket 1.4 if you
>>>>> really need it?
>>>>>
>>>>>
>>>>> public class HelloWorld extends WebPage implements IComponentResolver {
>>>>>
>>>>> public HelloWorld()
>>>>> {
>>>>> add(new WebMarkupContainer("body"));
>>>>> add(new Label("label","my label"));
>>>>> }
>>>>>
>>>>> public boolean resolve(MarkupContainer container,
>>>>> MarkupStream markupStream, ComponentTag tag) {
>>>>>
>>>>> Component component = get(tag.getId());
>>>>> if (component != null)
>>>>> {
>>>>> component.render(markupStream);
>>>>> return true;
>>>>> }
>>>>> return false;
>>>>> }
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Nov 9, 2010 at 16:29, Frank Silbermann
>>>>> wrote:
>>>>>> Progress is made by people who have understanding, not by the ignorant.
>>>>>> You're not in a position to make suggestions about extending Wicket if
>>>>>> you don't yet understand how to use the powers it already has.
>>>>>>
>>>>>> -Original Message-
>>>>>> From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com]
>>>>>> Sent: Tuesday, November 09, 2010 9:23 AM
>>>>>> To: users@wicket.apache.org
>>>>>> Subject: Re: Free wicket from component hierarchy hell
>>>>>>
>>>>>>> So instead of asking, "How can we make Wicket different so that my
>>>>>>> problem will go away?" the proper question to try first is, "What is
>>>>>> the
>>>>>>> Wicket way of solving my problem?"
>>>>>>
>>>>>> That's not how proggress is made...
>>>>>>
>>>>>> **
>>>>>> Martin
>>>>>>
>>>>>>
>>>>>>
>>>>>> -
>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> -
>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>> -
>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>
>>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 9:38 AM, Martin Makundi wrote: >> The user can queue stuff to the wrong component unknowingly because >> they won't get an exception. > > You will get an exception if you queue explicitly to the wrong > component. If you don't care about the parent component, it 's their > choie (good or bad) ;) > >> Then later a markup change could completely change what's >> going on behind the scenes, not just the look. > > If in doubt, there is always > getMarkupSettings().setAllowComponentAutoHierarchy(false); there will be no such method. -igor > > ** > Martin > >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
the queue() method is there in addition to add(), so you dont have to use it. yes, it is riskier to use under some circumstances because it is more forgiving then add() - but thats the point i think. -igor On Tue, Nov 9, 2010 at 9:41 AM, James Carman wrote: > On Tue, Nov 9, 2010 at 12:38 PM, Martin Makundi > wrote: >> >> You will get an exception if you queue explicitly to the wrong >> component. If you don't care about the parent component, it 's their >> choie (good or bad) ;) >> > > You're not understanding what I'm saying. I'm saying they're not > consciously making a *choice*; they're queueing the component to the > wrong parent on accident, but they aren't getting an exception. This > can lead to problems later on. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
textfield.isEnabledInHierachy() will then ofcourse not get to the
parent it is on.
because its parent is the webpage not the body markupcontainer.
So no this will not resolver from the child to the parent, only the
parent to the child.
On Tue, Nov 9, 2010 at 19:30, Martin Makundi
wrote:
> How will it work if I call get("body").setEnabled(false); and if label
> was a textfield? Would the textfield be still enabled?
>
> **
> Martin
>
> 2010/11/9 Johan Compagner :
>> no ofcourse not
>> The label will then be gone because the body is gone.
>> so the output will be this
>>
>>
>>
>> when the body container is not visible
>>
>> if the label is not visible:
>>
>>
>>
>>
>>
>>
>>
>> this solution you just can throw everything in the panel or webpage
>> that is the IComponentResolver for all its childs...
>> Just look at how the code works..
>> IF a component can't be found on its own parent the ComponentResolver
>> will ask all the parents which can be IComponentResolver to render the
>> child..
>>
>>
>>
>> On Tue, Nov 9, 2010 at 19:04, Martin Makundi
>> wrote:
>>> This does not really nest the components logically, does it?
>>>
>>> If you set get("body").setVisible(false) will the label remain visible?
>>>
>>> **
>>> Martin
>>>
>>> 2010/11/9 Johan Compagner :
>>>> Why are we discussing here already that works in wicket 1.4 if you
>>>> really need it?
>>>>
>>>>
>>>> public class HelloWorld extends WebPage implements IComponentResolver {
>>>>
>>>> public HelloWorld()
>>>> {
>>>> add(new WebMarkupContainer("body"));
>>>> add(new Label("label","my label"));
>>>> }
>>>>
>>>> public boolean resolve(MarkupContainer container,
>>>> MarkupStream markupStream, ComponentTag tag) {
>>>>
>>>> Component component = get(tag.getId());
>>>> if (component != null)
>>>> {
>>>> component.render(markupStream);
>>>> return true;
>>>> }
>>>> return false;
>>>> }
>>>> }
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Nov 9, 2010 at 16:29, Frank Silbermann
>>>> wrote:
>>>>> Progress is made by people who have understanding, not by the ignorant.
>>>>> You're not in a position to make suggestions about extending Wicket if
>>>>> you don't yet understand how to use the powers it already has.
>>>>>
>>>>> -Original Message-
>>>>> From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com]
>>>>> Sent: Tuesday, November 09, 2010 9:23 AM
>>>>> To: users@wicket.apache.org
>>>>> Subject: Re: Free wicket from component hierarchy hell
>>>>>
>>>>>> So instead of asking, "How can we make Wicket different so that my
>>>>>> problem will go away?" the proper question to try first is, "What is
>>>>> the
>>>>>> Wicket way of solving my problem?"
>>>>>
>>>>> That's not how proggress is made...
>>>>>
>>>>> **
>>>>> Martin
>>>>>
>>>>>
>>>>>
>>>>> -
>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>> -
>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>
>>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
How will it work if I call get("body").setEnabled(false); and if label
was a textfield? Would the textfield be still enabled?
**
Martin
2010/11/9 Johan Compagner :
> no ofcourse not
> The label will then be gone because the body is gone.
> so the output will be this
>
>
>
> when the body container is not visible
>
> if the label is not visible:
>
>
>
>
>
>
>
> this solution you just can throw everything in the panel or webpage
> that is the IComponentResolver for all its childs...
> Just look at how the code works..
> IF a component can't be found on its own parent the ComponentResolver
> will ask all the parents which can be IComponentResolver to render the
> child..
>
>
>
> On Tue, Nov 9, 2010 at 19:04, Martin Makundi
> wrote:
>> This does not really nest the components logically, does it?
>>
>> If you set get("body").setVisible(false) will the label remain visible?
>>
>> **
>> Martin
>>
>> 2010/11/9 Johan Compagner :
>>> Why are we discussing here already that works in wicket 1.4 if you
>>> really need it?
>>>
>>>
>>> public class HelloWorld extends WebPage implements IComponentResolver {
>>>
>>> public HelloWorld()
>>> {
>>> add(new WebMarkupContainer("body"));
>>> add(new Label("label","my label"));
>>> }
>>>
>>> public boolean resolve(MarkupContainer container,
>>> MarkupStream markupStream, ComponentTag tag) {
>>>
>>> Component component = get(tag.getId());
>>> if (component != null)
>>> {
>>> component.render(markupStream);
>>> return true;
>>> }
>>> return false;
>>> }
>>> }
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Nov 9, 2010 at 16:29, Frank Silbermann
>>> wrote:
>>>> Progress is made by people who have understanding, not by the ignorant.
>>>> You're not in a position to make suggestions about extending Wicket if
>>>> you don't yet understand how to use the powers it already has.
>>>>
>>>> -Original Message-
>>>> From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com]
>>>> Sent: Tuesday, November 09, 2010 9:23 AM
>>>> To: users@wicket.apache.org
>>>> Subject: Re: Free wicket from component hierarchy hell
>>>>
>>>>> So instead of asking, "How can we make Wicket different so that my
>>>>> problem will go away?" the proper question to try first is, "What is
>>>> the
>>>>> Wicket way of solving my problem?"
>>>>
>>>> That's not how proggress is made...
>>>>
>>>> **
>>>> Martin
>>>>
>>>>
>>>>
>>>> -
>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>>
>>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
no ofcourse not
The label will then be gone because the body is gone.
so the output will be this
when the body container is not visible
if the label is not visible:
this solution you just can throw everything in the panel or webpage
that is the IComponentResolver for all its childs...
Just look at how the code works..
IF a component can't be found on its own parent the ComponentResolver
will ask all the parents which can be IComponentResolver to render the
child..
On Tue, Nov 9, 2010 at 19:04, Martin Makundi
wrote:
> This does not really nest the components logically, does it?
>
> If you set get("body").setVisible(false) will the label remain visible?
>
> **
> Martin
>
> 2010/11/9 Johan Compagner :
>> Why are we discussing here already that works in wicket 1.4 if you
>> really need it?
>>
>>
>> public class HelloWorld extends WebPage implements IComponentResolver {
>>
>> public HelloWorld()
>> {
>> add(new WebMarkupContainer("body"));
>> add(new Label("label","my label"));
>> }
>>
>> public boolean resolve(MarkupContainer container,
>> MarkupStream markupStream, ComponentTag tag) {
>>
>> Component component = get(tag.getId());
>> if (component != null)
>> {
>> component.render(markupStream);
>> return true;
>> }
>> return false;
>> }
>> }
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Nov 9, 2010 at 16:29, Frank Silbermann
>> wrote:
>>> Progress is made by people who have understanding, not by the ignorant.
>>> You're not in a position to make suggestions about extending Wicket if
>>> you don't yet understand how to use the powers it already has.
>>>
>>> -Original Message-
>>> From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com]
>>> Sent: Tuesday, November 09, 2010 9:23 AM
>>> To: users@wicket.apache.org
>>> Subject: Re: Free wicket from component hierarchy hell
>>>
>>>> So instead of asking, "How can we make Wicket different so that my
>>>> problem will go away?" the proper question to try first is, "What is
>>> the
>>>> Wicket way of solving my problem?"
>>>
>>> That's not how proggress is made...
>>>
>>> **
>>> Martin
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
This does not really nest the components logically, does it?
If you set get("body").setVisible(false) will the label remain visible?
**
Martin
2010/11/9 Johan Compagner :
> Why are we discussing here already that works in wicket 1.4 if you
> really need it?
>
>
> public class HelloWorld extends WebPage implements IComponentResolver {
>
> public HelloWorld()
> {
> add(new WebMarkupContainer("body"));
> add(new Label("label","my label"));
> }
>
> public boolean resolve(MarkupContainer container,
> MarkupStream markupStream, ComponentTag tag) {
>
> Component component = get(tag.getId());
> if (component != null)
> {
> component.render(markupStream);
> return true;
> }
> return false;
> }
> }
>
>
>
>
>
>
>
>
>
> On Tue, Nov 9, 2010 at 16:29, Frank Silbermann
> wrote:
>> Progress is made by people who have understanding, not by the ignorant.
>> You're not in a position to make suggestions about extending Wicket if
>> you don't yet understand how to use the powers it already has.
>>
>> -Original Message-
>> From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com]
>> Sent: Tuesday, November 09, 2010 9:23 AM
>> To: users@wicket.apache.org
>> Subject: Re: Free wicket from component hierarchy hell
>>
>>> So instead of asking, "How can we make Wicket different so that my
>>> problem will go away?" the proper question to try first is, "What is
>> the
>>> Wicket way of solving my problem?"
>>
>> That's not how proggress is made...
>>
>> **
>> Martin
>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
Why are we discussing here already that works in wicket 1.4 if you
really need it?
public class HelloWorld extends WebPage implements IComponentResolver {
public HelloWorld()
{
add(new WebMarkupContainer("body"));
add(new Label("label","my label"));
}
public boolean resolve(MarkupContainer container,
MarkupStream markupStream, ComponentTag tag) {
Component component = get(tag.getId());
if (component != null)
{
component.render(markupStream);
return true;
}
return false;
}
}
On Tue, Nov 9, 2010 at 16:29, Frank Silbermann
wrote:
> Progress is made by people who have understanding, not by the ignorant.
> You're not in a position to make suggestions about extending Wicket if
> you don't yet understand how to use the powers it already has.
>
> -Original Message-
> From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com]
> Sent: Tuesday, November 09, 2010 9:23 AM
> To: users@wicket.apache.org
> Subject: Re: Free wicket from component hierarchy hell
>
>> So instead of asking, "How can we make Wicket different so that my
>> problem will go away?" the proper question to try first is, "What is
> the
>> Wicket way of solving my problem?"
>
> That's not how proggress is made...
>
> **
> Martin
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
>> Very good point: cleaner code! Finally complex wicket pages will look >> like their hello-world counterparts. > > You're becoming a bit irrational here, Martin. Let's try to stay on > point. He brings up a valid point and we should respect his opinion, > much like we're respecting yours. Remember, you are in the minority > in this conversation thus far. Let's keep the gloves up. James, I totally agree with Sebastian. I really think that now with this change also complex wicket pages can look like hamburgers on menu ;) >> So you mean that if a manufacturer manufactures a gun they are not >> conciously making the decision that somebody is getting shot? >> > > This has nothing to do with what we're talking about. Nor does it in > any way parallel what I'm saying. I just think that is a bit far-fetched that we should not manufacture features into wicket that can be used to make a mess. It's responsibility of the eventual developing team to keep it clean or use more strict add() method to keep it safe. ** Martin > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 12:43 PM, Martin Makundi wrote: > > So you mean that if a manufacturer manufactures a gun they are not > conciously making the decision that somebody is getting shot? > Ok, I'm officially done with this conversation. I've voiced my opinion. You apparently aren't open to a rational debate. This has nothing to do with what we're talking about. Nor does it in any way parallel what I'm saying. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
> You're not understanding what I'm saying. I'm saying they're not > consciously making a *choice*; they're queueing the component to the > wrong parent on accident, but they aren't getting an exception. This > can lead to problems later on. So you mean that if a manufacturer manufactures a gun they are not conciously making the decision that somebody is getting shot? ** Martin > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 12:38 PM, Martin Makundi wrote: > > You will get an exception if you queue explicitly to the wrong > component. If you don't care about the parent component, it 's their > choie (good or bad) ;) > You're not understanding what I'm saying. I'm saying they're not consciously making a *choice*; they're queueing the component to the wrong parent on accident, but they aren't getting an exception. This can lead to problems later on. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
> The user can queue stuff to the wrong component unknowingly because > they won't get an exception. You will get an exception if you queue explicitly to the wrong component. If you don't care about the parent component, it 's their choie (good or bad) ;) > Then later a markup change could completely change what's > going on behind the scenes, not just the look. If in doubt, there is always getMarkupSettings().setAllowComponentAutoHierarchy(false); ** Martin > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 12:33 PM, Martin Makundi wrote: > Very good point: cleaner code! Finally complex wicket pages will look > like their hello-world counterparts. > You're becoming a bit irrational here, Martin. Let's try to stay on point. He brings up a valid point and we should respect his opinion, much like we're respecting yours. Remember, you are in the minority in this conversation thus far. Let's keep the gloves up. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 12:29 PM, Martin Makundi wrote: > > I wouldn't call it unknowingly if you are stating it now before the > feature has been implemented. > The user can queue stuff to the wrong component unknowingly because they won't get an exception. Then later a markup change could completely change what's going on behind the scenes, not just the look. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
> On the other hand if you only have to do component nesting programmatically > in case of functional reasons (like security) your code will probably much > cleaner and you'll realize issues like using the wrong parent faster. +1 Very good point: cleaner code! Finally complex wicket pages will look like their hello-world counterparts. ** Martin > > Instead of: > myComponent.add(child1) > child1.add(child2) > child2.add(child3) > child2.add(child4) > myComponent.setVisible(false / true) > > You do: > myComponent.add(child1) > myComponent.add(child2) > myComponent.add(child3) // correct direct parent determined by markup > myComponent.add(child4) // correct direct parent determined by markup > myComponent.setVisible(false / true) > > On 09.11.2010 18:17, James Carman wrote: >> >> On Tue, Nov 9, 2010 at 12:06 PM, Martin Makundi >> wrote: >>> >>> (You) as a coder will be responsible for opening that can ;] For good >>> and for bad. Not wicket. Nor members of this discussion. >>> >> >> How many times have you done this: >> >> add(new TextField(...)) >> >> when you meant to do: >> >> someSubComponent.add(new TextField(..)) >> >> With add, you'll get an exception if the ids/hierarchy don't match up. >> Now, what if you're queueing instead? Suppose the user does: >> >> queue(new TextField(...)) >> >> which will work perfectly fine, but they meant to do (to enforce >> "security"): >> >> someSubComponent.queue(new TextField(...)) >> >> Now, since security is not enforced the "designer" has the freedom to >> move stuff around and royally hose things up. >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On the other hand if you only have to do component nesting programmatically in case of functional reasons (like security) your code will probably much cleaner and you'll realize issues like using the wrong parent faster. Instead of: myComponent.add(child1) child1.add(child2) child2.add(child3) child2.add(child4) myComponent.setVisible(false / true) You do: myComponent.add(child1) myComponent.add(child2) myComponent.add(child3) // correct direct parent determined by markup myComponent.add(child4) // correct direct parent determined by markup myComponent.setVisible(false / true) On 09.11.2010 18:17, James Carman wrote: On Tue, Nov 9, 2010 at 12:06 PM, Martin Makundi wrote: (You) as a coder will be responsible for opening that can ;] For good and for bad. Not wicket. Nor members of this discussion. How many times have you done this: add(new TextField(...)) when you meant to do: someSubComponent.add(new TextField(..)) With add, you'll get an exception if the ids/hierarchy don't match up. Now, what if you're queueing instead? Suppose the user does: queue(new TextField(...)) which will work perfectly fine, but they meant to do (to enforce "security"): someSubComponent.queue(new TextField(...)) Now, since security is not enforced the "designer" has the freedom to move stuff around and royally hose things up. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
> Again, the point is (regardless of unit tests) that you can > unknowingly do something that allows stuff to break later quite > easily. I wouldn't call it unknowingly if you are stating it now before the feature has been implemented. ** Martin > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 12:22 PM, Martin Makundi wrote: > > Yes, if you are unsure, you should use add() to make sure. You get > that extra security with that extra effort, if you want. > Again, the point is (regardless of unit tests) that you can unknowingly do something that allows stuff to break later quite easily. I'm just playing devil's advocate here. Allowing a markup change to modify the functionality of the "behind the scenes" code is dangerous, IMHO. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
Hi! First of all, normally I have junit tests that validate the functionality for me for regression purposes. > Suppose the user does: > > queue(new TextField(...)) > > which will work perfectly fine, but they meant to do (to enforce "security"): > > someSubComponent.queue(new TextField(...)) > > Now, since security is not enforced the "designer" has the freedom to > move stuff around and royally hose things up. Yes, if you are unsure, you should use add() to make sure. You get that extra security with that extra effort, if you want. ** Martin > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 12:06 PM, Martin Makundi wrote: > > (You) as a coder will be responsible for opening that can ;] For good > and for bad. Not wicket. Nor members of this discussion. > How many times have you done this: add(new TextField(...)) when you meant to do: someSubComponent.add(new TextField(..)) With add, you'll get an exception if the ids/hierarchy don't match up. Now, what if you're queueing instead? Suppose the user does: queue(new TextField(...)) which will work perfectly fine, but they meant to do (to enforce "security"): someSubComponent.queue(new TextField(...)) Now, since security is not enforced the "designer" has the freedom to move stuff around and royally hose things up. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
> wrote: >> >> http://apache-wicket.1842946.n4.nabble.com/forum/PrintPost.jtp?post=3034640 > > Did you mean to try to make me print this post? Hehe... I did not find antoher way to point to a single post ;] ** Martin > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 12:00 PM, Martin Makundi wrote: > > http://apache-wicket.1842946.n4.nabble.com/forum/PrintPost.jtp?post=3034640 > Did you mean to try to make me print this post? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
> The point is that this new approach can allow the "designer" to move > things around, potentially changing the semantics of how things work. > For example, a TextField may have validators set up on it that are > applicable within the context of one type of form, but may be > completely inappropriate in another form. I'm not saying I'm against > the queue approach necessarily, but I want to point out how you can > get some pretty weird stuff happening just by moving the markup > around. Do we want to open up that can of worms? (You) as a coder will be responsible for opening that can ;] For good and for bad. Not wicket. Nor members of this discussion. ** Martin > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 12:00 PM, Igor Vaynberg wrote: > yes, and that would of course be a mistake. if you just queue > everything into the page you can cause serious security problems. > > sometimes you have a "hard" container you want your components to live > under, and other times you dont care. you should always queue into the > hard container, just like you add to something under it now. > The point is that this new approach can allow the "designer" to move things around, potentially changing the semantics of how things work. For example, a TextField may have validators set up on it that are applicable within the context of one type of form, but may be completely inappropriate in another form. I'm not saying I'm against the queue approach necessarily, but I want to point out how you can get some pretty weird stuff happening just by moving the markup around. Do we want to open up that can of worms? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
> On Tue, Nov 9, 2010 at 11:55 AM, Martin Makundi > wrote: >> For security reasons in general, you might want to use: >> >> formA.queue(formAstuff); >> formB.queue(formBstuff); >> > > But then you're right back where you started. Why not just "add" and > not "queue"? http://apache-wicket.1842946.n4.nabble.com/forum/PrintPost.jtp?post=3034640 > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
yes, and that would of course be a mistake. if you just queue everything into the page you can cause serious security problems. sometimes you have a "hard" container you want your components to live under, and other times you dont care. you should always queue into the hard container, just like you add to something under it now. -igor On Tue, Nov 9, 2010 at 8:57 AM, James Carman wrote: > On Tue, Nov 9, 2010 at 11:55 AM, Igor Vaynberg > wrote: >> um. no. queued components cannot be moved out of their parent. so if >> you queued field1 under form1 and the designer moves the tag tied to >> field1 outside the tag tied to form1 you will get the same error you >> would get now. >> > > I'm not saying that. I'm saying that if you queue the fields into the > parent of form1 and form2, then you are free to move them between the > forms solely in the markup. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
ive outlined a couple of usecases when this is useful in another email. see there. -igor On Tue, Nov 9, 2010 at 8:56 AM, James Carman wrote: > On Tue, Nov 9, 2010 at 11:55 AM, Martin Makundi > wrote: >> For security reasons in general, you might want to use: >> >> formA.queue(formAstuff); >> formB.queue(formBstuff); >> > > But then you're right back where you started. Why not just "add" and > not "queue"? > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 11:50 AM, Frank Silbermann wrote: > I don't understand your example. You have two forms on one panel. You > wish to move a field (of one of the forms?) to another panel. Doesn't > that imply that you've taken the field out of the form? > Not to another panel. To the other form within the same panel. All fields are queued to the panel, not the forms. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 11:55 AM, Igor Vaynberg wrote: > um. no. queued components cannot be moved out of their parent. so if > you queued field1 under form1 and the designer moves the tag tied to > field1 outside the tag tied to form1 you will get the same error you > would get now. > I'm not saying that. I'm saying that if you queue the fields into the parent of form1 and form2, then you are free to move them between the forms solely in the markup. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 11:55 AM, Martin Makundi wrote: > For security reasons in general, you might want to use: > > formA.queue(formAstuff); > formB.queue(formBstuff); > But then you're right back where you started. Why not just "add" and not "queue"? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
um. no. queued components cannot be moved out of their parent. so if you queued field1 under form1 and the designer moves the tag tied to field1 outside the tag tied to form1 you will get the same error you would get now. -igor On Tue, Nov 9, 2010 at 8:50 AM, James Carman wrote: > On Tue, Nov 9, 2010 at 11:48 AM, Igor Vaynberg > wrote: >> so queue each formcomponet under the form they belong to. that way >> they cannot be moved outside the form. >> > > That's what happens in "code" not markup. You could potentially > change what gets edited by the form merely by moving fields around in > the markup. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
> That's what happens in "code" not markup. You could potentially > change what gets edited by the form merely by moving fields around in > the markup. With compoundpropertymodels yes if you don't restrict components inside a form this can happen. For good or for bad. For security reasons in general, you might want to use: formA.queue(formAstuff); formB.queue(formBstuff); ** Martin > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 8:10 AM, Carl-Eric Menzel wrote: > On Tue, 9 Nov 2010 10:51:49 -0500 > James Carman wrote: > >> On Tue, Nov 9, 2010 at 10:48 AM, Frank Silbermann >> wrote: >> > If the component hierarchy can be changed without changing behavior >> > or semantics, then why are the components in a hierarchy to begin >> > with? Why aren't all the components being moved around already >> > siblings at the same level? Does Wicket require that the order of >> > sibling Wicket components match the order at which simply HTML >> > elements appear? >> > >> >> You could do that, but I think Martin is trying to take it a step >> further allowing you to have an arbitrary hierarchy in your markup and >> just figure it out at runtime. Wicket doesn't care what order you add >> stuff to the page/component as long as they're all on the same level >> within the hierarchy. > > I think you misunderstood Frank's point. Why are the components in a > hierarchy in the first place, if the hierarchy can be changed without > changing behavior or semantics? They can simply be flat in the parent > then. sadly there are valid usecases for having the hierarchy purely for design purposes. an easy example is: now the designer wants tds to have a css class based on some condition. you now have to add a webmarkupcontainer to represent the td and renest first and last labels into it. the container is there purely for the design aspect. with queuing you can queue first and last under the repeater item. when you need to add css to td you simply queue the webmarkupcontainer under the repeater item as well and wicket will properly nest the labels in it for you. another usecase is introducing an arbitrary webmarkupcontainer just to have a div to repaint via ajax. it is hard to do this when refactoring a complex page because you have to find all the components that now need to be re-nested into the new container. hopefully queuing can eliminate some of this noise and make it easier. -igor > > Carl-Eric > www.wicketbuch.de > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Free wicket from component hierarchy hell
I don't understand your example. You have two forms on one panel. You wish to move a field (of one of the forms?) to another panel. Doesn't that imply that you've taken the field out of the form? -Original Message- From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On Behalf Of James Carman Sent: Tuesday, November 09, 2010 10:34 AM To: users@wicket.apache.org Subject: Re: Free wicket from component hierarchy hell On Tue, Nov 9, 2010 at 11:10 AM, Carl-Eric Menzel wrote: > > I think you misunderstood Frank's point. Why are the components in a > hierarchy in the first place, if the hierarchy can be changed without > changing behavior or semantics? They can simply be flat in the parent > then. > Say you have two forms on one panel (don't know if this is the best example or not, but here goes). You want to move a field from one panel to another. You'd have to do that in code with the traditional approach. With the "queued" approach, you'd just queue all your components to the parent container and it would auto-add them to the correct subcomponent as it finds them in the markup. With this, the order does matter, though. Suppose you had two components you wanted to queue with the same id, completely different components. If you reverse their order, then they're auto-added in a different order. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 11:48 AM, Igor Vaynberg wrote: > so queue each formcomponet under the form they belong to. that way > they cannot be moved outside the form. > That's what happens in "code" not markup. You could potentially change what gets edited by the form merely by moving fields around in the markup. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 7:36 AM, John Owen wrote: > "Do we really think this is that big of a problem that we need to change the > whole paradigm of the framework to address it?" it will not be changing the paradigm. it is adding a new method for you to add components. use it if you want, dont use it if you dont. -igor > > IMO, No. > > -Original Message- > From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On > Behalf Of James Carman > Sent: Tuesday, November 09, 2010 9:06 AM > To: users@wicket.apache.org > Subject: Re: Free wicket from component hierarchy hell > > I think we need to try to put our heads together on this one. I don't > necessarily think this approach is the best, but I haven't really had > a chance to wrap my head around it yet, frankly. Do we really think > this is that big of a problem that we need to change the whole > paradigm of the framework to address it? Perhaps you can create a new > "container" component that does all of this stuff with some pre-render > magic or something? If you want to use it, you can. If not, you > don't have to. So, if you're the type that likes this loosey goosey > stuff, you basically "wrap" your pages with one of these things to > enable this type of behavior. I don't know. This is just off the top > of my head. Still not done with my morning coffee. > > On Tue, Nov 9, 2010 at 9:58 AM, Martin Grigorov wrote: >> I think we have to make a vote whether this feature has to be investigated >> further. >> There are over 90 mails in the thread and I have the feeling that only >> Martin Makundi likes the idea. >> >> On Tue, Nov 9, 2010 at 3:46 PM, Frank Silbermann >> wrote: >> >>> Well then, why don't you have your base panel provide methods that >>> generate the individual components, with methods that implement >>> composite behaviors involving groups of components. >>> >>> Your constructor can call the component-creation methods to assemble the >>> component hierarchy to match the HTML. >>> >>> Then, when you want a panel with a different hierarchy you subclass the >>> panel, override the constructor to create the 2nd component hierarchy, >>> and provide the new panel its own HTML page. >>> >>> If you don't like overriding the constructor along with the HTML, then >>> you can build some sort of configurable constructor-constructor. >>> >>> /Frank >>> >>> -Original Message- >>> From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com] >>> Sent: Tuesday, November 09, 2010 6:55 AM >>> To: users@wicket.apache.org >>> Subject: Re: Free wicket from component hierarchy hell >>> >>> Hi! >>> >>> > Isn't this exactly the reason we've got CSS? >>> >>> It's just the buzz, not the reality. Unfortunately often CSS "doesn't >>> quite cut it: >>> * http://blog.iconara.net/2007/09/21/the-failure-of-css/ >>> >>> > HTML shouldn't really be used for look&feel and the size and placement >>> of >>> > components can perfectly be defined using CSS classes. >>> >>> In CSS the actual nesting of components plays a big role (div inside >>> float inside abs top 0px ul relative etc.). >>> >>> If you want a professional finish, you will often need to pull >>> components around the layers for different display. Even trying to >>> pull one component will break wicket in strict hierarchy mode. >>> >>> ** >>> Martin >>> >>> > >>> > Matt >>> > >>> > On 2010-11-09 13:34, Martin Makundi wrote: >>> >> >>> >> Also making skins for different devices / screen sizes becomes >>> easier. >>> >> >>> >> ** >>> >> Martin >>> >> >>> >> 2010/11/9 Vitaly Tsaplin: >>> >>>> >>> >>>> In simple cases it makes no difference. It makes real difference >>> with >>> >>>> some complex widgets (for example search components) that must be >>> >>>> reused on many pages and they should render differently on each >>> page >>> >>>> depending on how much space and what context they are in. I don't >>> like >>> >>>> duplicating code even if it is gui code. >>&g
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 11:47 AM, Carl-Eric Menzel wrote: > > Are you moving a field from one form to another? But that does change > the semantics, doesn't it? If it doesn't, why are there two forms? > Both forms "edit" one particular object (say a Person). They just edit different values on the same object. Again, I'm not sure this is the best example, but it's at least plausible. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
> PS: I think much of this controversy could have been streamlined by > pointing to a concept-complete implementation or at least making a > properly thought-out suggestion, instead of all the name-calling that > went on. (Almost) No offense taken, just a suggestion for the future. My apologies. I am quite bad at communicating my wicked ideas. However, the well thought suggestions from the wicketeers were necessary to get the solution growing. The solution and also the concept was invented collaboratively during the thread. For that I am very thankful ;) ** Martin > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
so queue each formcomponet under the form they belong to. that way
they cannot be moved outside the form.
-igor
On Tue, Nov 9, 2010 at 8:46 AM, James Carman wrote:
> On Tue, Nov 9, 2010 at 11:40 AM, Martin Makundi
> wrote:
>>
>> Yeah ids must be unique per each level and ofcourse if you have markup like:
>>
>>
>>
>> If you have code like:
>> panel {
>> queue(a("a"));
>> a.queue(a("a"));
>> }
>>
>
> This could be a problem. Say you do have two forms on the same page.
> One form edits a Person and the other edits a Department. Each of
> which have a "name" field (with id "name") which are queued/auto-added
> so that the Department's name field is queued before the Person's name
> field. To begin with, in the markup, the Department form comes before
> the Person form. Now, what if the "designer" switches the order of
> the markup and puts the Person form before the Department form? Then,
> the wrong name field will be added to the wrong form. Am I
> understanding this correctly?
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, 9 Nov 2010 11:33:31 -0500 James Carman wrote: > Say you have two forms on one panel (don't know if this is the best > example or not, but here goes). You want to move a field from one > panel to another. You'd have to do that in code with the traditional > approach. With the "queued" approach, you'd just queue all your > components to the parent container and it would auto-add them to the > correct subcomponent as it finds them in the markup. Are you moving a field from one form to another? But that does change the semantics, doesn't it? If it doesn't, why are there two forms? > With this, the order does matter, though. Suppose you had two > components you wanted to queue with the same id, completely different > components. If you reverse their order, then they're auto-added in a > different order. Ouch. I think this has the potential to be a showstopper. This will be an endless source of hard-to-find bugs. I think there needs to be a unique-id requirement when you start using queue. Right now we require unique-ids on the same hierarchy level, i.e. direct descendants of the same component. With queue, we're basically extending necessity that to the whole subtree. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 11:40 AM, Martin Makundi
wrote:
>
> Yeah ids must be unique per each level and ofcourse if you have markup like:
>
>
>
> If you have code like:
> panel {
> queue(a("a"));
> a.queue(a("a"));
> }
>
This could be a problem. Say you do have two forms on the same page.
One form edits a Person and the other edits a Department. Each of
which have a "name" field (with id "name") which are queued/auto-added
so that the Department's name field is queued before the Person's name
field. To begin with, in the markup, the Department form comes before
the Person form. Now, what if the "designer" switches the order of
the markup and puts the Person form before the Department form? Then,
the wrong name field will be added to the wrong form. Am I
understanding this correctly?
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
From my understanding the proposal works like this that you have a partially code controlled hierarchy of components when you need it for functional reasons (security, AJAX refresh, visibility, etc). You can define the parent of a component but technical you allow child components being nested at will in the HTML markup (below that code controlled parent). So if you do parent.add(component) you say that the component must be either added as a direct or indirect child to this parent => if you do parent.setVisible(false) all childs will still be invisible no matter how they are nested among themselves. So you give the HTML designer a bit more freedom in layouting components below a given code controlled parent. I think that would be a reasonable approach. On 09.11.2010 17:05, Carl-Eric Menzel wrote: On Tue, 9 Nov 2010 17:46:13 +0200 Martin Makundi wrote: @Carl-Erik Reason why I haven't commented your "enabledInHierarchy" comment is because it would not afect it in any way. I hope the proposition will be clear when we have it ready. We are working on Igor's proposal. It will be interesting to see how you propose not affecting something that depends on the hierarchy when you remove the hierarchy. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
Martin, isn't it all a matter of principles towards keeping a correct separation of concerns? one of the nice things of wicket is that java-code (programmer) and html-code (designer) are quite independent. only watching a wicket-java-file does a programmer deduce the structure and behaviour of the corresponding view, both things, without fully depending on inspecting html for understanding it all, in most cases. so, would your proposal tie programmers to requiring to watch the html-code to understand structure instead of a self-contained java-code. that's what old-fashioned frameworks do... On Tue, Nov 9, 2010 at 5:08 PM, Martin Makundi < martin.maku...@koodaripalvelut.com> wrote: > >> @Carl-Erik > >> Reason why I haven't commented your "enabledInHierarchy" comment is > >> because it would not afect it in any way. > >> > >> I hope the proposition will be clear when we have it ready. We are > >> working on Igor's proposal. > > > > It will be interesting to see how you propose not affecting something > > that depends on the hierarchy when you remove the hierarchy. > > Sorry for miscommunicating.. we are not removing hierarcy. We are > trying to automatically nest the components according to the hierarchy > defined in markup. > > ** > Martin > > > > > Carl-Eric > > www.wicketbuch.de > > > > - > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Free wicket from component hierarchy hell
>> @Carl-Erik >> Reason why I haven't commented your "enabledInHierarchy" comment is >> because it would not afect it in any way. >> >> I hope the proposition will be clear when we have it ready. We are >> working on Igor's proposal. > > It will be interesting to see how you propose not affecting something > that depends on the hierarchy when you remove the hierarchy. Sorry for miscommunicating.. we are not removing hierarcy. We are trying to automatically nest the components according to the hierarchy defined in markup. ** Martin > > Carl-Eric > www.wicketbuch.de > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
>> https://github.com/ivaynberg/wicket/tree/component-queuing > > Sorry, I was thinking for some reason that the depth-first search > through the current component's hierarchy would actually traverse into > subcomponent's markup, but I don't think it will. It will stay within > the current component's markup looking for the matching id. Could > fragments screw this up, since their markup is actually contained > within the markup of their parent container? When fragments are added they materialize as natural markup at the junction point? ** Martin > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 11:10 AM, Carl-Eric Menzel wrote: > > I think you misunderstood Frank's point. Why are the components in a > hierarchy in the first place, if the hierarchy can be changed without > changing behavior or semantics? They can simply be flat in the parent > then. > Say you have two forms on one panel (don't know if this is the best example or not, but here goes). You want to move a field from one panel to another. You'd have to do that in code with the traditional approach. With the "queued" approach, you'd just queue all your components to the parent container and it would auto-add them to the correct subcomponent as it finds them in the markup. With this, the order does matter, though. Suppose you had two components you wanted to queue with the same id, completely different components. If you reverse their order, then they're auto-added in a different order. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 11:34 AM, Martin Makundi wrote: > > When fragments are added they materialize as natural markup at the > junction point? > I don't know the answer to that. I'm asking, myself. :) Just trying to make sure the queue approach doesn't break with these typical use cases. I use fragments a lot! :) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
>> What happens if a sub-component changes one of the ids of one of its >> components that it contains? Is that then going to break your page >> because it's going to "grab" that id from you? Also depends what you mean by a "component". A panel sitting on a panel has its own markup so it won't grab anything. ** Martin > > Igor explained that "# Components can be queued to any container, and > can only be added to the hierarchy that stems from that container, > thereby solving the security requirement" > > https://github.com/ivaynberg/wicket/tree/component-queuing > > ** > Martin > >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 11:04 AM, Martin Makundi wrote: > > Igor explained that "# Components can be queued to any container, and > can only be added to the hierarchy that stems from that container, > thereby solving the security requirement" > > https://github.com/ivaynberg/wicket/tree/component-queuing > Sorry, I was thinking for some reason that the depth-first search through the current component's hierarchy would actually traverse into subcomponent's markup, but I don't think it will. It will stay within the current component's markup looking for the matching id. Could fragments screw this up, since their markup is actually contained within the markup of their parent container? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
> Say you have two forms on one panel (don't know if this is the best
> example or not, but here goes). You want to move a field from one
> panel to another. You'd have to do that in code with the traditional
> approach. With the "queued" approach, you'd just queue all your
> components to the parent container and it would auto-add them to the
> correct subcomponent as it finds them in the markup.
>
> With this, the order does matter, though. Suppose you had two
> components you wanted to queue with the same id, completely different
> components. If you reverse their order, then they're auto-added in a
> different order.
Yeah ids must be unique per each level and ofcourse if you have markup like:
If you have code like:
panel {
queue(a("a"));
a.queue(a("a"));
}
It is pretty evident what goes into where but not very good naming convention ;)
**
Martin
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
