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
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
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 jer...@wickettraining.com: 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
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 jer...@wickettraining.com: 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:50 AM, Jim Pinkham pinkh...@gmail.com 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
On Thu, Jan 20, 2011 at 4:41 PM, Giannis Koutsoubos kouts...@gmail.comwrote: 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 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 jer...@wickettraining.com:
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
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 jer...@wickettraining.com:
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 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 jer...@wickettraining.com:
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
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 wicket.version1.4.9/wicket.version 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 jer...@wickettraining.com: 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 3:34 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: The largest production I am responsible for is stuck with wicket.version1.4.9/wicket.version 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
so you only have one place to fix it in -igor On Thu, Jan 20, 2011 at 1:43 PM, James Carman ja...@carmanconsulting.com wrote: On Thu, Jan 20, 2011 at 3:34 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: The largest production I am responsible for is stuck with wicket.version1.4.9/wicket.version 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
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 igor.vaynb...@gmail.com wrote: so you only have one place to fix it in -igor On Thu, Jan 20, 2011 at 1:43 PM, James Carman ja...@carmanconsulting.com wrote: On Thu, Jan 20, 2011 at 3:34 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: The largest production I am responsible for is stuck with wicket.version1.4.9/wicket.version 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
(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 igor.vaynb...@gmail.com wrote: so you only have one place to fix it in -igor On Thu, Jan 20, 2011 at 1:43 PM, James Carman ja...@carmanconsulting.com wrote: On Thu, Jan 20, 2011 at 3:34 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: The largest production I am responsible for is stuck with wicket.version1.4.9/wicket.version 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
Can we bargain about this? Say, also wicket auto ajax enclosure and both into 1.4-x? ** Martin 2011/1/18 Jeremy Thomerson jer...@wickettraining.com: 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 mgrigo...@apache.org 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
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
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 kouts...@gmail.comwrote: 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
Hi! We would like to see it in 1.4, if possible. ** Martin 2011/1/18 Martin Grigorov mgrigo...@apache.org: 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 kouts...@gmail.comwrote: 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
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 mgrigo...@apache.org: 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 kouts...@gmail.com 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
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 mgrigo...@apache.org: 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 mgrigo...@apache.org: 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 kouts...@gmail.com 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
-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 mgrigo...@apache.org 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 mgrigo...@apache.org: 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 kouts...@gmail.com 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
On Tue, Jan 18, 2011 at 10:43 AM, Martin Grigorov mgrigo...@apache.org 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
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 mgrigo...@apache.org 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
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
On Tue, 9 Nov 2010 11:49:32 -0500 James Carman ja...@carmanconsulting.com 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
On Wed, Nov 10, 2010 at 3:49 AM, Carl-Eric Menzel cmen...@wicketbuch.de 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 12:17:38 -0800 Igor Vaynberg igor.vaynb...@gmail.com 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 Tue, 9 Nov 2010 12:16:00 -0800 Igor Vaynberg igor.vaynb...@gmail.com 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 Wed, 10 Nov 2010 07:31:28 -0500 James Carman ja...@carmanconsulting.com wrote: On Wed, Nov 10, 2010 at 3:49 AM, Carl-Eric Menzel cmen...@wicketbuch.de 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
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, Nov 10, 2010 at 8:08 AM, Carl-Eric Menzel cmen...@wicketbuch.de 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
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 frank.silberm...@fedex.com 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 1:05 AM, Carl-Eric Menzel cmen...@wicketbuch.de wrote: On Tue, 9 Nov 2010 12:16:00 -0800 Igor Vaynberg igor.vaynb...@gmail.com 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
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 cmen...@wicketbuch.de wrote: On Wed, 10 Nov 2010 07:31:28 -0500 James Carman ja...@carmanconsulting.com wrote: On Wed, Nov 10, 2010 at 3:49 AM, Carl-Eric Menzel cmen...@wicketbuch.de 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
Hi, no offense meant, but the rhetoric in this thread is getting more and more ridiculous. Chicken? Component hierarchy hell? Seriously? At most maybe component hierarchy slight annoyance. I am not at all convinced that this is a good idea. In my opinion, one of the strongest and best points about Wicket is that it has a set of very clear and logical concepts and does not deviate from them. I especially like the fact that the truth is in the code and the code rules, period. Unlike Tapestry, where you could pull all kinds of stunts by using a special notation in the ID attributes of markup elements. The next thing is going to be that some developers don't want to touch the code just because the designer wants a login panel on this other page too. So why can't the designer write wicket:instantiate class=foo/? It's just another hierarchy element, isn't it? 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. The loss of predictability and clear concepts isn't worth the very slight gain in... well, gain in what? In the ability to let code and markup drift apart? To be honest, I don't even see the possible gain with this change. So far, I have often heard about people not liking the requirement to match the code hierarchy in the markup. Most (not all!) of them have never actually used Wicket (I know this doesn't apply to Martin). Not once have I seen a convincing productive(!) example of where it was an actual problem. In my current day-to-day work on a reasonably large project, this hasn't come up *at all*. Not even in our sprint retrospectives, where people are specifically asked to complain! Carl-Eric www.wicketbuch.de On Tue, 9 Nov 2010 08:41:02 +0200 Martin Makundi martin.maku...@koodaripalvelut.com wrote: Hi! Or should I say, boldly go where no man has gone before or Do, or do not. There is no 'try.' . ** Martin 2010/11/9 Martin Makundi martin.maku...@koodaripalvelut.com: Chicken. 2010/11/9 Eelco Hillenius eelco.hillen...@gmail.com: But all really depends on your approach. Some people think dabbling in a swamp gives you a firm grip. I cosinder it the opposite: swamp has a firm grip on you. I consider it asking for trouble. Wicket would sacrifice predictability and conceptual surface for the sake of making a few things slightly less annoying. :-) Eelco - 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 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); 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
Re: Free wicket from component hierarchy hell
Hi! So far, I have often heard about people not liking the requirement to match the code hierarchy in the markup. Most (not all!) of them have never actually used Wicket (I know this doesn't apply to Martin). Not once have I seen a convincing productive(!) example of where it was an actual problem. In my current day-to-day work on a reasonably large project, this hasn't come up *at all*. heree I can only ask you: Have you ever seen friction with your own eyes? It's just the itchy feeling you get all day long when coding in the zone. This unneccessary fuzz is in my way. It might not be for everyone, but please don't deprive the needy ones. ** Martin Carl-Eric www.wicketbuch.de On Tue, 9 Nov 2010 08:41:02 +0200 Martin Makundi martin.maku...@koodaripalvelut.com wrote: Hi! Or should I say, boldly go where no man has gone before or Do, or do not. There is no 'try.' . ** Martin 2010/11/9 Martin Makundi martin.maku...@koodaripalvelut.com: Chicken. 2010/11/9 Eelco Hillenius eelco.hillen...@gmail.com: But all really depends on your approach. Some people think dabbling in a swamp gives you a firm grip. I cosinder it the opposite: swamp has a firm grip on you. I consider it asking for trouble. Wicket would sacrifice predictability and conceptual surface for the sake of making a few things slightly less annoying. :-) Eelco - 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, 9 Nov 2010 10:20:12 +0200 Martin Makundi martin.maku...@koodaripalvelut.com 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); Possibly. I'd rather not have the unnecessary complexity of this feature at all though. I certainly wouldn't want to support it if I was a wicket developer :-) Which is default false? This way you can make sure nobody in YOUR project messes things up? I have new projects every now and then, and most of them are already underway when I get called in. Which is why I like toolkits that do not encourage sloppiness(*). Carl-Eric www.wicketbuch.de *) sloppiness != easy to write I'm all for static typing, since it saves me the work of checking the types. I'd like it to be more like Scala, which saves me the typing I have to do in Java, while still giving me the same guarantees. With your proposed config switch, you're basically giving up one of Wicket's guarantees, the one that the hierarchy is what it looks like in the code. - 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 10:23:27 +0200 Martin Makundi martin.maku...@koodaripalvelut.com wrote: Hi! So far, I have often heard about people not liking the requirement to match the code hierarchy in the markup. Most (not all!) of them have never actually used Wicket (I know this doesn't apply to Martin). Not once have I seen a convincing productive(!) example of where it was an actual problem. In my current day-to-day work on a reasonably large project, this hasn't come up *at all*. heree I can only ask you: Have you ever seen friction with your own eyes? Coding friction? Yes. Every time I need to look at somebody else's code and try to figure out what exactly they did. And as a consultant (I know, I said the nasty word) that is a pretty big part of what I do. 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 :-) 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. It might not be for everyone, but please don't deprive the needy ones. 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*. 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
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
Re: Free wicket from component hierarchy hell
This is pretty much exactly what I'd do given such a requirement. If something is so different as to require a different internal hierarchy, it's no longer the same component. Make a new component and use standard OO techniques for code reuse, like Frank wrote here. This certainly is not worth the can of worms that's being opened right now. Carl-Eric www.wicketbuch.de On Tue, 9 Nov 2010 08:46:54 -0600 Frank Silbermann frank.silberm...@fedex.com 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 lookfeel 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 Tsaplinvitaly.tsap...@gmail.com: 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. Sounds like the first appealing argument slowly comming out of surrounding fuzz =) - 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, 9 Nov 2010 14:21:46 +0200 Martin Makundi martin.maku...@koodaripalvelut.com wrote: Here we finally come to an actual argument about this: Panel is not reusable enough because it has its own markup. If I override its markup, it stops working. Frank wrote in another message how to deal with this case. I agree with him and add: If your new panel is so different from the old panel that it requires a different internal hierarchy, it's no longer the same component. Use standard OO techniques to deal with it. Also, think about whether your component design (as in what parts form a component, and what parts don't) is correct. Seems to me that in such a case too many things have been thrown together that should not be together. 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 11:01:28 +0200 Martin Makundi martin.maku...@koodaripalvelut.com 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, ... So a clear architecture is a plastic sword? And do whatever you want is better? 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 ;))) There isn't. That's not the point. So far your argument seems to be #1 I don't like this and #2 those who don't agree with you aren't good coders. 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. WTF? Your argument #3 is that *I* want to screw my customers over? Seriously? 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). This just doesn't make sense. Put your stuff in a panel, then it's a self-contained component and insulated from the hierarchy of the page and other components. Then you can put that component wherever you want. 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 ;))) And I still haven't yet seen a convincing example of this being a problem worth adding the complexity. Then again, in the end the Wicket devs need to decide on whether they want to support this or not. So far *my* definitely non-binding vote is -1 :) 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
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. Sounds like the first appealing argument slowly comming out of surrounding fuzz =) - 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
Also making skins for different devices / screen sizes becomes easier. ** Martin 2010/11/9 Vitaly Tsaplin vitaly.tsap...@gmail.com: 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. Sounds like the first appealing argument slowly comming out of surrounding fuzz =) - 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! 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 lookfeel 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 Tsaplinvitaly.tsap...@gmail.com: 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. Sounds like the first appealing argument slowly comming out of surrounding fuzz =) - 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
your proposal is to wicket, what auto-generating-java-servlet-code is to a JSP (~ what a tied-and-deciding-designer-code was to a programmer-code in the past) that is, simply going back to hell :) why don't you stay on JSP domain, instead, sir? Please have some patience, just watch and see what will come out of it. You can decide for yourself whether to use it or not. Wicket community can decide whether to keep the patch as wicket-stuff or wicket. ** Martin On Tue, Nov 9, 2010 at 1:47 PM, Matthias Keller matthias.kel...@ergon.chwrote: Hi Martin Isn't this exactly the reason we've got CSS? HTML shouldn't really be used for lookfeel and the size and placement of components can perfectly be defined using CSS classes. 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 Tsaplinvitaly.tsap...@gmail.com: 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. Sounds like the first appealing argument slowly comming out of surrounding fuzz =) - 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
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 lookfeel 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 Tsaplinvitaly.tsap...@gmail.com: 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. Sounds like the first appealing argument slowly comming out of surrounding fuzz =) - 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! I don't think there is a substitute for coding skills/talent ;))) There isn't. That's not the point. So far your argument seems to be #1 I don't like this and #2 those who don't agree with you aren't good coders. Bad coding was your argument, not mine ;) I simply don't allow bad coders into the equation. So a clear architecture is a plastic sword? No, but if you don't facilitate certaint things it sort of takes the edge off the blade ... child play stuff. You must prefer linux over windows, eh? All those linked libraries ... This just doesn't make sense. Put your stuff in a panel, then it's a self-contained component and insulated from the hierarchy of the page and other components. Then you can put that component wherever you want. Panel is not reusable enough because it has its own markup. If I override its markup, it stops working. And I still haven't yet seen a convincing example of this being a problem worth adding the complexity. 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. ** Martin - 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 10:05:39 -0500 James Carman ja...@carmanconsulting.com wrote: 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. +0.5 If this can be done with a special-case container (HighlyDangerousLiquidHierarchyMarkupContainer ;-) ), I wouldn't really mind, as long as the impact on the rest of the framework is small. I do not think it's worth it to change the whole framework around this special case. Especially since things like enabling/disabling of components based on their parents in the hierarchy don't seem to have been addressed yet. 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
your proposal is to wicket, what auto-generating-java-servlet-code is to a JSP (~ what a tied-and-deciding-designer-code was to a programmer-code in the past) that is, simply going back to hell :) why don't you stay on JSP domain, instead, sir? On Tue, Nov 9, 2010 at 1:47 PM, Matthias Keller matthias.kel...@ergon.chwrote: Hi Martin Isn't this exactly the reason we've got CSS? HTML shouldn't really be used for lookfeel and the size and placement of components can perfectly be defined using CSS classes. 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 Tsaplinvitaly.tsap...@gmail.com: 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. Sounds like the first appealing argument slowly comming out of surrounding fuzz =)
Re: Free wicket from component hierarchy hell
Hi Martin Isn't this exactly the reason we've got CSS? HTML shouldn't really be used for lookfeel and the size and placement of components can perfectly be defined using CSS classes. 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 Tsaplinvitaly.tsap...@gmail.com: 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. Sounds like the first appealing argument slowly comming out of surrounding fuzz =) smime.p7s Description: S/MIME Cryptographic Signature
Re: Free wicket from component hierarchy hell
For what it's worth, I agree with these sentiments. I am not jazzed about this whole auto hierarchy idea. I too like the predictability of Wicket and I don't mind staying within the confines of a strict hierarchy. I've kept quiet until now because I really don't have the time to jump into this debate whole-heartedly, but I wanted to at least let my voice be heard as one who opposes such an idea. On Tue, Nov 9, 2010 at 3:15 AM, Carl-Eric Menzel cmen...@wicketbuch.de wrote: Hi, no offense meant, but the rhetoric in this thread is getting more and more ridiculous. Chicken? Component hierarchy hell? Seriously? At most maybe component hierarchy slight annoyance. I am not at all convinced that this is a good idea. In my opinion, one of the strongest and best points about Wicket is that it has a set of very clear and logical concepts and does not deviate from them. I especially like the fact that the truth is in the code and the code rules, period. Unlike Tapestry, where you could pull all kinds of stunts by using a special notation in the ID attributes of markup elements. The next thing is going to be that some developers don't want to touch the code just because the designer wants a login panel on this other page too. So why can't the designer write wicket:instantiate class=foo/? It's just another hierarchy element, isn't it? 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. The loss of predictability and clear concepts isn't worth the very slight gain in... well, gain in what? In the ability to let code and markup drift apart? To be honest, I don't even see the possible gain with this change. So far, I have often heard about people not liking the requirement to match the code hierarchy in the markup. Most (not all!) of them have never actually used Wicket (I know this doesn't apply to Martin). Not once have I seen a convincing productive(!) example of where it was an actual problem. In my current day-to-day work on a reasonably large project, this hasn't come up *at all*. Not even in our sprint retrospectives, where people are specifically asked to complain! Carl-Eric www.wicketbuch.de On Tue, 9 Nov 2010 08:41:02 +0200 Martin Makundi martin.maku...@koodaripalvelut.com wrote: Hi! Or should I say, boldly go where no man has gone before or Do, or do not. There is no 'try.' . ** Martin 2010/11/9 Martin Makundi martin.maku...@koodaripalvelut.com: Chicken. 2010/11/9 Eelco Hillenius eelco.hillen...@gmail.com: But all really depends on your approach. Some people think dabbling in a swamp gives you a firm grip. I cosinder it the opposite: swamp has a firm grip on you. I consider it asking for trouble. Wicket would sacrifice predictability and conceptual surface for the sake of making a few things slightly less annoying. :-) Eelco - 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 7:49 AM, manuelbarzi manuelba...@gmail.com wrote: why don't you stay on JSP domain, instead, sir? Let's keep it civil here folks. Can we agree to disagree without being disagreeable? - 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
may it be enough just create an independent simple
html-code-processor-to-wicket-java-code-tool, that would auto-generate that
tedious code you would like to avoid? a simple java-class-processor-tool may
help for that... possible an eclipse-wicket-plugin-tool, if it doesn't
already exists...
On Thu, Nov 4, 2010 at 11:13 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Can you see the matrix?
;)
If you have:
html
form wicket:id=form
input wicket:id=input .../
/form
/html
public class MyPage extends WebPage {
public MyPage () {
add(new Form(form));
add(new TextField(input, model)); // Wicket could
automatically handle parse hierarchy from markup
}
}
**
Martin
2010/11/5 Martin Makundi martin.maku...@koodaripalvelut.com:
1. I want freedom inside panels.
2. Doubly defined hierarhices are redundant. Server-side hierarchy can
be automatically deduced from markup hierarcy. Such tasks should be
done by COMPUTER. Not coder.
**
Martin
2010/11/5 Jonathan Locke jonathan.lo...@gmail.com:
I think if you find component hierarchies to be hell, you probably
aren't
using Wicket right. Break things down into small reusable chunks using
Panels and you will find everything gets much, much easier.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Free-wicket-from-component-hierarchy-hell-tp3027705p3027881.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
As an alternative, suppose that one's non-panel compound component contained a map from wicket-id's to components. The hierarchy could be encoded in a lisp-like string; the component's constructor could parse the string and create the component hierarchy to match. The hierarchy string could be a configuration property that the constructor looks up. When you want to use the component on an HTML page whose wicket-ids are embedded differently, set the configuration parameter to the desired hierarchy string. 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? -Original Message- From: Carl-Eric Menzel [mailto:cmen...@wicketbuch.de] Sent: Tuesday, November 09, 2010 9:12 AM To: users@wicket.apache.org Subject: Re: Free wicket from component hierarchy hell On Tue, 9 Nov 2010 14:21:46 +0200 Martin Makundi martin.maku...@koodaripalvelut.com wrote: Here we finally come to an actual argument about this: Panel is not reusable enough because it has its own markup. If I override its markup, it stops working. Frank wrote in another message how to deal with this case. I agree with him and add: If your new panel is so different from the old panel that it requires a different internal hierarchy, it's no longer the same component. Use standard OO techniques to deal with it. Also, think about whether your component design (as in what parts form a component, and what parts don't) is correct. Seems to me that in such a case too many things have been thrown together that should not be together. 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
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. That sounds really slick a good example of what we are trying to avoid having to do. ** Martin /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 lookfeel 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 Tsaplinvitaly.tsap...@gmail.com: 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. Sounds like the first appealing argument slowly comming out of surrounding fuzz =) - 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 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 -Original Message- Fro - 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 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 frank.silberm...@fedex.com 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 lookfeel 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 Tsaplinvitaly.tsap...@gmail.com: 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. Sounds like the first appealing argument slowly comming out of surrounding fuzz =) - 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 10:23 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: That's not how proggress is made... Well, it's at least a sane place to start. Figuring out how Wicket can be used as-is to solve your problem lets you know if it's really a problem or not. If this can be done in a non-intrusive way, then you can just do it yourself and provide it as a wicketstuff module. If enough folks use it and say man, I really wish the core framework worked like this, then perhaps we consider putting it into the core. - 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
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
Re: Free wicket from component hierarchy hell
That's not how proggress is made... Well, it's at least a sane place to start. Figuring out how Wicket can be used as-is to solve your problem lets you know if it's really a problem or not. I've been dabbling with Wicket for 2,5 years now, and I have now finally come up with this request for the core wicketeers to show us the correct way to patch this particular issue. I am very thankful for the very proactive proposition by Igor, we are working on it. If this can be done in a non-intrusive way, then you can just do it yourself and provide it as a wicketstuff module. If enough folks use it and say man, I really wish the core framework worked like this, then perhaps we consider putting it into the core. Sounds completely fair to me. ** 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
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. I feel I understand its powers and limitations. Its powers have not shown to be a problem, but its limitations need some alleviation ;) ** Martin -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
On Tue, 9 Nov 2010 17:23:18 +0200 Martin Makundi martin.maku...@koodaripalvelut.com wrote: 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... So far you are *still* the only one in favor of this whole idea. You have not really replied to any of proposed solutions except with [paraphrased] I don't want to do it that way or some silliness about child's play. At the same time, you have not responded to valid criticisms like the problems with enabledInHierarchy (at least I haven't seen any such response). I finally understand your problem now that it has been defined somewhat, but I do not think your suggestion is a good solution to it. There are other solutions with a much smaller impact. 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
Well.. that's what we are doing, at runtime.
**
Martin
2010/11/9 manuelbarzi manuelba...@gmail.com:
may it be enough just create an independent simple
html-code-processor-to-wicket-java-code-tool, that would auto-generate that
tedious code you would like to avoid? a simple java-class-processor-tool may
help for that... possible an eclipse-wicket-plugin-tool, if it doesn't
already exists...
On Thu, Nov 4, 2010 at 11:13 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Can you see the matrix?
;)
If you have:
html
form wicket:id=form
input wicket:id=input .../
/form
/html
public class MyPage extends WebPage {
public MyPage () {
add(new Form(form));
add(new TextField(input, model)); // Wicket could
automatically handle parse hierarchy from markup
}
}
**
Martin
2010/11/5 Martin Makundi martin.maku...@koodaripalvelut.com:
1. I want freedom inside panels.
2. Doubly defined hierarhices are redundant. Server-side hierarchy can
be automatically deduced from markup hierarcy. Such tasks should be
done by COMPUTER. Not coder.
**
Martin
2010/11/5 Jonathan Locke jonathan.lo...@gmail.com:
I think if you find component hierarchies to be hell, you probably
aren't
using Wicket right. Break things down into small reusable chunks using
Panels and you will find everything gets much, much easier.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Free-wicket-from-component-hierarchy-hell-tp3027705p3027881.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 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 mgrigo...@apache.org 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 frank.silberm...@fedex.com 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 lookfeel 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 Tsaplinvitaly.tsap...@gmail.com: 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. Sounds like the first appealing argument slowly comming out of surrounding fuzz =) - 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
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? 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 mgrigo...@apache.org 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 frank.silberm...@fedex.com 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 lookfeel 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 Tsaplinvitaly.tsap...@gmail.com: 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. Sounds like the first appealing argument slowly comming out of surrounding fuzz =) - 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 10:32 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: I've been dabbling with Wicket for 2,5 years now, and I have now finally come up with this request for the core wicketeers to show us the correct way to patch this particular issue. I'm not necessarily saying it's not an issue. I get what you're saying about having to stick to the hierarchy when designing markup files. I just don't know whether this approach is the best or not. Again, I really haven't had a chance to sit down and think it through. Sounds completely fair to me. Why don't you put this work into wicketstuff (or flesh it out more with Igor in his git repo first and then move it), so we can see what it's all about and perhaps try it out for ourselves? - 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
At the same time, you have not responded to valid criticisms like the problems with enabledInHierarchy (at least I haven't seen any such response). @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. I'm not necessarily saying it's not an issue. I get what you're saying about having to stick to the hierarchy when designing markup files. I just don't know whether this approach is the best or not. Again, I really haven't had a chance to sit down and think it through. @James I think Igor thought it through very well.. also Sebastian, Rodolfo and Michal have had very proactive comments. I apologise that it takes some time to code it, but we'll be back with a freebie for everybody to try out for themselves ;) ** 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 10:48 AM, Frank Silbermann frank.silberm...@fedex.com 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. - 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 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. Yes, and if they are at different levels in the hierarchy, Wicket can figure that out also, at runtime. ** 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 10:58 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: Yes, and if they are at different levels in the hierarchy, Wicket can figure that out also, at runtime. 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? - 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! 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? 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, 9 Nov 2010 17:46:13 +0200 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. 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 10:51:49 -0500 James Carman ja...@carmanconsulting.com wrote: On Tue, Nov 9, 2010 at 10:48 AM, Frank Silbermann frank.silberm...@fedex.com 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. 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
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... Quite the opposite in the general case. I cannot come up with an example case that would require to watch the html code, more than we must do already now. ** Martin 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 - 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 18:04:44 +0200 Martin Makundi martin.maku...@koodaripalvelut.com 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 Having read the readme there, this is starting to finally make some sense. This proposed solution might actually work without too much breakage. I still don't see the necessity for this change, but I'm willing to change my -1 to a -0.5. I'll go for a -0 if it can be shown that the impact of this on the rest of Wicket is minimal (i.e., it needs few code changes and doesn't break any assumptions in framework or user code, for example about when exactly the component tree is available). Carl-Eric www.wicketbuch.de 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. - 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:
div wicket:id=adiv wicket:id=a/div/div
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
Re: Free wicket from component hierarchy hell
On Tue, Nov 9, 2010 at 11:04 AM, Martin Makundi martin.maku...@koodaripalvelut.com 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
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:34 AM, Martin Makundi martin.maku...@koodaripalvelut.com 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
On Tue, Nov 9, 2010 at 11:10 AM, Carl-Eric Menzel cmen...@wicketbuch.de 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
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
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
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 Makundimartin.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. 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 Tue, Nov 9, 2010 at 11:40 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Yeah ids must be unique per each level and ofcourse if you have markup like:
div wicket:id=adiv wicket:id=a/div/div
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
On Tue, 9 Nov 2010 11:33:31 -0500 James Carman ja...@carmanconsulting.com 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
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 ja...@carmanconsulting.com wrote:
On Tue, Nov 9, 2010 at 11:40 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Yeah ids must be unique per each level and ofcourse if you have markup like:
div wicket:id=adiv wicket:id=a/div/div
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
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
On Tue, Nov 9, 2010 at 11:47 AM, Carl-Eric Menzel cmen...@wicketbuch.de 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
On Tue, Nov 9, 2010 at 7:36 AM, John Owen jo...@globalscape.com 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 mgrigo...@apache.org 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 frank.silberm...@fedex.com 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 lookfeel 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 Tsaplinvitaly.tsap...@gmail.com: 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. Sounds like the first appealing argument slowly comming out of surrounding fuzz =) - 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
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 cmen...@wicketbuch.de 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 igor.vaynb...@gmail.com 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 8:10 AM, Carl-Eric Menzel cmen...@wicketbuch.de wrote: On Tue, 9 Nov 2010 10:51:49 -0500 James Carman ja...@carmanconsulting.com wrote: On Tue, Nov 9, 2010 at 10:48 AM, Frank Silbermann frank.silberm...@fedex.com 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: tr wicket:id=repeatertdspan wicket:id=first/ span wicket:id=last//td/tr 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
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
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 ja...@carmanconsulting.com wrote: On Tue, Nov 9, 2010 at 11:48 AM, Igor Vaynberg igor.vaynb...@gmail.com 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
On Tue, Nov 9, 2010 at 11:55 AM, Martin Makundi martin.maku...@koodaripalvelut.com 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
On Tue, Nov 9, 2010 at 11:55 AM, Igor Vaynberg igor.vaynb...@gmail.com 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
