Free wicket from component hierarchy hell
I propose "Free Wicket" from component-hierarchy hell We have discussd before that Wicket has unnecessary binding to wicket:id and component hierarchy [http://www.mail-archive.com/users@wicket.apache.org/msg53941.html]. I think I found a simple solution: "wicket:id" should be allowed to be on any level within given Panel-type element. User has freedom to position components and change html layout. What you think? Old wicket applications can be automatically refectored to have unique ids. Currently the wicket hardcoded component hierarchy slows down development and is totally unnecessary. https://cwiki.apache.org/confluence/display/WICKET/Wicket+1.5+Wish+List ** 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
Perhaps this is what you mean by "any level within given Panel-type element", but would this not screw up making components? The hierarchy is rather important for this - unlike JSP, etc where you just dump data references in a "page response" Components are one of the things that makes Wicket so nice. On 11/4/10 1:13 PM, Martin Makundi wrote: I propose "Free Wicket" from component-hierarchy hell We have discussd before that Wicket has unnecessary binding to wicket:id and component hierarchy [http://www.mail-archive.com/users@wicket.apache.org/msg53941.html]. I think I found a simple solution: "wicket:id" should be allowed to be on any level within given Panel-type element. User has freedom to position components and change html layout. What you think? Old wicket applications can be automatically refectored to have unique ids. Currently the wicket hardcoded component hierarchy slows down development and is totally unnecessary. https://cwiki.apache.org/confluence/display/WICKET/Wicket+1.5+Wish+List ** 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
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
Re: Free wicket from component hierarchy hell
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 : > > 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
Can you see the matrix?
;)
If you have:
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 :
> 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 :
>>
>> 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
On Thu, Nov 4, 2010 at 5:13 PM, Martin Makundi <
martin.maku...@koodaripalvelut.com> wrote:
> Can you see the matrix?
>
> ;)
>
> If you have:
>
>
>
>
>
>
>
> 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
>
Can you see how this would fail?
When wicket looks up "input", it must look it up on the appropriate parent
component. You can't have two things in your page (or panel) that have the
same ID - Wicket couldn't possibly know how to differentiate which component
you mean when it parses the markup and finds the tag with ID "input".
What about repeaters?
What about if form1 was in BasePage.html and form2 was in HomePage.html
(which extends BasePage.html) - how do we know which input component to
get? The one you called add on in BasePage.java, or the one in
HomePage.java? Oh, we can't differentiate which class you called add from
within. Oh, and you could have meant for the one added in HomePage.java to
replace the one added in BasePage.java.
How do you propose we do all that?
--
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Free wicket from component hierarchy hell
Hi! > Can you see how this would fail? > > > > > > > > > That's old-school-wicket ;) This would not be allowed anymore. An application would have to be refactored (using an automated script) into: We would simply change wicket syntax: panels and pages require unique wicket id for all components. > What about repeaters? What about repeaters? Repeaters are generated on-the-fly anyways so they can be definitely computed on-the-fly. > What about if form1 was in BasePage.html and form2 was in HomePage.html > (which extends BasePage.html) - how do we know which input component to > get? The one you called add on in BasePage.java, or the one in > HomePage.java? Oh, we can't differentiate which class you called add from > within. Oh, and you could have meant for the one added in HomePage.java to > replace the one added in BasePage.java. > > How do you propose we do all that? You win some, you lose some. Nobody ever complained that parent and super classes cannot have protected fields with same names. Wicket:ids simply are considered protected-scoped. Maybe it could also be possible to define wicket:id:private which requires hierarcy and wicket:id which is "friendly" visibility etc. When there is a will, there is a way. ** Martin > > -- > 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
Hi! We could also make so that "wicket:id" is old-school and "wicket:id:protected" is new-school. No need to refactor anything. Just pros without any cons. ** Martin 2010/11/5 Martin Makundi : > Hi! > >> Can you see how this would fail? >> >> >> >> >> >> >> >> >> > > That's old-school-wicket ;) > > This would not be allowed anymore. An application would have to be > refactored (using an automated script) into: > > > > > > > > > > > We would simply change wicket syntax: panels and pages require unique > wicket id for all components. > >> What about repeaters? > > What about repeaters? Repeaters are generated on-the-fly anyways so > they can be definitely computed on-the-fly. > >> What about if form1 was in BasePage.html and form2 was in HomePage.html >> (which extends BasePage.html) - how do we know which input component to >> get? The one you called add on in BasePage.java, or the one in >> HomePage.java? Oh, we can't differentiate which class you called add from >> within. Oh, and you could have meant for the one added in HomePage.java to >> replace the one added in BasePage.java. >> >> How do you propose we do all that? > > You win some, you lose some. Nobody ever complained that parent and > super classes cannot have protected fields with same names. Wicket:ids > simply are considered protected-scoped. Maybe it could also be > possible to define wicket:id:private which requires hierarcy and > wicket:id which is "friendly" visibility etc. > > When there is a will, there is a way. > > ** > Martin > >> >> -- >> 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
Hi. I think its not a solution for problem which Martin described. If you cooperate with some outer company which provide you styled markup or they are modifing an existing one they can broke your hierarchy and you must change your code. It would be nice to not do this, for e.g adding everythink to page. I know that in this case (Jeremy wrote that) you must provide uniqueness of components in whole page but it also can be resolved somehow :) 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. - 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 know that in this case (Jeremy wrote that) you must provide > uniqueness of components in whole page but it also can be resolved somehow +1 Also DOM requires id uniqueness according to spec so it is nothing new to web developers. ** Martin > >> 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. > > - > 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 Fri, Nov 5, 2010 at 10:07 AM, Martin Makundi < martin.maku...@koodaripalvelut.com> wrote: > > I know that in this case (Jeremy wrote that) you must provide > > uniqueness of components in whole page but it also can be resolved > somehow > > +1 > > Also DOM requires id uniqueness according to spec so it is nothing new > to web developers. > Martin, Did you understand what Jeremy and Michal described above ? If you have to use libraries A and B that provide Wicket components and both of them use "message" or "feedback" as component id in any of their components then how your application will deal with that ? > > ** > Martin > > > > >> 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. > > > > - > > 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! > If you have to use libraries A and B that provide Wicket components and both > of them use "message" or "feedback" as component id in any of their > components then how your application will deal with that ? You make decision: feedback is either private (traditional) or protected/panel-scope member. Both ways can be supported. Ifcourse even better if we can have compile-time conflict resolution (Project Lombok, Bindgen). ** Martin > >> >> ** >> Martin >> >> > >> >> 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. >> > >> > - >> > 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 Fri, Nov 5, 2010 at 10:16 AM, Martin Makundi < martin.maku...@koodaripalvelut.com> wrote: > Hi! > > > If you have to use libraries A and B that provide Wicket components and > both > > of them use "message" or "feedback" as component id in any of their > > components then how your application will deal with that ? > > You make decision: feedback is either private (traditional) or > protected/panel-scope member. Both ways can be supported. Ifcourse > even better if we can have compile-time conflict resolution (Project > Lombok, Bindgen). > Let's say both libraries are "modern" (because private scope is old-fashion, right) and export "message" with Page scope. Then project X (Lombok, Bindgen) finds the problem at compile time and explain you that both lib A and B export component with the same id. What would you do now ? Throw away either lib A or B and re-write it ? > > ** > Martin > > > > >> > >> ** > >> Martin > >> > >> > > >> >> 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. > >> > > >> > - > >> > 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
> Let's say both libraries are "modern" (because private scope is old-fashion, > right) and export "message" with Page scope. > Then project X (Lombok, Bindgen) finds the problem at compile time and > explain you that both lib A and B export component with the same id. > What would you do now ? > Throw away either lib A or B and re-write it ? Please give a concrete example of such situation. If names are panel or page scope I cannot immagine many worthwile items that can be imported onto panels and pages that cannot be refactored. ** Martin > >> >> ** >> Martin >> >> > >> >> >> >> ** >> >> Martin >> >> >> >> > >> >> >> 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. >> >> > >> >> > - >> >> > 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
To be more precise: namespace would always be per each markupcontainer which has its own markup. ** Martin > Please give a concrete example of such situation. If names are panel > or page scope I cannot immagine many worthwile items that can be > imported onto panels and pages that cannot be refactored. > > ** > Martin > >> >>> >>> ** >>> Martin >>> >>> > >>> >> >>> >> ** >>> >> Martin >>> >> >>> >> > >>> >> >> 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. >>> >> > >>> >> > - >>> >> > 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
LibA provides PanelA which exports ComponentA with id == "messages" (e.g. ListView) with Page scope. LibB provides PanelB which exports ComponentB with id == "messages" (e.g. DataGrid) with Page scope. Then your application has a page MyPage which includes both PanelA and PanelB and the problem arises. On Fri, Nov 5, 2010 at 10:29 AM, Martin Makundi < martin.maku...@koodaripalvelut.com> wrote: > > Let's say both libraries are "modern" (because private scope is > old-fashion, > > right) and export "message" with Page scope. > > Then project X (Lombok, Bindgen) finds the problem at compile time and > > explain you that both lib A and B export component with the same id. > > What would you do now ? > > Throw away either lib A or B and re-write it ? > > Please give a concrete example of such situation. If names are panel > or page scope I cannot immagine many worthwile items that can be > imported onto panels and pages that cannot be refactored. > > ** > Martin > > > > >> > >> ** > >> Martin > >> > >> > > >> >> > >> >> ** > >> >> Martin > >> >> > >> >> > > >> >> >> 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. > >> >> > > >> >> > > - > >> >> > 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
Hi In my opinion, when you use lots of inheritance in a page, its really imposible to control if a component appears just once in the page. Wicket is great for the ability to reuse components. Actually I've been able to create a private framework where I'm able to build an entire page with components binded to a JPA entity bean just with some annotations (amazing productivity). If the project gets complicated, I think there is no possible way to control the uniqueness of the component in the page. The advantages of adding a component wherever you cant along the hierarchy are true, I don't think that your proposal gives the best of both worlds. Regards -- Marc Nuri
Re: Free wicket from component hierarchy hell
On Fri, Nov 5, 2010 at 10:31 AM, Martin Makundi < martin.maku...@koodaripalvelut.com> wrote: > To be more precise: namespace would always be per each markupcontainer > which has its own markup. > So the "hell" is still here. It is just moved one level up. It seems you didn't think of all cases. > > ** > Martin > > > Please give a concrete example of such situation. If names are panel > > or page scope I cannot immagine many worthwile items that can be > > imported onto panels and pages that cannot be refactored. > > > > ** > > Martin > > > >> > >>> > >>> ** > >>> Martin > >>> > >>> > > >>> >> > >>> >> ** > >>> >> Martin > >>> >> > >>> >> > > >>> >> >> 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. > >>> >> > > >>> >> > > - > >>> >> > 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
> LibA provides PanelA which exports ComponentA with id == "messages" (e.g. > ListView) with Page scope. PanelA defines independent namespace. > LibB provides PanelB which exports ComponentB with id == "messages" (e.g. > DataGrid) with Page scope. PanelB defines independent namespace. > Then your application has a page MyPage which includes both PanelA and > PanelB and the problem arises. MyPage defines new namespace. PanelA and PanelB are independent. No problems. ** Martin > > On Fri, Nov 5, 2010 at 10:29 AM, Martin Makundi < > martin.maku...@koodaripalvelut.com> wrote: > >> > Let's say both libraries are "modern" (because private scope is >> old-fashion, >> > right) and export "message" with Page scope. >> > Then project X (Lombok, Bindgen) finds the problem at compile time and >> > explain you that both lib A and B export component with the same id. >> > What would you do now ? >> > Throw away either lib A or B and re-write it ? >> >> Please give a concrete example of such situation. If names are panel >> or page scope I cannot immagine many worthwile items that can be >> imported onto panels and pages that cannot be refactored. >> >> ** >> Martin >> >> > >> >> >> >> ** >> >> Martin >> >> >> >> > >> >> >> >> >> >> ** >> >> >> Martin >> >> >> >> >> >> > >> >> >> >> 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. >> >> >> > >> >> >> > >> - >> >> >> > 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
> If the project gets complicated, I think there is no possible way to control > the uniqueness of the component in the page. The advantages of adding a > component wherever you cant along the hierarchy are true, I don't think that > your proposal gives the best of both worlds. This is a misunderstanding. Not ANYWHERE. Only on Panel and Page and similar markupprovider levels. > Regards > -- > Marc Nuri > - 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! >> To be more precise: namespace would always be per each markupcontainer >> which has its own markup. >> > So the "hell" is still here. It is just moved one level up. > It seems you didn't think of all cases. I must have miscommunicated myself, this is not at all what I meant. ** Martin > >> >> ** >> Martin >> >> > Please give a concrete example of such situation. If names are panel >> > or page scope I cannot immagine many worthwile items that can be >> > imported onto panels and pages that cannot be refactored. >> > >> > ** >> > Martin >> > >> >> >> >>> >> >>> ** >> >>> Martin >> >>> >> >>> > >> >>> >> >> >>> >> ** >> >>> >> Martin >> >>> >> >> >>> >> > >> >>> >> >> 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. >> >>> >> > >> >>> >> > >> - >> >>> >> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> >>> >> > For additional commands, e-mail: users-h...@wicket.apache.org >> >>> >> > >> >>> >> > >> >>> >> >> >>> >> >> - >> >>> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> >>> >> For additional commands, e-mail: users-h...@wicket.apache.org >> >>> >> >> >>> >> >> >>> > >> >>> >> >>> - >> >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> >>> For additional commands, e-mail: users-h...@wicket.apache.org >> >>> >> >>> >> >> >> > >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On 2010-11-05 09:37, Martin Makundi wrote: LibA provides PanelA which exports ComponentA with id == "messages" (e.g. ListView) with Page scope. PanelA defines independent namespace. LibB provides PanelB which exports ComponentB with id == "messages" (e.g. DataGrid) with Page scope. PanelB defines independent namespace. Then your application has a page MyPage which includes both PanelA and PanelB and the problem arises. MyPage defines new namespace. PanelA and PanelB are independent. No problems. and what about : add( new PanelA( new Model1() ); add( new PanelA( new Model2() ); add( new PanelA( new Model3() ); to the same page ? -- Leszek Gawron http://lgawron.blogspot.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 Fri, Nov 5, 2010 at 8:36 AM, Leszek Gawron wrote: > > add( new PanelA( new Model1() ); > add( new PanelA( new Model2() ); > add( new PanelA( new Model3() ); > > to the same page ? > Different ids? - 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
Yeah, Panel always has id, so what you do is:
add( new PanelA("id1", new Model1() );
add( new PanelA("id2", new Model2() );
add( new PanelA("id3", new Model3() );
All Panels would have their own namespace within themselves.
**
Martin
2010/11/5 James Carman :
> On Fri, Nov 5, 2010 at 8:36 AM, Leszek Gawron wrote:
>>
>> add( new PanelA( new Model1() );
>> add( new PanelA( new Model2() );
>> add( new PanelA( new Model3() );
>>
>> to the same page ?
>>
>
> Different ids?
>
> -
> 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 somewhat possible. in 1.5 we have added features that are
somewhat enabling to this such as oninitializecallback and early
markup availability.
we can make all adds() be flat and at runtime parse the hierarchy from
markup, since it is defined there. if we keep a transient
represenation of the hierarchy on the java side we can still properly
handle things that need it, eg isVisibleInHierarchy().
what bothers me about this is that it wont work for everything. for
example, it wont work for repeaters:
add(new listview("contacts",...) {
onpopulateitem(item) {
// this code *has* to add to the item and not to the panel
because unique ids are not possible
}});
i wonder how many other cases like this will creep up, and at the end
will it be made easier when you have to think: in this case i can just
call add, but in this case i need to maintain the hierarchy somehow.
also right now it is easy to extract methods that do the same thing:
private void populate(WebMarkupContainer parent) {
parent.add(new Label("foo",...));
parent add(new Link("bar", parent.getModel()) {...};
}
such helpers will no longer be possible because we have forced the
panel to have unique wicket ids
these are just the two that come up off the top of my head.
in the end we have to figure out if the added simplicity is worth the
headache it brings for more complex usecases. what has always
attracted me to wicket is its consistency. once you learn how to add
components you can use the same method for all usecases and it works.
it seems like this would take away from that.
-igor
On Thu, Nov 4, 2010 at 1:13 PM, Martin Makundi
wrote:
> I propose "Free Wicket" from component-hierarchy hell
>
> We have discussd before that Wicket has unnecessary binding to
> wicket:id and component hierarchy
> [http://www.mail-archive.com/users@wicket.apache.org/msg53941.html].
>
> I think I found a simple solution: "wicket:id" should be allowed to be
> on any level within given Panel-type element. User has freedom to
> position components and change html layout.
>
> What you think?
>
> Old wicket applications can be automatically refectored to have unique
> ids. Currently the wicket hardcoded component hierarchy slows down
> development and is totally unnecessary.
>
> https://cwiki.apache.org/confluence/display/WICKET/Wicket+1.5+Wish+List
>
> **
> 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 Fri, Nov 5, 2010 at 11:55 AM, Igor Vaynberg wrote: > in the end we have to figure out if the added simplicity is worth the > headache it brings for more complex usecases. I don't think it is. Keeping the two hierarchies in sync is not really that difficult. The funny thing about the proposed approach is that it is in an effort to make things "simpler". But, as you pointed out, the more complex things won't work with the proposed approach (without probably some huge amount of hacks). So, the complex stays complex, and is then inconsistent with how all the other stuff works. I just really don't see the benefit in this. I've taught tons of people Wicket, and keeping the hierarchy in sync is hardly ever the thing that makes it difficult for people to learn or use. The only time I've seen it be an issue is with Borders. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Free wicket from component hierarchy hell
Hi!
> what bothers me about this is that it wont work for everything. for
> example, it wont work for repeaters:
> these are just the two that come up off the top of my head.
What do you mean? Repeaters have unique index, it's not a duplicate.
public ListItem(final int index, final IModel model)
{
super(Integer.toString(index).intern(), model);
this.index = index;
}
> such helpers will no longer be possible because we have forced the
> panel to have unique wicket ids
The developer can choose: using unique wicket:ids or traditional ones.
> what has always attracted me to wicket is its consistency. once you
> learn how to add components you can use the same method for all
> usecases and it works. it seems like this would take away from that.
It is consistent yes, but also redundant.
> Keeping the two hierarchies in sync is not really that difficult.
> I just really don't see the benefit in this. I've taught tons of people
> Wicket, and keeping the hierarchy in sync is hardly ever the
> thing that makes it difficult for people to learn or use.
It is not about being difficult, it's all about being efficient.
Redundancy is waste. Waste is bad. "Intentional waste" is even worse.
So let's lean it out ;]
**
Martin
>
> On Thu, Nov 4, 2010 at 1:13 PM, Martin Makundi
> wrote:
>> I propose "Free Wicket" from component-hierarchy hell
>>
>> We have discussd before that Wicket has unnecessary binding to
>> wicket:id and component hierarchy
>> [http://www.mail-archive.com/users@wicket.apache.org/msg53941.html].
>>
>> I think I found a simple solution: "wicket:id" should be allowed to be
>> on any level within given Panel-type element. User has freedom to
>> position components and change html layout.
>>
>> What you think?
>>
>> Old wicket applications can be automatically refectored to have unique
>> ids. Currently the wicket hardcoded component hierarchy slows down
>> development and is totally unnecessary.
>>
>> https://cwiki.apache.org/confluence/display/WICKET/Wicket+1.5+Wish+List
>>
>> **
>> Martin
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Fri, Nov 5, 2010 at 10:24 AM, Martin Makundi
wrote:
> Hi!
>
>> what bothers me about this is that it wont work for everything. for
>> example, it wont work for repeaters:
>> these are just the two that come up off the top of my head.
>
> What do you mean? Repeaters have unique index, it's not a duplicate.
>
> public ListItem(final int index, final IModel model)
> {
> super(Integer.toString(index).intern(), model);
> this.index = index;
> }
>
>> such helpers will no longer be possible because we have forced the
>> panel to have unique wicket ids
its not about the list *items* its about the components you add to them
onpopuateitem(item item) {
add(new label("name"));
add(new label("email"));
}
wont work
> The developer can choose: using unique wicket:ids or traditional ones.
i would not want to support both approaches. it will make things very
difficult for us and for developers. we should have one consistent
approach. you say its "hell" but let me remind you that you are in a
very very vast minority about this. how many threads on this list are
about this hell compared to other threads? not many at all, not even
1%. therefore, im not too inclined to change the way the entire
framework works for the loud 1%.
>> what has always attracted me to wicket is its consistency. once you
>> learn how to add components you can use the same method for all
>> usecases and it works. it seems like this would take away from that.
>
> It is consistent yes, but also redundant.
redundant for basic cases, yes. not redundant as soon as you are
trying to do something non-trivial. you cant build anything
interesting if you only try to use trivial constructs.
-igor
>> Keeping the two hierarchies in sync is not really that difficult.
>> I just really don't see the benefit in this. I've taught tons of people
>> Wicket, and keeping the hierarchy in sync is hardly ever the
>> thing that makes it difficult for people to learn or use.
>
> It is not about being difficult, it's all about being efficient.
> Redundancy is waste. Waste is bad. "Intentional waste" is even worse.
> So let's lean it out ;]
>
> **
> Martin
>
>>
>> On Thu, Nov 4, 2010 at 1:13 PM, Martin Makundi
>> wrote:
>>> I propose "Free Wicket" from component-hierarchy hell
>>>
>>> We have discussd before that Wicket has unnecessary binding to
>>> wicket:id and component hierarchy
>>> [http://www.mail-archive.com/users@wicket.apache.org/msg53941.html].
>>>
>>> I think I found a simple solution: "wicket:id" should be allowed to be
>>> on any level within given Panel-type element. User has freedom to
>>> position components and change html layout.
>>>
>>> What you think?
>>>
>>> Old wicket applications can be automatically refectored to have unique
>>> ids. Currently the wicket hardcoded component hierarchy slows down
>>> development and is totally unnecessary.
>>>
>>> https://cwiki.apache.org/confluence/display/WICKET/Wicket+1.5+Wish+List
>>>
>>> **
>>> Martin
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
Hi!
> its not about the list *items* its about the components you add to them
>
> onpopuateitem(item item) {
> add(new label("name"));
> add(new label("email"));
> }
>
> wont work
Why should it? Won't make it any easier than:
item.add(new label("name"));
item.add(new label("email"));
>> The developer can choose: using unique wicket:ids or traditional ones.
>
> i would not want to support both approaches. it will make things very
> difficult for us and for developers. we should have one consistent
> approach.
Thank god nobody said "640k will be enough for everybody".
Why is there private, friendly, package and public visibility
confusing java developers?
What about giving more freedom to design effectively according to
designer's choice?
> you say its "hell" but let me remind you that you are in a
> very very vast minority about this. how many threads on this list are
> about this hell compared to other threads? not many at all, not even
> 1%. therefore, im not too inclined to change the way the entire
> framework works for the loud 1%.
I believe most are just acustomed to using it as it is. Even more
people are accustomed using JSF.
That feels more like an excuse to refrain from making Wicket even better.
>>> what has always attracted me to wicket is its consistency. once you
>>> learn how to add components you can use the same method for all
>>> usecases and it works. it seems like this would take away from that.
>>
>> It is consistent yes, but also redundant.
>
> redundant for basic cases, yes. not redundant as soon as you are
> trying to do something non-trivial. you cant build anything
> interesting if you only try to use trivial constructs.
Web pages are 80% trivial. Small friction like doing unnecessary
hierarcy matching is waste of time. 5 min per hour, 40 minutes per
day, 800 minutes per month, 20 people team 16000 wasted minutes per
month is 33 days per month wasted only because of wicket hierarchies.
**
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
> Web pages are 80% trivial. Small friction like doing unnecessary > hierarcy matching is waste of time. 5 min per hour, 40 minutes per > day, 800 minutes per month, 20 people team 16000 wasted minutes per > month is 33 days per month wasted only because of wicket hierarchies. As time and time again research shows is that the real cost is not in the initial development, but in maintaining (which of course starts often while you're still doing the initial development, as it also includes refactoring on initial ideas etc). I think it is a bad idea to enable something that makes developing a little bit quicker/ easier but that makes problems potentially much harder to debug. As a comparison, my main pet-peeve with Hibernate for instance isn't that it doesn't save me enough lines of code, but that debugging problems with it can be bloody hard. And in fact, this can already be the case for Wicket as well, even as much around the framework is centered around avoiding that. Eelco - 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 think it is. Keeping the two hierarchies in sync is not really that > difficult. The funny thing about the proposed approach is that it is in an > effort to make things "simpler". But, as you pointed out, the more complex > things won't work with the proposed approach (without probably some huge > amount of hacks). So, the complex stays complex, and is then inconsistent > with how all the other stuff works. I agree. It's a bad idea. We should learn from other frameworks and our own past mistakes that consistency is everything. There's no doubt in my mind that this short cut would backfire at some point (and probably sooner than later). Instead, the focus should be on improving error diagnostics etc. Eelco - 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! > As time and time again research shows is that the real cost is not in > the initial development, but in maintaining (which of course starts > often while you're still doing the initial development, as it also > includes refactoring on initial ideas etc). I believe poorly developed software has high "maintenance costs" (bugfixing). Maintenance of well designed software is 80% new feature development. > I think it is a bad idea to enable something that makes developing a > little bit quicker/ easier but that makes problems potentially much > harder to debug. I don't see any difference in getting "hierarchy not matched" exception from either way. Ofcourse the main difference is that you would get much less such exceptions in the proposed scheme. ** 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
>> I don't think it is. Keeping the two hierarchies in sync is not really that >> difficult. The funny thing about the proposed approach is that it is in an >> effort to make things "simpler". But, as you pointed out, the more complex >> things won't work with the proposed approach (without probably some huge >> amount of hacks). So, the complex stays complex, and is then inconsistent >> with how all the other stuff works. > > I agree. It's a bad idea. We should learn from other frameworks and > our own past mistakes that consistency is everything. There's no doubt > in my mind that this short cut would backfire at some point (and > probably sooner than later). Instead, the focus should be on improving > error diagnostics etc. Duh.. I think there can be _no_ excuse to not reduce manual work where it is really not needed. It's not like we are talking about airline autopilots here. ** Martin > > 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
Re: Free wicket from component hierarchy hell
>> I think it is a bad idea to enable something that makes developing a >> little bit quicker/ easier but that makes problems potentially much >> harder to debug. > > I don't see any difference in getting "hierarchy not matched" > exception from either way. Ofcourse the main difference is that you > would get much less such exceptions in the proposed scheme. That's a fair point. So I guess that introducing a short cut like this could be OK as long as the error diagnosis is very clear. Eelco - 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 Fri, Nov 5, 2010 at 11:39 AM, Martin Makundi
wrote:
> Hi!
>
>> its not about the list *items* its about the components you add to them
>>
>> onpopuateitem(item item) {
>> add(new label("name"));
>> add(new label("email"));
>> }
>>
>> wont work
>
> Why should it? Won't make it any easier than:
>
> item.add(new label("name"));
> item.add(new label("email"))
right. this is the inconsistency i was talking about. sometimes you
use straight add() and everything works, but sometimes you have to add
to the proper component. this is going to cause headaches.
>>> The developer can choose: using unique wicket:ids or traditional ones.
>>
>> i would not want to support both approaches. it will make things very
>> difficult for us and for developers. we should have one consistent
>> approach.
>
> Thank god nobody said "640k will be enough for everybody".
thank god no one spent millions of dollars designing IEEE1394 to
compete against PCI and USB, otherwise it wouldve been a tremendous
waste.
> Why is there private, friendly, package and public visibility
> confusing java developers?
because without it you wouldnt be able to control visibility. your
proposal does not add any *new* features.
> What about giving more freedom to design effectively according to
> designer's choice?
because the designer delivers only part of the solution - the markup.
the missing part is the behavior and to think that the behavior can be
added in a completely orthogonal manner is foolish because behavior
and markup are tightly coupled on matter whichever way you slice it.
the best we can do is to make the coupling as easy and us unobtrusive
as possible.
the designers are free to move pieces around as long as they do not
cross wicket:id border, after all those borders are there for a reason
- to attach some behavior.
a very simple example is that you have a container that should only be
visible to admins of the application - this container contains
sensitive fields that normal users should not see.
now the developer takes the "salary" div and moves it out of the
"for-admins-only" div. guess what, your *designer* has just opened a
huge security hole in your application. who would use wicket if such
things were so easily possible?
>> you say its "hell" but let me remind you that you are in a
>> very very vast minority about this. how many threads on this list are
>> about this hell compared to other threads? not many at all, not even
>> 1%. therefore, im not too inclined to change the way the entire
>> framework works for the loud 1%.
>
> I believe most are just acustomed to using it as it is. Even more people are
> accustomed using JSF.
> That feels more like an excuse to refrain from making Wicket even better.
that is why we have no improvement and new feature requests in jira?
because everyone is ok with the status quo? is it also the reason why
we have not added anything new from 1.0 to 1.5, these have all been
bug fix releases?
what has always attracted me to wicket is its consistency. once you
learn how to add components you can use the same method for all
usecases and it works. it seems like this would take away from that.
>>>
>>> It is consistent yes, but also redundant.
and as with many such things we have to calculate if eliminating
redundancy is worth decreasing consistency.
>> redundant for basic cases, yes. not redundant as soon as you are
>> trying to do something non-trivial. you cant build anything
>> interesting if you only try to use trivial constructs.
>
> Web pages are 80% trivial. Small friction like doing unnecessary
> hierarcy matching is waste of time. 5 min per hour, 40 minutes per
> day, 800 minutes per month, 20 people team 16000 wasted minutes per
> month is 33 days per month wasted only because of wicket hierarchies.
if your web pages are trivial then why do you have hierarchy? you don
thave to have hierarchy in java just because it is in markup...you
dont have to model every single tag in wicket.
anywho, i think the fact that no one has really jumped in and sided
with you is a good indication where this is going.
-igor
>
> **
> Martin
>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Nov 5, 2010, at 3:01 PM, Martin Makundi wrote: > Duh.. I think there can be _no_ excuse to not reduce manual work where > it is really not needed. It's not like we are talking about airline > autopilots here. So we don't need Wicket to work predictably and reliably all the time? MTBF is a composite factor of all weaknesses, what happens when the next weak hacks are added? MTBF goes down exponentially. Do Not Want. As a dev, I really don't have a problem with assigning id attributes. And while I see cases where folks in this thread have identified areas where your proposal *could* work *much of the time*, I am 100% concerned about total cost of ownership, which is directly linked to maintainability. Putting on my stakeholder hat, I don't care if my developers have to type "wi" a thousand times if it means the code cannot be blindly refactored in the future by people who are completely unfamiliar with how the original code was written. Do Not Want. You might want to do some research on a version that was once considered "Wicket 2.0". It was a valiant effort by everyone involved, but eventually was one of those paths that had too much risk and did not end well. It wasn't just a problem for the framework developers (who also need to put bread on their families tables at the end of the day), but also for users who started coding to it and had to significantly refactor their applications when it ultimately didn't work. Wicket is open source though. Start a branch and prove your theory works! :-) Brian - 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
> because the designer delivers only part of the solution - the markup. I meant software designer. > > > > > > now the developer takes the "salary" div and moves it out of the > "for-admins-only" div. guess what, your *designer* has just opened a > huge security hole in your application. who would use wicket if such > things were so easily possible? I did not propose that. If hierarchy is parsed from markup the visibility rules will remain same at runtime. >> I believe most are just acustomed to using it as it is. Even more people are >> accustomed using JSF. >> That feels more like an excuse to refrain from making Wicket even better. > > that is why we have no improvement and new feature requests in jira? > because everyone is ok with the status quo? is it also the reason why > we have not added anything new from 1.0 to 1.5, these have all been > bug fix releases? I'm not standing in the way of this improvement ;) > anywho, i think the fact that no one has really jumped in and sided > with you is a good indication where this is going. Not so good indication ;) But pretty predictable ;) I think it's just fear of change. ** Martin >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
>> Duh.. I think there can be _no_ excuse to not reduce manual work where >> it is really not needed. It's not like we are talking about airline >> autopilots here. > > So we don't need Wicket to work predictably and reliably all the time? We are only proposing a new way of doing things faster with equal reliability or even better if piggybacked with compile time safety. > I see cases where folks in this thread have identified areas > where your proposal *could* work *much of the time*, I am > 100% concerned about total cost of ownership, which is > directly linked to maintainability. How do you see this explicitly affecting total cost of ownership? Wicket internal component path structure would not change a single bit. Only difference is that developer does not need to write code according to html hierarchy - instead wicket will deduche hierarchy from HTML. Total cost of ownership should be lower because of more efficient ways to produce new software. > As a dev, I really don't have a problem with assigning id attributes. > Putting on my stakeholder hat, I don't care if my developers have to > type "wi" This is not what the proposal is about. It's a proposal not to be obliged to nest components in java because they are already instructed to nest according to HTML. Simply leave out redundant bytecode instructions. > Wicket is open source though. Start a branch and prove your theory works! > :-) We will provide a patch if possible. However, we might need some help onto our endevor. ** 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 Fri, Nov 5, 2010 at 1:07 PM, Martin Makundi wrote: >> because the designer delivers only part of the solution - the markup. > > I meant software designer. > >> >> >> >> >> >> now the developer takes the "salary" div and moves it out of the >> "for-admins-only" div. guess what, your *designer* has just opened a >> huge security hole in your application. who would use wicket if such >> things were so easily possible? > > I did not propose that. If hierarchy is parsed from markup the > visibility rules will remain same at runtime. the above should have read: now the *designer* (not developer) takes the "salary" div and moves it out of the the designer is free to change the hierarchy, oblivious to whatever behavioral changes that can cause or why the hierarchy was there in the first place. but i bet the developers will get the blame :) >>> I believe most are just acustomed to using it as it is. Even more people >>> are accustomed using JSF. >>> That feels more like an excuse to refrain from making Wicket even better. >> >> that is why we have no improvement and new feature requests in jira? >> because everyone is ok with the status quo? is it also the reason why >> we have not added anything new from 1.0 to 1.5, these have all been >> bug fix releases? > > I'm not standing in the way of this improvement ;) no, you are just saying that we are against this because we dont want to improve the framework. which is obviously a bogus statement. >> anywho, i think the fact that no one has really jumped in and sided >> with you is a good indication where this is going. > > Not so good indication ;) But pretty predictable ;) I think it's just > fear of change. i think if you look at the history of conversations we had on this list you will find that to be the opposite. -igor > > ** > Martin > >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - 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 Nov 5, 2010, at 4:15 PM, Martin Makundi wrote: > We will provide a patch if possible. However, we might need some help > onto our endevor. If it's not possible, why would you expect someone else to do it? Step up and make it happen! Avoid the misunderstandings, show what it should do! If you are demonstrating progress on something that benefits the community, I'm sure the help you find you need will materialize along the way. You have the faith in your convictions to insist that this is the right thing to do, and people who aren't interested just have "fear of change". What is holding you back? A demonstration is far more valuable than a discussion. Brian - 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
>>> >>> >>> >>> >>> >>> now the developer takes the "salary" div and moves it out of the >>> "for-admins-only" div. guess what, your *designer* has just opened a >>> huge security hole in your application. who would use wicket if such >>> things were so easily possible? Traditional way can be supported, still, where it is needed. Automated regression testing is a good practice ;) Actually this hierarchy-less scheme can be implemented using a helper method: HierarchyUtils.helpMeAddThisComponentToItsParent(panel, component); *** Martin >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
>> We will provide a patch if possible. However, we might need some help >> onto our endevor. > > If it's not possible, why would you expect someone else to do it? > Step up and make it happen! Avoid the misunderstandings, show what it should > do! > > If you are demonstrating progress on something that benefits the community, > I'm sure the help you find you need will materialize along the way. "We will be back with a patch" ;) ** Martin > > Brian > - > 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 Sat, Nov 6, 2010 at 12:08 AM, Martin Makundi < martin.maku...@koodaripalvelut.com> wrote: > >> We will provide a patch if possible. However, we might need some help > >> onto our endevor. > > > > If it's not possible, why would you expect someone else to do it? > > Step up and make it happen! Avoid the misunderstandings, show what it > should do! > > > > If you are demonstrating progress on something that benefits the > community, > > I'm sure the help you find you need will materialize along the way. > > "We will be back with a patch" ;) > Please make sure that it passes all current test cases before submitting the patch. Also, it would be good to take the examples that have been given to you in this thread and create tests from them that demonstrate that they all work. Particularly important will be demonstrating the security example that Igor gave above. I'm telling you all this in advance, not to be mean, but to help you out. In this one thread, you've pulled out more responses from PMC members and committers than any thread in recent memory - and all of them agreed that it was a bad idea, and not likely to be implemented. So, if you submit a patch, it needs to meet all the above criteria to prove us all wrong. I'd rather tell you that up front than have you submit a half-working patch and then get shot down in a blaze of glory. :) -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Free wicket from component hierarchy hell
Hi! > Please make sure that it passes all current test cases before submitting the > patch. Also, it would be good to take the examples that have been given to > you in this thread and create tests from them that demonstrate that they all > work. Particularly important will be demonstrating the security example > that Igor gave above. The security example is quite extreme and should be implemented in traditional way if there is no regression test for it. > I'm telling you all this in advance, not to be mean, but to help you out. > In this one thread, you've pulled out more responses from PMC members and > committers than any thread in recent memory - and all of them agreed that it > was a bad idea, and not likely to be implemented. So, if you submit a > patch, it needs to meet all the above criteria to prove us all wrong. I'd > rather tell you that up front than have you submit a half-working patch and > then get shot down in a blaze of glory. :) I am planning to take more of a "helper method" approach that is not so invasive: HierarchyUtils.helpMeAddThisComponentToItsParent(panel, component); ** Martin > > -- > 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 Fri, Nov 5, 2010 at 11:32 PM, Martin Makundi wrote: > Hi! > >> Please make sure that it passes all current test cases before submitting the >> patch. Also, it would be good to take the examples that have been given to >> you in this thread and create tests from them that demonstrate that they all >> work. Particularly important will be demonstrating the security example >> that Igor gave above. > > The security example is quite extreme and should be implemented in > traditional way if there is no regression test for it. there is nothing extreme about it, it is a common use of containers when implementing visibility/security. just the fact that this "forces" the traditional approach sounds scarry. -igor > >> I'm telling you all this in advance, not to be mean, but to help you out. >> In this one thread, you've pulled out more responses from PMC members and >> committers than any thread in recent memory - and all of them agreed that it >> was a bad idea, and not likely to be implemented. So, if you submit a >> patch, it needs to meet all the above criteria to prove us all wrong. I'd >> rather tell you that up front than have you submit a half-working patch and >> then get shot down in a blaze of glory. :) > > I am planning to take more of a "helper method" approach that is not > so invasive: > > HierarchyUtils.helpMeAddThisComponentToItsParent(panel, component); > > ** > Martin > >> >> -- >> 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
>> The security example is quite extreme and should be implemented in >> traditional way if there is no regression test for it. > > there is nothing extreme about it, it is a common use of containers > when implementing visibility/security. just the fact that this > "forces" the traditional approach sounds scarry. I'm not scared that easily. Private members have a place and purpose. ** Martin > > -igor > - 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 Sat, Nov 6, 2010 at 2:57 AM, Martin Makundi wrote: > > I'm not scared that easily. Private members have a place and purpose. > Yes, please don't make us have to expose our private parts. - 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'm not scared that easily. Private members have a place and purpose.
> Yes, please don't make us have to expose our private parts.
;) Here's a first attempt with few TODOs, however:
### Eclipse Workspace Patch 1.0
Index: src/main/java/org/apache/wicket/MarkupContainer.java
===
RCS file: /src/main/java/org/apache/wicket/MarkupContainer.java,v
retrieving revision 1.1
diff -u -r1.1 MarkupContainer.java
--- src/main/java/org/apache/wicket/MarkupContainer.java6 Nov 2010
12:17:36 - 1.1
+++ src/main/java/org/apache/wicket/MarkupContainer.java6 Nov 2010
12:18:00 -
@@ -20,8 +20,11 @@
import java.util.ArrayList;
import java.util.Collections;
import java.util.Comparator;
+import java.util.HashMap;
import java.util.Iterator;
+import java.util.LinkedList;
import java.util.List;
+import java.util.Map;
import org.apache.wicket.markup.ComponentTag;
import org.apache.wicket.markup.MarkupElement;
@@ -112,7 +115,7 @@
{
super(id, model);
}
-
+
/**
* Adds a child component to this container.
*
@@ -1723,6 +1726,25 @@
}
return result;
}
+
+ private Map componentIdMapAidedComponent = new
HashMap();
+
+ public final MarkupContainer addWithAid(final Component... childs)
+ {
+for (Component child : childs)
+{
+ Component duplicateChild =
componentIdMapAidedComponent.put(child.getId(), child);
+
+ if (duplicateChild != null)
+ {
+// Fail-fast
+throw new IllegalArgumentException(exceptionMessage("A child
with id '" +
+child.getId() + "' already exists"));
+ }
+}
+
+return this;
+ }
/**
*
@@ -1732,6 +1754,25 @@
void onBeforeRenderChildren()
{
super.onBeforeRenderChildren();
+
+{
+ // Add also aided children to their right place; all should now
exist in the map
+ for (Component child : new
LinkedList(componentIdMapAidedComponent.values() /** remove
items from componentIdMapAidedComponent as soon as they are matched
*/))
+ {
+/*
+ * TODO Parse markup, find each component's real parent and add it onto
+ * its real parent
+ *
+ * TODO MarkupVisitor must not visit child markup when they have their
+ * own (maybe it's not even possible by default).
+ *
+ * TODO Throw exception if child id is matched multiple times.
+ */
+
+// Finally remove aided component from map
+componentIdMapAidedComponent.remove(child.getId());
+ }
+}
// We need to copy the children list because the children components can
// modify the hierarchy in their onBeforeRender.
**
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 Sat, Nov 6, 2010 at 7:20 AM, Martin Makundi <
martin.maku...@koodaripalvelut.com> wrote:
> Hi!
>
> >> I'm not scared that easily. Private members have a place and purpose.
> > Yes, please don't make us have to expose our private parts.
>
> ;) Here's a first attempt with few TODOs, however:
>
All right, let's take a look.
> }
> +
> + private Map componentIdMapAidedComponent = new
> HashMap();
>
So, you just added a new Map to all markup containers that keeps components
in it? Why would you do that? We already have a storage mechanism for
children of a markup container. And, it takes less memory space than a
Map. Why do we need two storage containers for children? Why can't you
call add(foo) and get("fooID")?
+{
> + // Add also aided children to their right place; all should now
> exist in the map
> + for (Component child : new
> LinkedList(componentIdMapAidedComponent.values() /** remove
> items from componentIdMapAidedComponent as soon as they are matched
> */))
> + {
> +/*
> + * TODO Parse markup, find each component's real parent and add it
> onto
> + * its real parent
> + *
> + * TODO MarkupVisitor must not visit child markup when they have
> their
> + * own (maybe it's not even possible by default).
> + *
> + * TODO Throw exception if child id is matched multiple times.
> + */
> +
>
Oh, so all that's left is to do all the real work? :)
> +// Finally remove aided component from map
> +componentIdMapAidedComponent.remove(child.getId());
> + }
> +}
>
Like I mentioned in my previous response on this thread - you need to come
to us with everything you've got. It needs to show us:
- a real working solution
- something that doesn't break existing stuff (real world apps, and
passes all existing test cases)
- test cases for itself and all new functionality
- proof that it doesn't allow the designers to easily break security
(like Igor's example)
I'm not trying to be difficult. I'm simply saying that you have an uphill
battle ahead of you. Many core committers have already told you that the
idea isn't real good. Then you come with a "patch" that simply adds a
bloated second place to store children in all markup containers? That's not
helping your case.
If you can truly present an elegant solution that solves all of the above,
we can consider it. But don't bring us noise that is laughably incomplete.
Like Brian said, make a branch (you can fork the git mirror to make this
easier) and start some development. This is not something that will be done
in an hour. You're going to have to sink some time into it. Do yourself
the favor of really working through the solution wholeheartedly.
--
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Free wicket from component hierarchy hell
Hi!
>> + private Map componentIdMapAidedComponent = new
>> HashMap();
>
> So, you just added a new Map to all markup containers that keeps components
> in it? Why would you do that?
We need to wait until all components are added so that we can arrange
them into correct hireracy before rendering.
> We already have a storage mechanism for children of a markup container.
> Why do we need two storage containers for children? Why can't you
> call add(foo) and get("fooID")?
If there is an existing way to accomplish the temporary caching of
"components to be added", that mechanism can be used.
Another way to go about this would be to arrange children immediately
whenever addWithAid(component) is called so that they would be in
correct order when render is due.
> Oh, so all that's left is to do all the real work? :)
True :)
> Like I mentioned in my previous response on this thread - you need to come
> to us with everything you've got. It needs to show us:
>
> - a real working solution
> - something that doesn't break existing stuff (real world apps, and
> passes all existing test cases)
> - test cases for itself and all new functionality
> - proof that it doesn't allow the designers to easily break security
> (like Igor's example)
It's gonna take more than 5 min which I spent with the above. I take
in the feedback and work on it.
> Then you come with a "patch" that simply adds a bloated second place
> to store children in all markup containers? That's not helping your case.
As I said before, I would need help form wicket internals to
efficiently leverage the existing mechanics.
> If you can truly present an elegant solution that solves all of the above,
> we can consider it. Do yourself the favor of really working through the
> solution wholeheartedly.
We'll do that and keep posting for intermediate feedback ;)
**
Martin
>
> --
> 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
> We need to wait until all components are added so that we can arrange
them into correct hireracy before rendering.
May I suggest that components are added with help of a builder object, for
example:
public MyPanel(String id) {
super(id);
Builder b = new Builder(this); // the Builder gets reference to this MyPanel
b.add(new TextField("name")); // can be child of "form" which is added later
b.add(new SomeForm("form"));
b.build(); // after this line this MyPanel contains the components name and form
}
If MyPanel's super class needs to access the same builder, it can provide a
constructor for it. In that case b.build() should be only invoked in MyPanel's
constructor.
If a developer uses more than one builder in a constructor, he can restrict
moving of components in markup to some extent:
public MyPanel(String id) {
super(id);
Builder b1 = new Builder(this);
b1.add(new TextField("name")); // in markup, "name" can't be put under "form"
because it's in a different builder
b1.build();
Builder b2 = new Builder(this);
b2.add(new SomeForm("form");
b2.build();
}
Of course this doesn't solve the problem Igor mentioned. For that you'd need
the "old-fashioned way":
public MyPanel(String id) {
super(id);
SomeForm form = new SomeForm("form");
form.add(new TextField("name"); // in markup, "name" can't be moved out from
"form"
add(form);
}
Developers would need to mix different approaches for building hierarchies if
security is an issue. On second thought, I should use a broader term than
security because there is more than one reason to restrict those pesky
designers ;)
-
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
here is a proper very rough initial implementation:
https://github.com/ivaynberg/wicket/commit/cbe861f4028120993f5d10d575f12c4ca291fdce
now someone has to mature it to the point where it can be properly evaluated.
-igor
On Sat, Nov 6, 2010 at 6:54 AM, samket wrote:
>> We need to wait until all components are added so that we can arrange
> them into correct hireracy before rendering.
>
> May I suggest that components are added with help of a builder object, for
> example:
>
> public MyPanel(String id) {
> super(id);
> Builder b = new Builder(this); // the Builder gets reference to this MyPanel
> b.add(new TextField("name")); // can be child of "form" which is added later
> b.add(new SomeForm("form"));
> b.build(); // after this line this MyPanel contains the components name and
> form
> }
>
> If MyPanel's super class needs to access the same builder, it can provide a
> constructor for it. In that case b.build() should be only invoked in
> MyPanel's constructor.
>
> If a developer uses more than one builder in a constructor, he can restrict
> moving of components in markup to some extent:
>
> public MyPanel(String id) {
> super(id);
> Builder b1 = new Builder(this);
> b1.add(new TextField("name")); // in markup, "name" can't be put under "form"
> because it's in a different builder
> b1.build();
> Builder b2 = new Builder(this);
> b2.add(new SomeForm("form");
> b2.build();
> }
>
> Of course this doesn't solve the problem Igor mentioned. For that you'd need
> the "old-fashioned way":
>
> public MyPanel(String id) {
> super(id);
> SomeForm form = new SomeForm("form");
> form.add(new TextField("name"); // in markup, "name" can't be moved out from
> "form"
> add(form);
> }
>
> Developers would need to mix different approaches for building hierarchies if
> security is an issue. On second thought, I should use a broader term than
> security because there is more than one reason to restrict those pesky
> designers ;)
>
> -
> 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 sorry to say, but the whole discussion makes little sense to me and
these attempts to fix something that is not broken actually scares me a bit.
As far as I understand the philosophy of Wicket it is a Java centric and
Java code drive web application framework. This makes it very unique to
all other approaches I've seen so far.
The component hierarchy defined in the code means more than just to
layout the components right for the markup. It for example also defines
the visibility hierarchy which is important for security and usability,
and defines the update hierarchy when doing component refreshs via AJAX.
It simply is not right to allow the designer to move around components
at will which are cascaded in the code with good functional reasons.
So what I want to say is, the hierarchy defined in the markup only
represents one aspect of the hierarchy defined in the code and as such
is NOT a good source to build the runtime component hierarchy on. Also I
would not like to have a "traditional way" and another way to define
hierarchies in Wicket as this will only cause confusion. I prefer the
Python philosphy "there should be one — and only one — obvious way to do
something".
Regards,
Seb
On 07.11.2010 00:45, Igor Vaynberg wrote:
here is a proper very rough initial implementation:
https://github.com/ivaynberg/wicket/commit/cbe861f4028120993f5d10d575f12c4ca291fdce
now someone has to mature it to the point where it can be properly evaluated.
-igor
On Sat, Nov 6, 2010 at 6:54 AM, samket wrote:
We need to wait until all components are added so that we can arrange
them into correct hireracy before rendering.
May I suggest that components are added with help of a builder object, for
example:
public MyPanel(String id) {
super(id);
Builder b = new Builder(this); // the Builder gets reference to this MyPanel
b.add(new TextField("name")); // can be child of "form" which is added later
b.add(new SomeForm("form"));
b.build(); // after this line this MyPanel contains the components name and form
}
If MyPanel's super class needs to access the same builder, it can provide a
constructor for it. In that case b.build() should be only invoked in MyPanel's
constructor.
If a developer uses more than one builder in a constructor, he can restrict
moving of components in markup to some extent:
public MyPanel(String id) {
super(id);
Builder b1 = new Builder(this);
b1.add(new TextField("name")); // in markup, "name" can't be put under "form"
because it's in a different builder
b1.build();
Builder b2 = new Builder(this);
b2.add(new SomeForm("form");
b2.build();
}
Of course this doesn't solve the problem Igor mentioned. For that you'd need the
"old-fashioned way":
public MyPanel(String id) {
super(id);
SomeForm form = new SomeForm("form");
form.add(new TextField("name"); // in markup, "name" can't be moved out from
"form"
add(form);
}
Developers would need to mix different approaches for building hierarchies if
security is an issue. On second thought, I should use a broader term than
security because there is more than one reason to restrict those pesky
designers ;)
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
> I'm sorry to say, but the whole discussion makes little sense to me and > these attempts to fix something that is not broken actually scares me a bit. +1 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
it is not about fixing something that isnt broken, its about making it easier. anyways, i just updated the readme in my experimental branch that explains the solution a bit more: https://github.com/ivaynberg/wicket/tree/component-queuing -igor On Mon, Nov 8, 2010 at 8:23 AM, Vitaly Tsaplin wrote: >> I'm sorry to say, but the whole discussion makes little sense to me and >> these attempts to fix something that is not broken actually scares me a bit. > > +1 > > - > 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 sorry to say, but the whole discussion makes little sense to me and >> these attempts to fix something that is not broken actually scares me a bit. > > +1 It's maybe not broken for you. For me it's like dabbling in a swamp (http://kuvablogi.com/nayta/prev/img1483294.jpg, http://www.lansi-savo.fi/Urheilu/9349269.jpg, http://www.suopotkupallo.fi/). 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. ** 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
My only hope is that the solution you end up with will not make us running some sort of script against all the sorces we have. On Mon, Nov 8, 2010 at 7:30 PM, Martin Makundi wrote: >>> I'm sorry to say, but the whole discussion makes little sense to me and >>> these attempts to fix something that is not broken actually scares me a bit. >> >> +1 > > It's maybe not broken for you. For me it's like dabbling in a swamp > (http://kuvablogi.com/nayta/prev/img1483294.jpg, > http://www.lansi-savo.fi/Urheilu/9349269.jpg, > http://www.suopotkupallo.fi/). > > 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. > > ** > 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
wtf, srsly? -igor On Mon, Nov 8, 2010 at 8:30 AM, Martin Makundi wrote: >>> I'm sorry to say, but the whole discussion makes little sense to me and >>> these attempts to fix something that is not broken actually scares me a bit. >> >> +1 > > It's maybe not broken for you. For me it's like dabbling in a swamp > (http://kuvablogi.com/nayta/prev/img1483294.jpg, > http://www.lansi-savo.fi/Urheilu/9349269.jpg, > http://www.suopotkupallo.fi/). > > 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. > > ** > 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
> My only hope is that the solution you end up with will not make us > running some sort of script against all the sorces we have. We ended up with the requirement that it should 100% compatible with existing code and tests. ** 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
Vigor, as I understand the readme the queue method basically has only a slightly different behavior compared to the add method in the way that it either adds a component as a direct child to the parent or as a sub-child as defined in the markup. So the markup is only used to determine the child's location below a given (code controlled) parent. This means if you replace the current add method with the behavior of the queue method, existing code will still work and we would not have two separate ways to add components. That sounds like a good solution. @Martin: please start arguing with the given arguments and stop moaning. Thanks. Regards, Seb On 08.11.2010 17:28, Igor Vaynberg wrote: it is not about fixing something that isnt broken, its about making it easier. anyways, i just updated the readme in my experimental branch that explains the solution a bit more: https://github.com/ivaynberg/wicket/tree/component-queuing -igor On Mon, Nov 8, 2010 at 8:23 AM, Vitaly Tsaplin wrote: I'm sorry to say, but the whole discussion makes little sense to me and these attempts to fix something that is not broken actually scares me a bit. +1 - 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
> as I understand the readme the queue method basically has only a slightly > different behavior compared to the add method in the way that it either adds > a component as a direct child to the parent or as a sub-child as defined in > the markup. So the markup is only used to determine the child's location > below a given (code controlled) parent. This means if you replace the > current add method with the behavior of the queue method, existing code will > still work and we would not have two separate ways to add components. That > sounds like a good solution. > > @Martin: please start arguing with the given arguments and stop moaning. > Thanks. I would argue that it is not completely safe to _replace_ add method with queue method. As Igor pointed out before, we might want to define security boundaries: componentA must be inside componentB. Such code should be implemented either traditionally or otherwise the new way of adding components via queue must implement a security feature that allows restricting child components inside a certain parent component in a fluid but robust manner. Plain queue implementation, however, is a very good starting point to begin studying various ways of imposing security boundaries. ** Martin > > On 08.11.2010 17:28, Igor Vaynberg wrote: >> >> it is not about fixing something that isnt broken, its about making it >> easier. anyways, i just updated the readme in my experimental branch >> that explains the solution a bit more: >> https://github.com/ivaynberg/wicket/tree/component-queuing >> >> -igor >> >> On Mon, Nov 8, 2010 at 8:23 AM, Vitaly Tsaplin >> wrote: I'm sorry to say, but the whole discussion makes little sense to me and these attempts to fix something that is not broken actually scares me a bit. >>> >>> +1 >>> >>> - >>> 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 Mon, Nov 8, 2010 at 8:51 AM, Sebastian wrote: > Vigor, > > as I understand the readme the queue method basically has only a slightly > different behavior compared to the add method in the way that it either adds > a component as a direct child to the parent or as a sub-child as defined in > the markup. So the markup is only used to determine the child's location > below a given (code controlled) parent. This means if you replace the > current add method with the behavior of the queue method, existing code will > still work and we would not have two separate ways to add components. That > sounds like a good solution. hrm. i was thinking to have queue() in addition to add(). i havent looked into it enough to be able to say that we can replace add() with queue() completely and not lose anything. if, however, that is the case, then i would prefer tweaking add() itself to work like queue(). -igor > > @Martin: please start arguing with the given arguments and stop moaning. > Thanks. > > Regards, > Seb > > On 08.11.2010 17:28, Igor Vaynberg wrote: >> >> it is not about fixing something that isnt broken, its about making it >> easier. anyways, i just updated the readme in my experimental branch >> that explains the solution a bit more: >> https://github.com/ivaynberg/wicket/tree/component-queuing >> >> -igor >> >> On Mon, Nov 8, 2010 at 8:23 AM, Vitaly Tsaplin >> wrote: I'm sorry to say, but the whole discussion makes little sense to me and these attempts to fix something that is not broken actually scares me a bit. >>> >>> +1 >>> >>> - >>> 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 Mon, Nov 8, 2010 at 8:58 AM, Martin Makundi wrote: >> as I understand the readme the queue method basically has only a slightly >> different behavior compared to the add method in the way that it either adds >> a component as a direct child to the parent or as a sub-child as defined in >> the markup. So the markup is only used to determine the child's location >> below a given (code controlled) parent. This means if you replace the >> current add method with the behavior of the queue method, existing code will >> still work and we would not have two separate ways to add components. That >> sounds like a good solution. >> >> @Martin: please start arguing with the given arguments and stop moaning. >> Thanks. > > I would argue that it is not completely safe to _replace_ add method > with queue method. As Igor pointed out before, we might want to define > security boundaries: componentA must be inside componentB. Such code > should be implemented either traditionally or otherwise the new way of > adding components via queue must implement a security feature that > allows restricting child components inside a certain parent component > in a fluid but robust manner. thats exactly what it does, as my readme file explains in the git branch... -igor > > Plain queue implementation, however, is a very good starting point to > begin studying various ways of imposing security boundaries. > > ** > Martin >> >> On 08.11.2010 17:28, Igor Vaynberg wrote: >>> >>> it is not about fixing something that isnt broken, its about making it >>> easier. anyways, i just updated the readme in my experimental branch >>> that explains the solution a bit more: >>> https://github.com/ivaynberg/wicket/tree/component-queuing >>> >>> -igor >>> >>> On Mon, Nov 8, 2010 at 8:23 AM, Vitaly Tsaplin >>> wrote: > > I'm sorry to say, but the whole discussion makes little sense to me and > these attempts to fix something that is not broken actually scares me a > bit. +1 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
...and that makes the queue method a candidate to replace the add method without breaking anything. Regards, Seb On 08.11.2010 18:03, Igor Vaynberg wrote: On Mon, Nov 8, 2010 at 8:58 AM, Martin Makundi wrote: as I understand the readme the queue method basically has only a slightly different behavior compared to the add method in the way that it either adds a component as a direct child to the parent or as a sub-child as defined in the markup. So the markup is only used to determine the child's location below a given (code controlled) parent. This means if you replace the current add method with the behavior of the queue method, existing code will still work and we would not have two separate ways to add components. That sounds like a good solution. @Martin: please start arguing with the given arguments and stop moaning. Thanks. I would argue that it is not completely safe to _replace_ add method with queue method. As Igor pointed out before, we might want to define security boundaries: componentA must be inside componentB. Such code should be implemented either traditionally or otherwise the new way of adding components via queue must implement a security feature that allows restricting child components inside a certain parent component in a fluid but robust manner. thats exactly what it does, as my readme file explains in the git branch... -igor Plain queue implementation, however, is a very good starting point to begin studying various ways of imposing security boundaries. ** Martin On 08.11.2010 17:28, Igor Vaynberg wrote: it is not about fixing something that isnt broken, its about making it easier. anyways, i just updated the readme in my experimental branch that explains the solution a bit more: https://github.com/ivaynberg/wicket/tree/component-queuing -igor On Mon, Nov 8, 2010 at 8:23 AM, Vitaly Tsaplin wrote: I'm sorry to say, but the whole discussion makes little sense to me and these attempts to fix something that is not broken actually scares me a bit. +1 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
> ...and that makes the queue method a candidate to replace the add method > without breaking anything. Yes :) ** Martin > > > Seb > > On 08.11.2010 18:03, Igor Vaynberg wrote: >> >> On Mon, Nov 8, 2010 at 8:58 AM, Martin Makundi >> wrote: as I understand the readme the queue method basically has only a slightly different behavior compared to the add method in the way that it either adds a component as a direct child to the parent or as a sub-child as defined in the markup. So the markup is only used to determine the child's location below a given (code controlled) parent. This means if you replace the current add method with the behavior of the queue method, existing code will still work and we would not have two separate ways to add components. That sounds like a good solution. @Martin: please start arguing with the given arguments and stop moaning. Thanks. >>> >>> I would argue that it is not completely safe to _replace_ add method >>> with queue method. As Igor pointed out before, we might want to define >>> security boundaries: componentA must be inside componentB. Such code >>> should be implemented either traditionally or otherwise the new way of >>> adding components via queue must implement a security feature that >>> allows restricting child components inside a certain parent component >>> in a fluid but robust manner. >> >> thats exactly what it does, as my readme file explains in the git >> branch... >> >> -igor >> >>> >>> Plain queue implementation, however, is a very good starting point to >>> begin studying various ways of imposing security boundaries. >>> >>> ** >>> Martin On 08.11.2010 17:28, Igor Vaynberg wrote: > > it is not about fixing something that isnt broken, its about making it > easier. anyways, i just updated the readme in my experimental branch > that explains the solution a bit more: > https://github.com/ivaynberg/wicket/tree/component-queuing > > -igor > > On Mon, Nov 8, 2010 at 8:23 AM, Vitaly > Tsaplin > wrote: >>> >>> I'm sorry to say, but the whole discussion makes little sense to me >>> and >>> these attempts to fix something that is not broken actually scares me >>> a >>> bit. >> >> +1 >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
Hi, I think this approach of changing .add or adding a .queue is too radical while the purpose can be achieved in a much simpler way. I think hierarchy of Java code among other things helps considerably with code-readability and should be kept in pace, but also it's strictness sometimes makes one have to change the code for trivial markup change/requirement which is inconvenient. So I suggest instead of tampering with code hierarchy, let markup override it with some special format in wicket:id - for example both these markups can work with the same java code: (edit) (wicket:id=":edit:name" means relative path "edit:name" from the panel that owns the markup) We just check for colon at markup id, resolve the component by relative path, determine it's visibility & enabled-ness the traditional way and render it. For ajax, I guess when rendering components we can check if it has children that have been rendered outside itself, if the child has outputMarkupId enabled just render that too, if not print a warn message that the markup designer has made a mistake there. What do you think? Does this do what you want? Is there something I overlooked? Omid On Mon, Nov 8, 2010 at 8:28 PM, Igor Vaynberg wrote: > On Mon, Nov 8, 2010 at 8:51 AM, Sebastian wrote: >> Vigor, >> >> as I understand the readme the queue method basically has only a slightly >> different behavior compared to the add method in the way that it either adds >> a component as a direct child to the parent or as a sub-child as defined in >> the markup. So the markup is only used to determine the child's location >> below a given (code controlled) parent. This means if you replace the >> current add method with the behavior of the queue method, existing code will >> still work and we would not have two separate ways to add components. That >> sounds like a good solution. > > hrm. i was thinking to have queue() in addition to add(). i havent > looked into it enough to be able to say that we can replace add() with > queue() completely and not lose anything. if, however, that is the > case, then i would prefer tweaking add() itself to work like queue(). > > -igor > > >> >> @Martin: please start arguing with the given arguments and stop moaning. >> Thanks. >> >> Regards, >> Seb >> >> On 08.11.2010 17:28, Igor Vaynberg wrote: >>> >>> it is not about fixing something that isnt broken, its about making it >>> easier. anyways, i just updated the readme in my experimental branch >>> that explains the solution a bit more: >>> https://github.com/ivaynberg/wicket/tree/component-queuing >>> >>> -igor >>> >>> On Mon, Nov 8, 2010 at 8:23 AM, Vitaly Tsaplin >>> wrote: > > I'm sorry to say, but the whole discussion makes little sense to me and > these attempts to fix something that is not broken actually scares me a > bit. +1 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
On Mon, Nov 8, 2010 at 9:07 AM, Sebastian wrote: > ...and that makes the queue method a candidate to replace the add method > without breaking anything. not necessarily. while add() adds right away, queue holds componets in a buffer until after the oninitialize() cascade. so calling getparent() or walking the hieararchy cannot be done until after oninitialize() has been called on the parent container. this gives you no way to traverse and tweak the child hiearachy. i might move the code so it creates the hierarchy just before the parent's oninitialize(), post seemed safer at first glance. -igor > > Regards, > > Seb > > On 08.11.2010 18:03, Igor Vaynberg wrote: >> >> On Mon, Nov 8, 2010 at 8:58 AM, Martin Makundi >> wrote: as I understand the readme the queue method basically has only a slightly different behavior compared to the add method in the way that it either adds a component as a direct child to the parent or as a sub-child as defined in the markup. So the markup is only used to determine the child's location below a given (code controlled) parent. This means if you replace the current add method with the behavior of the queue method, existing code will still work and we would not have two separate ways to add components. That sounds like a good solution. @Martin: please start arguing with the given arguments and stop moaning. Thanks. >>> >>> I would argue that it is not completely safe to _replace_ add method >>> with queue method. As Igor pointed out before, we might want to define >>> security boundaries: componentA must be inside componentB. Such code >>> should be implemented either traditionally or otherwise the new way of >>> adding components via queue must implement a security feature that >>> allows restricting child components inside a certain parent component >>> in a fluid but robust manner. >> >> thats exactly what it does, as my readme file explains in the git >> branch... >> >> -igor >> >>> >>> Plain queue implementation, however, is a very good starting point to >>> begin studying various ways of imposing security boundaries. >>> >>> ** >>> Martin On 08.11.2010 17:28, Igor Vaynberg wrote: > > it is not about fixing something that isnt broken, its about making it > easier. anyways, i just updated the readme in my experimental branch > that explains the solution a bit more: > https://github.com/ivaynberg/wicket/tree/component-queuing > > -igor > > On Mon, Nov 8, 2010 at 8:23 AM, Vitaly > Tsaplin > wrote: >>> >>> I'm sorry to say, but the whole discussion makes little sense to me >>> and >>> these attempts to fix something that is not broken actually scares me >>> a >>> bit. >> >> +1 >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Free wicket from component hierarchy hell
It makes more sense to be before. I think the component hierarchy should be ready for onInitialize() On Mon, 2010-11-08 at 09:32 -0800, Igor Vaynberg wrote: > On Mon, Nov 8, 2010 at 9:07 AM, Sebastian wrote: > > ...and that makes the queue method a candidate to replace the add method > > without breaking anything. > > not necessarily. while add() adds right away, queue holds componets in > a buffer until after the oninitialize() cascade. so calling > getparent() or walking the hieararchy cannot be done until after > oninitialize() has been called on the parent container. this gives you > no way to traverse and tweak the child hiearachy. > > i might move the code so it creates the hierarchy just before the > parent's oninitialize(), post seemed safer at first glance. > > > -igor > > > > > Regards, > > > > Seb > > > > On 08.11.2010 18:03, Igor Vaynberg wrote: > >> > >> On Mon, Nov 8, 2010 at 8:58 AM, Martin Makundi > >> wrote: > > as I understand the readme the queue method basically has only a > slightly > different behavior compared to the add method in the way that it either > adds > a component as a direct child to the parent or as a sub-child as defined > in > the markup. So the markup is only used to determine the child's location > below a given (code controlled) parent. This means if you replace the > current add method with the behavior of the queue method, existing code > will > still work and we would not have two separate ways to add components. > That > sounds like a good solution. > > @Martin: please start arguing with the given arguments and stop moaning. > Thanks. > >>> > >>> I would argue that it is not completely safe to _replace_ add method > >>> with queue method. As Igor pointed out before, we might want to define > >>> security boundaries: componentA must be inside componentB. Such code > >>> should be implemented either traditionally or otherwise the new way of > >>> adding components via queue must implement a security feature that > >>> allows restricting child components inside a certain parent component > >>> in a fluid but robust manner. > >> > >> thats exactly what it does, as my readme file explains in the git > >> branch... > >> > >> -igor > >> > >>> > >>> Plain queue implementation, however, is a very good starting point to > >>> begin studying various ways of imposing security boundaries. > >>> > >>> ** > >>> Martin > > On 08.11.2010 17:28, Igor Vaynberg wrote: > > > > it is not about fixing something that isnt broken, its about making it > > easier. anyways, i just updated the readme in my experimental branch > > that explains the solution a bit more: > > https://github.com/ivaynberg/wicket/tree/component-queuing > > > > -igor > > > > On Mon, Nov 8, 2010 at 8:23 AM, Vitaly > > Tsaplin > > wrote: > >>> > >>> I'm sorry to say, but the whole discussion makes little sense to me > >>> and > >>> these attempts to fix something that is not broken actually scares me > >>> a > >>> bit. > >> > >> +1 > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> For additional commands, e-mail: users-h...@wicket.apache.org > >> > >> > > > > - > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > > >>> > >>> - > >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >>> For additional commands, e-mail: users-h...@wicket.apache.org > >>> > >>> > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> For additional commands, e-mail: users-h...@wicket.apache.org > >> > >> > > > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org >
Re: Free wicket from component hierarchy hell
> 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
Re: Free wicket from component hierarchy hell
Chicken. 2010/11/9 Eelco Hillenius : >> 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
Re: Free wicket from component hierarchy hell
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 : > Chicken. > > 2010/11/9 Eelco Hillenius : >>> 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
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 ? 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 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 : > > Chicken. > > > > 2010/11/9 Eelco Hillenius : > >>> 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 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 : >> > Chicken. >> > >> > 2010/11/9 Eelco Hillenius : >> >>> 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 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 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" wrote: > Well then, why don't you have your base panel provide methods that > generate the individual components, with methods that implement > composite behaviors involving groups of components. > > Your constructor can call the component-creation methods to assemble > the component hierarchy to match the HTML. > > Then, when you want a panel with a different hierarchy you subclass > the panel, override the constructor to create the 2nd component > hierarchy, and provide the new panel its own HTML page. > > If you don't like overriding the constructor along with the HTML, then > you can build some sort of configurable constructor-constructor. > > /Frank > > -Original Message- > From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com] > Sent: Tuesday, November 09, 2010 6:55 AM > To: users@wicket.apache.org > Subject: Re: Free wicket from component hierarchy hell > > Hi! > > > Isn't this exactly the reason we've got CSS? > > It's just the buzz, not the reality. Unfortunately often CSS "doesn't > quite cut it: > * http://blog.iconara.net/2007/09/21/the-failure-of-css/ > > > HTML shouldn't really be used for look&feel and the size and > > placement > of > > components can perfectly be defined using CSS classes. > > In CSS the actual nesting of components plays a big role (div inside > float inside abs top 0px ul relative etc.). > > If you want a professional finish, you will often need to pull > components around the layers for different display. Even trying to > pull one component will break wicket in strict hierarchy mode. > > ** > Martin > > > > > Matt > > > > On 2010-11-09 13:34, Martin Makundi wrote: > >> > >> Also making skins for different devices / screen sizes becomes > easier. > >> > >> ** > >> Martin > >> > >> 2010/11/9 Vitaly Tsaplin: > >>>> > >>>> In simple cases it makes no difference. It makes real difference > with > >>>> some complex widgets (for example search components) that must be > >>>> reused on many pages and they should render differently on each > page > >>>> depending on how much space and what context they are in. I don't > like > >>>> duplicating code even if it is gui code. > >>> > >>> 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 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 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 : >> 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 look&feel and the size and placement of > components can perfectly be defined using CSS classes. In CSS the actual nesting of components plays a big role (div inside float inside abs top 0px ul relative etc.). If you want a professional finish, you will often need to pull components around the layers for different display. Even trying to pull one component will break wicket in strict hierarchy mode. ** Martin > > Matt > > On 2010-11-09 13:34, Martin Makundi wrote: >> >> Also making skins for different devices / screen sizes becomes easier. >> >> ** >> Martin >> >> 2010/11/9 Vitaly Tsaplin: In simple cases it makes no difference. It makes real difference with some complex widgets (for example search components) that must be reused on many pages and they should render differently on each page depending on how much space and what context they are in. I don't like duplicating code even if it is gui code. >>> >>> 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 > wrote: > >> Hi Martin >> >> Isn't this exactly the reason we've got CSS? >> HTML shouldn't really be used for look&feel 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 Tsaplin: >>> In simple cases it makes no difference. It makes real difference with > some complex widgets (for example search components) that must be > reused on many pages and they should render differently on each page > depending on how much space and what context they are in. I don't like > duplicating code even if it is gui code. > 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 look&feel and the size and placement of > components can perfectly be defined using CSS classes. In CSS the actual nesting of components plays a big role (div inside float inside abs top 0px ul relative etc.). If you want a professional finish, you will often need to pull components around the layers for different display. Even trying to pull one component will break wicket in strict hierarchy mode. ** Martin > > Matt > > On 2010-11-09 13:34, Martin Makundi wrote: >> >> Also making skins for different devices / screen sizes becomes easier. >> >> ** >> Martin >> >> 2010/11/9 Vitaly Tsaplin: >>>> >>>> In simple cases it makes no difference. It makes real difference with >>>> some complex widgets (for example search components) that must be >>>> reused on many pages and they should render differently on each page >>>> depending on how much space and what context they are in. I don't like >>>> duplicating code even if it is gui code. >>> >>> 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 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 wrote: > Hi Martin > > Isn't this exactly the reason we've got CSS? > HTML shouldn't really be used for look&feel 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 Tsaplin: >> >>> In simple cases it makes no difference. It makes real difference with some complex widgets (for example search components) that must be reused on many pages and they should render differently on each page depending on how much space and what context they are in. I don't like duplicating code even if it is gui code. >>> 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 look&feel 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 Tsaplin: In simple cases it makes no difference. It makes real difference with some complex widgets (for example search components) that must be reused on many pages and they should render differently on each page depending on how much space and what context they are in. I don't like duplicating code even if it is gui code. 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 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 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 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 : >> > Chicken. >> > >> > 2010/11/9 Eelco Hillenius : >> >>> 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 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:
>
>
>
>
>
>
>
> 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 :
> > 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 :
> >>
> >> 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 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 look&feel and the size and placement > of >> components can perfectly be defined using CSS classes. > > In CSS the actual nesting of components plays a big role (div inside > float inside abs top 0px ul relative etc.). > > If you want a professional finish, you will often need to pull > components around the layers for different display. Even trying to > pull one component will break wicket in strict hierarchy mode. > > ** > Martin > >> >> Matt >> >> On 2010-11-09 13:34, Martin Makundi wrote: >>> >>> Also making skins for different devices / screen sizes becomes > easier. >>> >>> ** >>> Martin >>> >>> 2010/11/9 Vitaly Tsaplin: >>>>> >>>>> In simple cases it makes no difference. It makes real difference > with >>>>> some complex widgets (for example search components) that must be >>>>> reused on many pages and they should render differently on each > page >>>>> depending on how much space and what context they are in. I don't > like >>>>> duplicating code even if it is gui code. >>>> >>>> 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 wrote: > Well then, why don't you have your base panel provide methods that > generate the individual components, with methods that implement > composite behaviors involving groups of components. > > Your constructor can call the component-creation methods to assemble the > component hierarchy to match the HTML. > > Then, when you want a panel with a different hierarchy you subclass the > panel, override the constructor to create the 2nd component hierarchy, > and provide the new panel its own HTML page. > > If you don't like overriding the constructor along with the HTML, then > you can build some sort of configurable constructor-constructor. > > /Frank > > -Original Message- > From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com] > Sent: Tuesday, November 09, 2010 6:55 AM > To: users@wicket.apache.org > Subject: Re: Free wicket from component hierarchy hell > > Hi! > > > Isn't this exactly the reason we've got CSS? > > It's just the buzz, not the reality. Unfortunately often CSS "doesn't > quite cut it: > * http://blog.iconara.net/2007/09/21/the-failure-of-css/ > > > HTML shouldn't really be used for look&feel and the size and placement > of > > components can perfectly be defined using CSS classes. > > In CSS the actual nesting of components plays a big role (div inside > float inside abs top 0px ul relative etc.). > > If you want a professional finish, you will often need to pull > components around the layers for different display. Even trying to > pull one component will break wicket in strict hierarchy mode. > > ** > Martin > > > > > Matt > > > > On 2010-11-09 13:34, Martin Makundi wrote: > >> > >> Also making skins for different devices / screen sizes becomes > easier. > >> > >> ** > >> Martin > >> > >> 2010/11/9 Vitaly Tsaplin: > >>>> > >>>> In simple cases it makes no difference. It makes real difference > with > >>>> some complex widgets (for example search components) that must be > >>>> reused on many pages and they should render differently on each > page > >>>> depending on how much space and what context they are in. I don't > like > >>>> duplicating code even if it is gui code. > >>> > >>> 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 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
SV: Free wicket from component hierarchy hell
> That's not how proggress is made... No, but there are dozens of web frameworks, why try to "progress" Wicket into something that works in a way there perhaps already is another framework does? What you propose sounds close to how Tapestry already works, for instance... - Tor Iver - 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
