Re: [VOTE] Nested forms - don't process inner form fields in outer form submit
i would like to see a real world usecase where you would have nested forms but will not want to process the inner when the outer is submitted. -igor On 11/5/06, Matej Knopp <[EMAIL PROTECTED]> wrote: People, people! I just don't get it. By no means I want to generate invalid input. When using nested forms only the toplevel form is generated as . All nested forms are just s in html. The only difference is how the form is processed. If a nested form is submitted, user input in all fields in entire form is persisted, only the submitted form gets really processed. This is IMHO a great feature and allows us to create components that are totally independent, e.g. they don't have to care whether they are put in form or not, they can contain their own form and everything will work as expected. All those remarks about getting against standard are just... well... uninformed. We don't render anything against standard compliance. We don't render things like ... ... -Matej Nick Heudecker wrote: > I'm -1 on allowing nested forms, and +1 on throwing a runtime error if this > condition is encountered. Non-binding. > > On 11/5/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote: >> >> shame on me ... >> >> now serious >> > I think the way we treat nested forms in 2.0 and 1.3 a real >> > improvement and a showcase for component frameworks: work >> > around problems in an elegant and meaningful way. Abstract >> > away the limitations of the protocols we have to work with. >> >> i think this is a big danger - remember: most wicket users come from a >> point >> of GUI building, they dont know the limitations of http, html, css, >> ajax - >> this ends usually up in trouble (security, locked out browsers, >> unusability, >> load, not barrer free...) >> >> my personal way is to always stick to standards - it might be harder >> sometimes to achive this, but youre on a save side... >> >> Regards >> >> Korbinian >> >> > -Ursprüngliche Nachricht- >> > Von: Martijn Dashorst [mailto:[EMAIL PROTECTED] >> > Gesendet: Sonntag, 5. November 2006 22:00 >> > An: wicket-dev@incubator.apache.org >> > Betreff: Re: Re: [VOTE] Nested forms - don't process inner >> > form fields in outer form submit >> > >> > On 11/5/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: >> > > > The vote: don't process inner form fields when the outer form is >> > > > submitted [ ] Yes, don't process those pesky little >> > fields [ ] No, >> > > > process them as if they were part of the outer form >> > > >> > > I'm still not crazy about the whole concept, but I guess >> > nested forms >> > > can be useful sometimes. I just hope we don't open up >> > another can of >> > > worms. >> > >> > Hmmm breakfast. We already allow nested forms, but we >> > don't do anything about it, and these fail horribly at the >> > moment as Korbinian reminds us of constantly. The only other >> > option would be to check the markup and throw a runtime >> > exception that nesting is not allowed. >> > >> > I think the way we treat nested forms in 2.0 and 1.3 a real >> > improvement and a showcase for component frameworks: work >> > around problems in an elegant and meaningful way. Abstract >> > away the limitations of the protocols we have to work with. >> > >> > > My vote: >> > > [ x ] Yes, don't process those pesky little fields >> > > >> > > as that is more explicit/ less magic. >> > >> > Thanks for the vote. >> > >> > Martijn >> > >> > -- >> > > > href="http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote >> > for > > href="http://www.thebeststuffintheworld.com/stuff/wicket";>Wicket >> > at the http://www.thebeststuffintheworld.com/";>Best >> > Stuff in the World! >> > >> >> >
Re: [VOTE] Nested forms - don't process inner form fields in outer form submit
People, people! I just don't get it. By no means I want to generate invalid input. When using nested forms only the toplevel form is generated as . All nested forms are just s in html. The only difference is how the form is processed. If a nested form is submitted, user input in all fields in entire form is persisted, only the submitted form gets really processed. This is IMHO a great feature and allows us to create components that are totally independent, e.g. they don't have to care whether they are put in form or not, they can contain their own form and everything will work as expected. All those remarks about getting against standard are just... well... uninformed. We don't render anything against standard compliance. We don't render things like ... ... -Matej Nick Heudecker wrote: I'm -1 on allowing nested forms, and +1 on throwing a runtime error if this condition is encountered. Non-binding. On 11/5/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote: shame on me ... now serious > I think the way we treat nested forms in 2.0 and 1.3 a real > improvement and a showcase for component frameworks: work > around problems in an elegant and meaningful way. Abstract > away the limitations of the protocols we have to work with. i think this is a big danger - remember: most wicket users come from a point of GUI building, they dont know the limitations of http, html, css, ajax - this ends usually up in trouble (security, locked out browsers, unusability, load, not barrer free...) my personal way is to always stick to standards - it might be harder sometimes to achive this, but youre on a save side... Regards Korbinian > -Ursprüngliche Nachricht- > Von: Martijn Dashorst [mailto:[EMAIL PROTECTED] > Gesendet: Sonntag, 5. November 2006 22:00 > An: wicket-dev@incubator.apache.org > Betreff: Re: Re: [VOTE] Nested forms - don't process inner > form fields in outer form submit > > On 11/5/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > The vote: don't process inner form fields when the outer form is > > > submitted [ ] Yes, don't process those pesky little > fields [ ] No, > > > process them as if they were part of the outer form > > > > I'm still not crazy about the whole concept, but I guess > nested forms > > can be useful sometimes. I just hope we don't open up > another can of > > worms. > > Hmmm breakfast. We already allow nested forms, but we > don't do anything about it, and these fail horribly at the > moment as Korbinian reminds us of constantly. The only other > option would be to check the markup and throw a runtime > exception that nesting is not allowed. > > I think the way we treat nested forms in 2.0 and 1.3 a real > improvement and a showcase for component frameworks: work > around problems in an elegant and meaningful way. Abstract > away the limitations of the protocols we have to work with. > > > My vote: > > [ x ] Yes, don't process those pesky little fields > > > > as that is more explicit/ less magic. > > Thanks for the vote. > > Martijn > > -- > href="http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote > for href="http://www.thebeststuffintheworld.com/stuff/wicket";>Wicket > at the http://www.thebeststuffintheworld.com/";>Best > Stuff in the World! >
Re: License headers
Hi Martijn, There are checkstyle plugins for Eclipse and for IDEA. Don't know about Netbeans. In addition checkstyle is able to check for a header (even as a RE), or check for the presence/absence of any RE. I used checkstyle frequently to enforce a correct copyright header, the presence of an $Id$ tag, presence of javadoc and a lot of code formatting rules. Regards, Erik. Martijn Dashorst schreef: I was going to propose to use checkstyle instead. Problem with checkstyle is that it is not a unit test and doesn't run inside Eclipse, NetBeans or IDEA :-). -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
Re: [VOTE] Nested forms - don't process inner form fields in outer form submit
After following your discussion: [x] Yes, don't process those pesky little fields Dirk
Re: AW: [VOTE] Nested forms - don't process inner form fields in outer form submit
On 11/5/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote: I vote (if im allowed) not to allow nested forms at all as they are not HTML compliant. I *love* a pissing contest :-) I did some research on nesting forms (which is quite interesting though, seaside has had similar discussions), and discovered that in XHTML, nesting forms is valid [1]. The following document validates perfectly: http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> http://www.w3.org/1999/xhtml"; lang="en" xml:lang="en"> Title http://example.org"; method="post"> http://example.org"; method="post"> Now this doesn't imply that nesting HTML form /tags/ is a good idea, supported by browsers or something we should try to do. Nesting form /components/ is another matter, and another email message. Martijn [1] http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-October/004807.html -- http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote for http://www.thebeststuffintheworld.com/stuff/wicket";>Wicket at the http://www.thebeststuffintheworld.com/";>Best Stuff in the World!
Re: Re: [VOTE] Nested forms - don't process inner form fields in outer form submit
actually the JSF is finshed, in revision what 1.2 now? :) it sucks, but its still a standard -igor On 11/5/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote: DOH! - that hurts ;) no serious: for java-webframeworks there is no standard yet - at least no finished (JSP is dead & mess, JSF is not yet finished and usable and struts... well, split up into different projects) > -Ursprüngliche Nachricht- > Von: Igor Vaynberg [mailto:[EMAIL PROTECTED] > Gesendet: Montag, 6. November 2006 00:09 > An: wicket-dev@incubator.apache.org > Betreff: Re: Re: [VOTE] Nested forms - don't process inner > form fields in outer form submit > > On 11/5/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote: > > > > shame on me ... > > > > my personal way is to always stick to standards - it might > be harder > > sometimes to achive this, but youre on a save side... > > > you contradict yourself by using wicket :P > > -igor > > > > Regards > > > > Korbinian > > > > > -Ursprüngliche Nachricht- > > > Von: Martijn Dashorst [mailto:[EMAIL PROTECTED] > > > Gesendet: Sonntag, 5. November 2006 22:00 > > > An: wicket-dev@incubator.apache.org > > > Betreff: Re: Re: [VOTE] Nested forms - don't process inner form > > > fields in outer form submit > > > > > > On 11/5/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > > > The vote: don't process inner form fields when the > outer form is > > > > > submitted [ ] Yes, don't process those pesky little > > > fields [ ] No, > > > > > process them as if they were part of the outer form > > > > > > > > I'm still not crazy about the whole concept, but I guess > > > nested forms > > > > can be useful sometimes. I just hope we don't open up > > > another can of > > > > worms. > > > > > > Hmmm breakfast. We already allow nested forms, but we > don't do > > > anything about it, and these fail horribly at the moment as > > > Korbinian reminds us of constantly. The only other option > would be > > > to check the markup and throw a runtime exception that nesting is > > > not allowed. > > > > > > I think the way we treat nested forms in 2.0 and 1.3 a real > > > improvement and a showcase for component frameworks: work around > > > problems in an elegant and meaningful way. Abstract away the > > > limitations of the protocols we have to work with. > > > > > > > My vote: > > > > [ x ] Yes, don't process those pesky little fields > > > > > > > > as that is more explicit/ less magic. > > > > > > Thanks for the vote. > > > > > > Martijn > > > > > > -- > > > > > > href="http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote > > > > > > for > > > href="http://www.thebeststuffintheworld.com/stuff/wicket";>Wicket > > > at the http://www.thebeststuffintheworld.com/";>Best > > > Stuff in the World! > > > > > > > >
AW: Re: [VOTE] Nested forms - don't process inner form fields in outer form submit
DOH! - that hurts ;) no serious: for java-webframeworks there is no standard yet - at least no finished (JSP is dead & mess, JSF is not yet finished and usable and struts... well, split up into different projects) > -Ursprüngliche Nachricht- > Von: Igor Vaynberg [mailto:[EMAIL PROTECTED] > Gesendet: Montag, 6. November 2006 00:09 > An: wicket-dev@incubator.apache.org > Betreff: Re: Re: [VOTE] Nested forms - don't process inner > form fields in outer form submit > > On 11/5/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote: > > > > shame on me ... > > > > my personal way is to always stick to standards - it might > be harder > > sometimes to achive this, but youre on a save side... > > > you contradict yourself by using wicket :P > > -igor > > > > Regards > > > > Korbinian > > > > > -Ursprüngliche Nachricht- > > > Von: Martijn Dashorst [mailto:[EMAIL PROTECTED] > > > Gesendet: Sonntag, 5. November 2006 22:00 > > > An: wicket-dev@incubator.apache.org > > > Betreff: Re: Re: [VOTE] Nested forms - don't process inner form > > > fields in outer form submit > > > > > > On 11/5/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > > > The vote: don't process inner form fields when the > outer form is > > > > > submitted [ ] Yes, don't process those pesky little > > > fields [ ] No, > > > > > process them as if they were part of the outer form > > > > > > > > I'm still not crazy about the whole concept, but I guess > > > nested forms > > > > can be useful sometimes. I just hope we don't open up > > > another can of > > > > worms. > > > > > > Hmmm breakfast. We already allow nested forms, but we > don't do > > > anything about it, and these fail horribly at the moment as > > > Korbinian reminds us of constantly. The only other option > would be > > > to check the markup and throw a runtime exception that nesting is > > > not allowed. > > > > > > I think the way we treat nested forms in 2.0 and 1.3 a real > > > improvement and a showcase for component frameworks: work around > > > problems in an elegant and meaningful way. Abstract away the > > > limitations of the protocols we have to work with. > > > > > > > My vote: > > > > [ x ] Yes, don't process those pesky little fields > > > > > > > > as that is more explicit/ less magic. > > > > > > Thanks for the vote. > > > > > > Martijn > > > > > > -- > > > > > > href="http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote > > > > > > for > > > href="http://www.thebeststuffintheworld.com/stuff/wicket";>Wicket > > > at the http://www.thebeststuffintheworld.com/";>Best > > > Stuff in the World! > > > > > > > >
Re: Re: [VOTE] Nested forms - don't process inner form fields in outer form submit
On 11/5/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote: shame on me ... my personal way is to always stick to standards - it might be harder sometimes to achive this, but youre on a save side... you contradict yourself by using wicket :P -igor Regards Korbinian > -Ursprüngliche Nachricht- > Von: Martijn Dashorst [mailto:[EMAIL PROTECTED] > Gesendet: Sonntag, 5. November 2006 22:00 > An: wicket-dev@incubator.apache.org > Betreff: Re: Re: [VOTE] Nested forms - don't process inner > form fields in outer form submit > > On 11/5/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > The vote: don't process inner form fields when the outer form is > > > submitted [ ] Yes, don't process those pesky little > fields [ ] No, > > > process them as if they were part of the outer form > > > > I'm still not crazy about the whole concept, but I guess > nested forms > > can be useful sometimes. I just hope we don't open up > another can of > > worms. > > Hmmm breakfast. We already allow nested forms, but we > don't do anything about it, and these fail horribly at the > moment as Korbinian reminds us of constantly. The only other > option would be to check the markup and throw a runtime > exception that nesting is not allowed. > > I think the way we treat nested forms in 2.0 and 1.3 a real > improvement and a showcase for component frameworks: work > around problems in an elegant and meaningful way. Abstract > away the limitations of the protocols we have to work with. > > > My vote: > > [ x ] Yes, don't process those pesky little fields > > > > as that is more explicit/ less magic. > > Thanks for the vote. > > Martijn > > -- > href="http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote > for href="http://www.thebeststuffintheworld.com/stuff/wicket";>Wicket > at the http://www.thebeststuffintheworld.com/";>Best > Stuff in the World! >
Re: Re: [VOTE] Nested forms - don't process inner form fields in outer form submit
I'm -1 on allowing nested forms, and +1 on throwing a runtime error if this condition is encountered. Non-binding. On 11/5/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote: shame on me ... now serious > I think the way we treat nested forms in 2.0 and 1.3 a real > improvement and a showcase for component frameworks: work > around problems in an elegant and meaningful way. Abstract > away the limitations of the protocols we have to work with. i think this is a big danger - remember: most wicket users come from a point of GUI building, they dont know the limitations of http, html, css, ajax - this ends usually up in trouble (security, locked out browsers, unusability, load, not barrer free...) my personal way is to always stick to standards - it might be harder sometimes to achive this, but youre on a save side... Regards Korbinian > -Ursprüngliche Nachricht- > Von: Martijn Dashorst [mailto:[EMAIL PROTECTED] > Gesendet: Sonntag, 5. November 2006 22:00 > An: wicket-dev@incubator.apache.org > Betreff: Re: Re: [VOTE] Nested forms - don't process inner > form fields in outer form submit > > On 11/5/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > The vote: don't process inner form fields when the outer form is > > > submitted [ ] Yes, don't process those pesky little > fields [ ] No, > > > process them as if they were part of the outer form > > > > I'm still not crazy about the whole concept, but I guess > nested forms > > can be useful sometimes. I just hope we don't open up > another can of > > worms. > > Hmmm breakfast. We already allow nested forms, but we > don't do anything about it, and these fail horribly at the > moment as Korbinian reminds us of constantly. The only other > option would be to check the markup and throw a runtime > exception that nesting is not allowed. > > I think the way we treat nested forms in 2.0 and 1.3 a real > improvement and a showcase for component frameworks: work > around problems in an elegant and meaningful way. Abstract > away the limitations of the protocols we have to work with. > > > My vote: > > [ x ] Yes, don't process those pesky little fields > > > > as that is more explicit/ less magic. > > Thanks for the vote. > > Martijn > > -- > href="http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote > for href="http://www.thebeststuffintheworld.com/stuff/wicket";>Wicket > at the http://www.thebeststuffintheworld.com/";>Best > Stuff in the World! >
Re: Re: [VOTE] Nested forms - don't process inner form fields in outer form submit
my personal way is to always stick to standards - it might be harder sometimes to achive this, but youre on a save side... And that's a sane view point. However, we are not forcing people to use nested forms, but we merely make it possible. We could consider making this another configuration parameter (throw exception or process nested), though I'm not sure whether that will be worth the effort. Eelco
AW: Re: [VOTE] Nested forms - don't process inner form fields in outer form submit
shame on me ... now serious > I think the way we treat nested forms in 2.0 and 1.3 a real > improvement and a showcase for component frameworks: work > around problems in an elegant and meaningful way. Abstract > away the limitations of the protocols we have to work with. i think this is a big danger - remember: most wicket users come from a point of GUI building, they dont know the limitations of http, html, css, ajax - this ends usually up in trouble (security, locked out browsers, unusability, load, not barrer free...) my personal way is to always stick to standards - it might be harder sometimes to achive this, but youre on a save side... Regards Korbinian > -Ursprüngliche Nachricht- > Von: Martijn Dashorst [mailto:[EMAIL PROTECTED] > Gesendet: Sonntag, 5. November 2006 22:00 > An: wicket-dev@incubator.apache.org > Betreff: Re: Re: [VOTE] Nested forms - don't process inner > form fields in outer form submit > > On 11/5/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > The vote: don't process inner form fields when the outer form is > > > submitted [ ] Yes, don't process those pesky little > fields [ ] No, > > > process them as if they were part of the outer form > > > > I'm still not crazy about the whole concept, but I guess > nested forms > > can be useful sometimes. I just hope we don't open up > another can of > > worms. > > Hmmm breakfast. We already allow nested forms, but we > don't do anything about it, and these fail horribly at the > moment as Korbinian reminds us of constantly. The only other > option would be to check the markup and throw a runtime > exception that nesting is not allowed. > > I think the way we treat nested forms in 2.0 and 1.3 a real > improvement and a showcase for component frameworks: work > around problems in an elegant and meaningful way. Abstract > away the limitations of the protocols we have to work with. > > > My vote: > > [ x ] Yes, don't process those pesky little fields > > > > as that is more explicit/ less magic. > > Thanks for the vote. > > Martijn > > -- > href="http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote > for href="http://www.thebeststuffintheworld.com/stuff/wicket";>Wicket > at the http://www.thebeststuffintheworld.com/";>Best > Stuff in the World! >
Re: AW: Nested forms
the idea of me was that the outer form extends the inner - as this is closes to what happens in html. So yo still can process the inner one, as is a complete form, but when the outer one is processed, the inner onSubmit etc. is overriden and therefore no other misunderstandings and errors should occur. This is also closest to the html form that is coming out - the inner one can be processed, but if you do the outer one then the inner is processed too (in case of formouter extends form inner) and solely processed in case of outer form doenst extend inner form. that is should be 2 seperate form is ok, if the developer wants to tread them seperately, if he wants to tread them together, he may use the outer extending the inner. Sounds quite basic and easy to me. I wouldn't like to force clients use inheritance here. I think the nested form use cases would more closely resemble composition and furthermore, I don't think forcing inheritance would solve a real problem here. Eelco
Re: [VOTE] Cutting to the chase: create branch 1.2.x, start 1.3
+1 On 11/5/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote: From my previous long winded message and to make sure we're voting on the right issue: - create 1.2.x from current head, - fix only bugs in 1.2.x branch after a vote, - eventually release 1.2.4 - start working on 1.3 *NOW* Create a vote for each issue that should go into 1.2. This creates a low barrier for fixing stuff in three branches. In my opinion anyone can hold a vote for anything, this would mean that anyone can start a vote to get a bug fixed in 1.2.x. Martijn -- http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote for http://www.thebeststuffintheworld.com/stuff/wicket";>Wicket at the http://www.thebeststuffintheworld.com/";>Best Stuff in the World!
Re: Re: [VOTE] Nested forms - don't process inner form fields in outer form submit
Hmmm breakfast. We already allow nested forms, but we don't do anything about it, and these fail horribly at the moment as Korbinian reminds us of constantly. The only other option would be to check the markup and throw a runtime exception that nesting is not allowed. I think the way we treat nested forms in 2.0 and 1.3 a real improvement and a showcase for component frameworks: work around problems in an elegant and meaningful way. Abstract away the limitations of the protocols we have to work with. Yeah, I can see that, and the fact that you and Igor think it is really useful is enough for me to vote +1, but I wrote a lot of Wicket myself over last two years, and never had to use the construction or even found it would have solved any problem better. Anyway, enough of that, you gave a convincing example earlier. Eelco
Re: Re: [VOTE] Nested forms - don't process inner form fields in outer form submit
On 11/5/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > The vote: don't process inner form fields when the outer form is submitted > [ ] Yes, don't process those pesky little fields > [ ] No, process them as if they were part of the outer form I'm still not crazy about the whole concept, but I guess nested forms can be useful sometimes. I just hope we don't open up another can of worms. Hmmm breakfast. We already allow nested forms, but we don't do anything about it, and these fail horribly at the moment as Korbinian reminds us of constantly. The only other option would be to check the markup and throw a runtime exception that nesting is not allowed. I think the way we treat nested forms in 2.0 and 1.3 a real improvement and a showcase for component frameworks: work around problems in an elegant and meaningful way. Abstract away the limitations of the protocols we have to work with. My vote: [ x ] Yes, don't process those pesky little fields as that is more explicit/ less magic. Thanks for the vote. Martijn -- http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote for http://www.thebeststuffintheworld.com/stuff/wicket";>Wicket at the http://www.thebeststuffintheworld.com/";>Best Stuff in the World!
Re: [VOTE] Nested forms - don't process inner form fields in outer form submit
The vote: don't process inner form fields when the outer form is submitted [ ] Yes, don't process those pesky little fields [ ] No, process them as if they were part of the outer form I'm still not crazy about the whole concept, but I guess nested forms can be useful sometimes. I just hope we don't open up another can of worms. My vote: [ x ] Yes, don't process those pesky little fields as that is more explicit/ less magic. Eelco
Re: [VOTE] Cutting to the chase: create branch 1.2.x, start 1.3
+1 On 11/5/06, Frank Bille <[EMAIL PROTECTED]> wrote: +1 On 11/5/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > > From my previous long winded message and to make sure we're voting on > the right issue: > > - create 1.2.x from current head, > - fix only bugs in 1.2.x branch after a vote, > - eventually release 1.2.4 > - start working on 1.3 *NOW* > > Create a vote for each issue that should go into 1.2. This creates a > low barrier for fixing stuff in three branches. In my opinion anyone > can hold a vote for anything, this would mean that anyone can start a > vote to get a bug fixed in 1.2.x. > > Martijn > > -- > http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote > for http://www.thebeststuffintheworld.com/stuff/wicket > ">Wicket > at the http://www.thebeststuffintheworld.com/";>Best Stuff in > the World! >
Re: [VOTE] Cutting to the chase: create branch 1.2.x, start 1.3
+1 On 11/5/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote: From my previous long winded message and to make sure we're voting on the right issue: - create 1.2.x from current head, - fix only bugs in 1.2.x branch after a vote, - eventually release 1.2.4 - start working on 1.3 *NOW* Create a vote for each issue that should go into 1.2. This creates a low barrier for fixing stuff in three branches. In my opinion anyone can hold a vote for anything, this would mean that anyone can start a vote to get a bug fixed in 1.2.x. Martijn -- http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote for http://www.thebeststuffintheworld.com/stuff/wicket ">Wicket at the http://www.thebeststuffintheworld.com/";>Best Stuff in the World!
Re: [VOTE] Cutting to the chase: create branch 1.2.x, start 1.3
+1 -igor On 11/5/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote: From my previous long winded message and to make sure we're voting on the right issue: - create 1.2.x from current head, - fix only bugs in 1.2.x branch after a vote, - eventually release 1.2.4 - start working on 1.3 *NOW* Create a vote for each issue that should go into 1.2. This creates a low barrier for fixing stuff in three branches. In my opinion anyone can hold a vote for anything, this would mean that anyone can start a vote to get a bug fixed in 1.2.x. Martijn -- http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote for http://www.thebeststuffintheworld.com/stuff/wicket ">Wicket at the http://www.thebeststuffintheworld.com/";>Best Stuff in the World!
Re: Allow reporter to close issue?
thats what they keep telling me :) -igor On 11/5/06, Frank Bille <[EMAIL PROTECTED]> wrote: Your the man :) On 11/5/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > done > > -igor > > > On 11/5/06, Frank Bille <[EMAIL PROTECTED]> wrote: > > > > Shouldn't we change the JIRA permission to allow the reporter to close > the > > issue? I have now a couple of times tried to get reporter to confirm and > > close the issue but they couldn't because of to few permissions. > > > > Frank > > > > > >
[VOTE] Cutting to the chase: create branch 1.2.x, start 1.3
From my previous long winded message and to make sure we're voting on the right issue: - create 1.2.x from current head, - fix only bugs in 1.2.x branch after a vote, - eventually release 1.2.4 - start working on 1.3 *NOW* Create a vote for each issue that should go into 1.2. This creates a low barrier for fixing stuff in three branches. In my opinion anyone can hold a vote for anything, this would mean that anyone can start a vote to get a bug fixed in 1.2.x. Martijn -- http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote for http://www.thebeststuffintheworld.com/stuff/wicket";>Wicket at the http://www.thebeststuffintheworld.com/";>Best Stuff in the World!
Re: Allow reporter to close issue?
Your the man :) On 11/5/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: done -igor On 11/5/06, Frank Bille <[EMAIL PROTECTED]> wrote: > > Shouldn't we change the JIRA permission to allow the reporter to close the > issue? I have now a couple of times tried to get reporter to confirm and > close the issue but they couldn't because of to few permissions. > > Frank > >
Re: 1.2.4 or 1.3?
+1 On 11/5/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote: The current development/release process is bothering me. We don't cut to the chase and keep on working and improving minor issues. Yes I know that 1.3 and 2.0 will be far away. But we have that under our own control: the longer we postpone working on those releases the longer it will take before we release them, and are out of the incubator. Should we go for 1.2.4 and add yet another waiting period of a week for 1.3 or can we finally start working on 1.3? Scenario's: - cut 1.2.x from 1.2.3 starting point, fix only essential bugs in 1.2.x branch, eventually release 1.2.4 start working on 1.3 *NOW* - cut 1.2.x from current head, fix only new bugs in 1.2.x branch, eventually release 1.2.4 start working on 1.3 *NOW* - release 1.2.4 from current head, wait one week, hold development on 1.x branch, only bugs cut 1.2.x branch after one week start 1.3 development after that The problem I see with the third option is that we keep on postponing work on a new Wicket. There will always be bugs in Wicket. At the moment I don't see any real show stoppers (deadlocks, security, completely failing functionality) that would warrant an immediate release of 1.2.4. On the other hand, I do see a lot of functionality that could go into 1.3 and would guide us through the incubator. So to cut to the chase, I propose the following: - cut 1.2.x from current head, fix only new bugs in 1.2.x branch, eventually release 1.2.4 start working on 1.3 *NOW* Create a vote for each issue that should go into 1.2. This creates a low barrier for fixing stuff in three branches. In my opinion anyone can hold a vote for anything, this would mean that anyone can start a vote to get a bug fixed in 1.2.x. Martijn PS. google sponsored link for this message: Bed Bug information Control bedbugs in your home. Protect your family. -- http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote for http://www.thebeststuffintheworld.com/stuff/wicket";>Wicket at the http://www.thebeststuffintheworld.com/";>Best Stuff in the World!
Re: 1.2.4 or 1.3?
sounds reasonable -igor On 11/5/06, Frank Bille <[EMAIL PROTECTED]> wrote: On 11/5/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > > - cut 1.2.x from current head, fix only new bugs in 1.2.x branch, >eventually release 1.2.4 >start working on 1.3 *NOW* > +1 Frank
Re: Allow reporter to close issue?
done -igor On 11/5/06, Frank Bille <[EMAIL PROTECTED]> wrote: Shouldn't we change the JIRA permission to allow the reporter to close the issue? I have now a couple of times tried to get reporter to confirm and close the issue but they couldn't because of to few permissions. Frank
Re: 1.2.4 or 1.3?
On 11/5/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote: - cut 1.2.x from current head, fix only new bugs in 1.2.x branch, eventually release 1.2.4 start working on 1.3 *NOW* +1 Frank
Re: Re: Re: Re: License headers
On 11/5/06, Frank Bille <[EMAIL PROTECTED]> wrote: Good idea let me play around with that. :) Don't let me hold you back, it is all yours! (I only want to play with your toys at a later time) Martijn
1.2.4 or 1.3?
The current development/release process is bothering me. We don't cut to the chase and keep on working and improving minor issues. Yes I know that 1.3 and 2.0 will be far away. But we have that under our own control: the longer we postpone working on those releases the longer it will take before we release them, and are out of the incubator. Should we go for 1.2.4 and add yet another waiting period of a week for 1.3 or can we finally start working on 1.3? Scenario's: - cut 1.2.x from 1.2.3 starting point, fix only essential bugs in 1.2.x branch, eventually release 1.2.4 start working on 1.3 *NOW* - cut 1.2.x from current head, fix only new bugs in 1.2.x branch, eventually release 1.2.4 start working on 1.3 *NOW* - release 1.2.4 from current head, wait one week, hold development on 1.x branch, only bugs cut 1.2.x branch after one week start 1.3 development after that The problem I see with the third option is that we keep on postponing work on a new Wicket. There will always be bugs in Wicket. At the moment I don't see any real show stoppers (deadlocks, security, completely failing functionality) that would warrant an immediate release of 1.2.4. On the other hand, I do see a lot of functionality that could go into 1.3 and would guide us through the incubator. So to cut to the chase, I propose the following: - cut 1.2.x from current head, fix only new bugs in 1.2.x branch, eventually release 1.2.4 start working on 1.3 *NOW* Create a vote for each issue that should go into 1.2. This creates a low barrier for fixing stuff in three branches. In my opinion anyone can hold a vote for anything, this would mean that anyone can start a vote to get a bug fixed in 1.2.x. Martijn PS. google sponsored link for this message: Bed Bug information Control bedbugs in your home. Protect your family. -- http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote for http://www.thebeststuffintheworld.com/stuff/wicket";>Wicket at the http://www.thebeststuffintheworld.com/";>Best Stuff in the World!
Re: Re: Re: License headers
On 11/5/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote: Anyhow, the check could also be a unit test, and the actual checking/file scanner could be implemented in Wicket core (though it is not a specific framework concern imo). Good idea let me play around with that. :) Frank
Re: Re: Re: License headers
Their site is now out of order, so I couldn't check it. I thought you
could supply a file pattern.
Anyhow, the check could also be a unit test, and the actual
checking/file scanner could be implemented in Wicket core (though it
is not a specific framework concern imo).
All sub projects could then implement the license check in their own
unit tests. Even the base test case could be inside the
'wicket.util.license' package:
protected abstract class ApacheLicenseTest extends TestCase {
public void testJavaScript() {
// do test
}
public void testCss() {
// do test
}
public void testJava() {
// do test
}
public void testHtml() {
// do test
}
// etc.
}
Each project then only has to do (will automatically be picked up by
the testrunner):
public WicketApacheLicenseTest extends ApacheLicenseTest {
}
public WicketExtensionsApacheLicenseTest extends ApacheLicenseTest {
}
Martijn
On 11/5/06, Frank Bille <[EMAIL PROTECTED]> wrote:
I don't know checkstyle very well, but doesn't it only handle java code?
Frank
On 11/5/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
>
> On 11/5/06, Frank Bille <[EMAIL PROTECTED]> wrote:
> > The bad thing about having it as a unittest is that it has to be copied
> to
> > every subproject and can't just be run off wicket-parent.
>
> True, that is an argument for using checkstyle.
>
> Martijn
>
> --
> http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote
> for http://www.thebeststuffintheworld.com/stuff/wicket
> ">Wicket
> at the http://www.thebeststuffintheworld.com/";>Best Stuff in
> the World!
>
--
http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote
for http://www.thebeststuffintheworld.com/stuff/wicket";>Wicket
at the http://www.thebeststuffintheworld.com/";>Best Stuff in
the World!
Re: Re: License headers
I don't know checkstyle very well, but doesn't it only handle java code? Frank On 11/5/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote: On 11/5/06, Frank Bille <[EMAIL PROTECTED]> wrote: > The bad thing about having it as a unittest is that it has to be copied to > every subproject and can't just be run off wicket-parent. True, that is an argument for using checkstyle. Martijn -- http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote for http://www.thebeststuffintheworld.com/stuff/wicket ">Wicket at the http://www.thebeststuffintheworld.com/";>Best Stuff in the World!
Re: Re: License headers
On 11/5/06, Frank Bille <[EMAIL PROTECTED]> wrote: The bad thing about having it as a unittest is that it has to be copied to every subproject and can't just be run off wicket-parent. True, that is an argument for using checkstyle. Martijn -- http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote for http://www.thebeststuffintheworld.com/stuff/wicket";>Wicket at the http://www.thebeststuffintheworld.com/";>Best Stuff in the World!
Re: License headers
But yeah I forgot the .js files. I'll add them right away. The bad thing about having it as a unittest is that it has to be copied to every subproject and can't just be run off wicket-parent. What to do with all these license headers when "building binaries"/"sending output to client"/etc. is another discussion. :) Frank On 11/5/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote: I was going to propose to use checkstyle instead. Problem with checkstyle is that it is not a unit test and doesn't run inside Eclipse, NetBeans or IDEA :-). I would also (as a preliminary action) add javascript to the list (.js). We can always remove them, but at the moment, they need to be in there. I don't expect ASF to relax their stance on those files. +1 on removing the svn keywords. Martijn On 11/5/06, Frank Bille <[EMAIL PROTECTED]> wrote: > Last night when I couldn't sleep I got this crazy idea to write a unittest > for checking the source files in the project for correct license headers. > When I woke up this morning the idea still seemed quite reasonable, so I > cleaned it up and have now committed some code for it[1]. > > So what does this mean? Well to begin with the test checks the following > file types: .java, .xml, .html, .properties, .fml, .css and .vm. For .java > files it's checking on the new updated Apache2 license header[2], *without* > our svn keywords. The developers I have talked to doesn't seem to care about > those anyway, but WDYT? > > The test doesn't fix the headers or add the license. > > WDYT? > > Frank > > [1]: http://svn.apache.org/viewvc?view=rev&rev=471390 > [2]: http://www.apache.org/legal/src-headers.html > > -- http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote for http://www.thebeststuffintheworld.com/stuff/wicket ">Wicket at the http://www.thebeststuffintheworld.com/";>Best Stuff in the World!
Re: [VOTE] Nested forms - don't process inner form fields in outer form submit
On 11/5/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote: The vote: don't process inner form fields when the outer form is submitted [X] Yes, don't process those pesky little fields [ ] No, process them as if they were part of the outer form
Re: License headers
I was going to propose to use checkstyle instead. Problem with checkstyle is that it is not a unit test and doesn't run inside Eclipse, NetBeans or IDEA :-). I would also (as a preliminary action) add javascript to the list (.js). We can always remove them, but at the moment, they need to be in there. I don't expect ASF to relax their stance on those files. +1 on removing the svn keywords. Martijn On 11/5/06, Frank Bille <[EMAIL PROTECTED]> wrote: Last night when I couldn't sleep I got this crazy idea to write a unittest for checking the source files in the project for correct license headers. When I woke up this morning the idea still seemed quite reasonable, so I cleaned it up and have now committed some code for it[1]. So what does this mean? Well to begin with the test checks the following file types: .java, .xml, .html, .properties, .fml, .css and .vm. For .java files it's checking on the new updated Apache2 license header[2], *without* our svn keywords. The developers I have talked to doesn't seem to care about those anyway, but WDYT? The test doesn't fix the headers or add the license. WDYT? Frank [1]: http://svn.apache.org/viewvc?view=rev&rev=471390 [2]: http://www.apache.org/legal/src-headers.html -- http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote for http://www.thebeststuffintheworld.com/stuff/wicket";>Wicket at the http://www.thebeststuffintheworld.com/";>Best Stuff in the World!
AW: [VOTE] Nested forms - don't process inner form fields in outer form submit
I vote (if im allowed) not to allow nested forms at all as they are not HTML compliant. Regards > -Ursprüngliche Nachricht- > Von: Martijn Dashorst [mailto:[EMAIL PROTECTED] > Gesendet: Sonntag, 5. November 2006 13:40 > An: Wicket Development > Betreff: [VOTE] Nested forms - don't process inner form > fields in outer form submit > > A problem with nested forms arises when the outer form is > submitted and what should happen with the fields of the inner forms. > > Consider the following form setup in a page: > > outer > inner1 > inner2 > inner3 > inner4 > > If you submit the outer form, what should you process now? > All inner forms? In what order? What happens if validation of > one of the inner forms fails? > > My proposal is to treat the outer form the same as submitting > one of the inner forms: don't process the input of the form > that was not explicitly submitted. The reason is that it > breaks the encapsulation of the inner forms and therefore can > introduce subtle bugs or unwanted behavior. > > If a user of the nested form does want to process the inner > forms, it is a matter of implementing a form visitor that > visits all or a particular inner form and invokes the > processing. In this case, the user is himself responsible for > breaking the encapsulation, not us. > > The vote: don't process inner form fields when the outer form > is submitted [ ] Yes, don't process those pesky little fields > [ ] No, process them as if they were part of the outer form > > Martijn >
[VOTE] Nested forms - don't process inner form fields in outer form submit
A problem with nested forms arises when the outer form is submitted and what should happen with the fields of the inner forms. Consider the following form setup in a page: outer inner1 inner2 inner3 inner4 If you submit the outer form, what should you process now? All inner forms? In what order? What happens if validation of one of the inner forms fails? My proposal is to treat the outer form the same as submitting one of the inner forms: don't process the input of the form that was not explicitly submitted. The reason is that it breaks the encapsulation of the inner forms and therefore can introduce subtle bugs or unwanted behavior. If a user of the nested form does want to process the inner forms, it is a matter of implementing a form visitor that visits all or a particular inner form and invokes the processing. In this case, the user is himself responsible for breaking the encapsulation, not us. The vote: don't process inner form fields when the outer form is submitted [ ] Yes, don't process those pesky little fields [ ] No, process them as if they were part of the outer form Martijn
Re: AW: AW: Nested forms
This has nothing to do with extending or inheritence.
The idea is that sometimes you have a form inside of which you want to
nest other components such as panels. Previously you have to design
your panels such that they don't have a form inside, imposing the
requirement of adding the form on the user of the panel.
This breaks the component encapsulation and therefore I came up with
allowing the nesting of forms. The question here is whether the inputs
of the inner form should be updated and processed when the outer form
is submitted.
The longer I think about it, I seriously don't think it is wise to do
so. I'll create a proposal for this with a vote.
Martijn
On 11/5/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
Hi Johan,
the idea of me was that the outer form extends the inner - as this is closes
to what happens in html. So yo still can process the inner one, as is a
complete form, but when the outer one is processed, the inner onSubmit etc.
is overriden and therefore no other misunderstandings and errors should
occur. This is also closest to the html form that is coming out - the inner
one can be processed, but if you do the outer one then the inner is
processed too (in case of formouter extends form inner) and solely processed
in case of outer form doenst extend inner form.
that is should be 2 seperate form is ok, if the developer wants to tread
them seperately, if he wants to tread them together, he may use the outer
extending the inner. Sounds quite basic and easy to me.
Regards
Korbinian
> -Ursprüngliche Nachricht-
> Von: Johan Compagner [mailto:[EMAIL PROTECTED]
> Gesendet: Samstag, 4. November 2006 23:02
> An: wicket-dev@incubator.apache.org
> Betreff: Re: AW: Nested forms
>
> what do you mean extend the inner form? as in java extend?
> Why should you do that as developer. then just have one form.
> What does that inner do then?
>
> It should be just 2 seperate forms (on the java side) and if
> possible we should know what button (so what form) is
> submitted so that only one is processed The other should keep
> the rawinput for the next render.
>
> johan
>
>
> On 11/4/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
> >
> > hmm.. I like that idea. If this is a wicket only thing, you
> might want
> > to let the programmer decide what should be happening..
> perhaps the
> > outer form has to extend the inner one if it should be act
> like 1 big
> > form, if you dont extend it, they are acting as 2 own forms instead?
> >
> > Regards
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Matej Knopp [mailto:[EMAIL PROTECTED]
> > > Gesendet: Samstag, 4. November 2006 18:38
> > > An: wicket-dev@incubator.apache.org
> > > Betreff: Re: AW: Nested forms
> > >
> > > Indeed, nesting html forms it not allowed. Therefore we
> have nested
> > > forms support in 2.0. If you nest form copmonents, the
> inner > > tags will be replaced by s.
> > >
> > > When the inner form is submitted, it actually means
> submitting the
> > > outerform, but only the fieds from inner form will be
> validated and
> > > updated.
> > >
> > > -Matej
> > >
> > > Korbinian Bachl wrote:
> > > > Emm, Martinj,
> > > >
> > > > im not sure but as far as I know, nested forms are not
> allowed in
> > > > HTML3, 4 and XHTML 1.0 and 1.1. Furthermore, as its not allowed
> > > > you dont know what the browser will do.
> > > >
> > > > Regards
> > > >
> > > >> -Ursprüngliche Nachricht-
> > > >> Von: Martijn Dashorst [mailto:[EMAIL PROTECTED]
> > > >> Gesendet: Samstag, 4. November 2006 17:49
> > > >> An: Wicket Development
> > > >> Betreff: Nested forms
> > > >>
> > > >> I was surprised to see the nested forms working, but I have a
> > > >> question on what happens with the inner form inputs when the
> > > >> outer form is
> > > >> submitted:
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> public class MyPage extends WebPage {
> > > >> private String inner;
> > > >> private String outer;
> > > >>
> > > >> public MyPage() {
> > > >> Form outer = new Form(this, "outer");
> > > >> new TextField(outer, "field", new PropertyModel(this,
> > > >> "outer"));
> > > >> Form inner = new Form(outer, "inner");
> > > >> new TextField(inner, "field", new PropertyModel(this,
> > > >> "inner"));
> > > >> new Button(outer, "outerSave") {};
> > > >> new Button(inner, "innerSave") {};
> > > >> }
> > > >> }
> > > >>
> > > >> If the user clicks the inner button, only the inner fields are
> > > >> processed.
> > > >>
> > > >> If the user clicks the outer button, both the inner and
> > > outer fields
> > > >> are processed, but the inner forms 'onSubmit' is not called.
> > > >>
> > > >> Two questions:
> > > >> 1. should the inner fields be processed and update
> their models?
> > > >> 2. should the inner onSubmit/onError be called when
> the outer is
> > > >> submitted?
> > > >>
> > > >> Martijn
> >
AW: AW: Nested forms
Hi Johan,
the idea of me was that the outer form extends the inner - as this is closes
to what happens in html. So yo still can process the inner one, as is a
complete form, but when the outer one is processed, the inner onSubmit etc.
is overriden and therefore no other misunderstandings and errors should
occur. This is also closest to the html form that is coming out - the inner
one can be processed, but if you do the outer one then the inner is
processed too (in case of formouter extends form inner) and solely processed
in case of outer form doenst extend inner form.
that is should be 2 seperate form is ok, if the developer wants to tread
them seperately, if he wants to tread them together, he may use the outer
extending the inner. Sounds quite basic and easy to me.
Regards
Korbinian
> -Ursprüngliche Nachricht-
> Von: Johan Compagner [mailto:[EMAIL PROTECTED]
> Gesendet: Samstag, 4. November 2006 23:02
> An: wicket-dev@incubator.apache.org
> Betreff: Re: AW: Nested forms
>
> what do you mean extend the inner form? as in java extend?
> Why should you do that as developer. then just have one form.
> What does that inner do then?
>
> It should be just 2 seperate forms (on the java side) and if
> possible we should know what button (so what form) is
> submitted so that only one is processed The other should keep
> the rawinput for the next render.
>
> johan
>
>
> On 11/4/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
> >
> > hmm.. I like that idea. If this is a wicket only thing, you
> might want
> > to let the programmer decide what should be happening..
> perhaps the
> > outer form has to extend the inner one if it should be act
> like 1 big
> > form, if you dont extend it, they are acting as 2 own forms instead?
> >
> > Regards
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Matej Knopp [mailto:[EMAIL PROTECTED]
> > > Gesendet: Samstag, 4. November 2006 18:38
> > > An: wicket-dev@incubator.apache.org
> > > Betreff: Re: AW: Nested forms
> > >
> > > Indeed, nesting html forms it not allowed. Therefore we
> have nested
> > > forms support in 2.0. If you nest form copmonents, the
> inner > > tags will be replaced by s.
> > >
> > > When the inner form is submitted, it actually means
> submitting the
> > > outerform, but only the fieds from inner form will be
> validated and
> > > updated.
> > >
> > > -Matej
> > >
> > > Korbinian Bachl wrote:
> > > > Emm, Martinj,
> > > >
> > > > im not sure but as far as I know, nested forms are not
> allowed in
> > > > HTML3, 4 and XHTML 1.0 and 1.1. Furthermore, as its not allowed
> > > > you dont know what the browser will do.
> > > >
> > > > Regards
> > > >
> > > >> -Ursprüngliche Nachricht-
> > > >> Von: Martijn Dashorst [mailto:[EMAIL PROTECTED]
> > > >> Gesendet: Samstag, 4. November 2006 17:49
> > > >> An: Wicket Development
> > > >> Betreff: Nested forms
> > > >>
> > > >> I was surprised to see the nested forms working, but I have a
> > > >> question on what happens with the inner form inputs when the
> > > >> outer form is
> > > >> submitted:
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> public class MyPage extends WebPage {
> > > >> private String inner;
> > > >> private String outer;
> > > >>
> > > >> public MyPage() {
> > > >> Form outer = new Form(this, "outer");
> > > >> new TextField(outer, "field", new PropertyModel(this,
> > > >> "outer"));
> > > >> Form inner = new Form(outer, "inner");
> > > >> new TextField(inner, "field", new PropertyModel(this,
> > > >> "inner"));
> > > >> new Button(outer, "outerSave") {};
> > > >> new Button(inner, "innerSave") {};
> > > >> }
> > > >> }
> > > >>
> > > >> If the user clicks the inner button, only the inner fields are
> > > >> processed.
> > > >>
> > > >> If the user clicks the outer button, both the inner and
> > > outer fields
> > > >> are processed, but the inner forms 'onSubmit' is not called.
> > > >>
> > > >> Two questions:
> > > >> 1. should the inner fields be processed and update
> their models?
> > > >> 2. should the inner onSubmit/onError be called when
> the outer is
> > > >> submitted?
> > > >>
> > > >> Martijn
> > > >> --
> > > >> > > >>
> > >
> href="http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote > > >
> > > >> for > > >>
> > >
> href="http://www.thebeststuffintheworld.com/stuff/wicket";>Wicket
> > > >> at the http://www.thebeststuffintheworld.com/";>Best
> > > >> Stuff in the World!
> > > >>
> > > >
> > > >
> > >
> > >
> >
> >
>
Allow reporter to close issue?
Shouldn't we change the JIRA permission to allow the reporter to close the issue? I have now a couple of times tried to get reporter to confirm and close the issue but they couldn't because of to few permissions. Frank
Re: Are we ready for branch 1.2.x?
+1 to branch But branch then the current stream. We already have a version tag i presume? johan On 11/5/06, Frank Bille <[EMAIL PROTECTED]> wrote: The only thing is that I have committed something to 1.x which idealy should go into 1.2.4. I also think Matej has?! Should we then just recommit these things to the new 1.2.x or? Frank On 11/5/06, Frank Bille <[EMAIL PROTECTED]> wrote: > > +1 > > On 11/1/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > > > sounds good > > > > -igor > > > > > > On 11/1/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > > > > > > I know it is too early to call, but I just wanted to make sure we're > > > on the same page... > > > > > > This weekend is the first week anniversary of our 1.2.3 release, and > > > based on the reactions on the mailinglist it seems quite stable. > > > > > > According to the vote, we would create a branch 1.2.x and start > > > developing 1.3 on branch 1.x. > > > > > > The previous time we branched 1.2.x it got quite a heavy discussion so > > > I want to make sure we all agree this time that creating the branch is > > > welcomed and sustainable. > > > > > > I would like to propose to create the branch from the tag I created on > > > 1.2.3, ensuring that we have a consistent starting point. > > > > > > Ideas, discussions? > > > > > > Martijn > > > > > > -- > > > http://www.thebeststuffintheworld.com/vote_for/wicket > > ">Vote > > > for http://www.thebeststuffintheworld.com/stuff/wicket > > > ">Wicket > > > at the http://www.thebeststuffintheworld.com/";>Best Stuff in > > > the World! > > > > > > > >
Re: Are we ready for branch 1.2.x?
The only thing is that I have committed something to 1.x which idealy should go into 1.2.4. I also think Matej has?! Should we then just recommit these things to the new 1.2.x or? Frank On 11/5/06, Frank Bille <[EMAIL PROTECTED]> wrote: +1 On 11/1/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > sounds good > > -igor > > > On 11/1/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > > > > I know it is too early to call, but I just wanted to make sure we're > > on the same page... > > > > This weekend is the first week anniversary of our 1.2.3 release, and > > based on the reactions on the mailinglist it seems quite stable. > > > > According to the vote, we would create a branch 1.2.x and start > > developing 1.3 on branch 1.x. > > > > The previous time we branched 1.2.x it got quite a heavy discussion so > > I want to make sure we all agree this time that creating the branch is > > welcomed and sustainable. > > > > I would like to propose to create the branch from the tag I created on > > 1.2.3, ensuring that we have a consistent starting point. > > > > Ideas, discussions? > > > > Martijn > > > > -- > > http://www.thebeststuffintheworld.com/vote_for/wicket > ">Vote > > for http://www.thebeststuffintheworld.com/stuff/wicket > > ">Wicket > > at the http://www.thebeststuffintheworld.com/";>Best Stuff in > > the World! > > > >
Re: Are we ready for branch 1.2.x?
+1 On 11/1/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: sounds good -igor On 11/1/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > > I know it is too early to call, but I just wanted to make sure we're > on the same page... > > This weekend is the first week anniversary of our 1.2.3 release, and > based on the reactions on the mailinglist it seems quite stable. > > According to the vote, we would create a branch 1.2.x and start > developing 1.3 on branch 1.x. > > The previous time we branched 1.2.x it got quite a heavy discussion so > I want to make sure we all agree this time that creating the branch is > welcomed and sustainable. > > I would like to propose to create the branch from the tag I created on > 1.2.3, ensuring that we have a consistent starting point. > > Ideas, discussions? > > Martijn > > -- > http://www.thebeststuffintheworld.com/vote_for/wicket";>Vote > for http://www.thebeststuffintheworld.com/stuff/wicket > ">Wicket > at the http://www.thebeststuffintheworld.com/";>Best Stuff in > the World! >
Re: License headers
BTW, all our .java files needs to have it's license updated anyway, because of [2]. On 11/5/06, Frank Bille <[EMAIL PROTECTED]> wrote: Last night when I couldn't sleep I got this crazy idea to write a unittest for checking the source files in the project for correct license headers. When I woke up this morning the idea still seemed quite reasonable, so I cleaned it up and have now committed some code for it[1]. So what does this mean? Well to begin with the test checks the following file types: .java, .xml, .html, .properties, .fml, .css and .vm. For .java files it's checking on the new updated Apache2 license header[2], *without* our svn keywords. The developers I have talked to doesn't seem to care about those anyway, but WDYT? The test doesn't fix the headers or add the license. WDYT? Frank [1]: http://svn.apache.org/viewvc?view=rev&rev=471390 [2]: http://www.apache.org/legal/src-headers.html
License headers
Last night when I couldn't sleep I got this crazy idea to write a unittest for checking the source files in the project for correct license headers. When I woke up this morning the idea still seemed quite reasonable, so I cleaned it up and have now committed some code for it[1]. So what does this mean? Well to begin with the test checks the following file types: .java, .xml, .html, .properties, .fml, .css and .vm. For .java files it's checking on the new updated Apache2 license header[2], *without* our svn keywords. The developers I have talked to doesn't seem to care about those anyway, but WDYT? The test doesn't fix the headers or add the license. WDYT? Frank [1]: http://svn.apache.org/viewvc?view=rev&rev=471390 [2]: http://www.apache.org/legal/src-headers.html
Re: Re: AW: Nested forms
I am also in the 'separate forms - separate submits' camp. It is
probably easier to call the submit for the inside form using a child
visitor than it is to circumvent it.
The reason is: encapsulation. The nested form is a separate unit of
work. And what would you do if you have 3 or 4 forms nested? Call them
all? Which one would 'win' if a setResponsePage() was done?
Martijn
On 11/5/06, Matej Knopp <[EMAIL PROTECTED]> wrote:
Well, nothing is carved into stone. If more people think that the forms
should be treated as separate, so be it.
Do you think there should be a vote? If so can someone formulate one?
-Matej
Johan Compagner wrote:
> hmm, i don't know.
> its a difficult one.
>
> I think they are really separate you could implement it this way that
> really
> only the form is submitted.
>
> For example i have a Search Form component that is in my outer form.
> and that form has really standalone behavior. if you fill in the field and
> press search then something is searched for
> But the outer form is editing data so if i submit that form i really don't
> want to search.
>
> That kind of example make me choose for only call the submit of the form
> that is really submitted
> if it is outer or inner..
>
> johan
>
>
>
> On 11/4/06, Matej Knopp <[EMAIL PROTECTED]> wrote:
>>
>> Johan Compagner wrote:
>> > what do you mean extend the inner form? as in java extend?
>> > Why should you do that as developer. then just have one form. What does
>> > that
>> > inner do then?
>> >
>> > It should be just 2 seperate forms (on the java side)
>> > and if possible we should know what button (so what form) is submitted
>> so
>> > that only one is processed
>> > The other should keep the rawinput for the next render.
>> Yeah. This is basically what currently happens. The question is, when
>> outer form is submitted, what should the nested form do. I personally
>> think that it should be processed to. There is a parent-child
>> relationship, they are not isolated.
>>
>> If you have form a, and then form b and c inside a, you submit b, the
>> form c should not be processed (though rawinput should be kept).
>>
>> But if you submit a, I think that both b and c should be processed.
>>
>> -Matej
>> >
>> > johan
>> >
>> >
>> > On 11/4/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
>> >>
>> >> hmm.. I like that idea. If this is a wicket only thing, you might want
>> to
>> >> let the programmer decide what should be happening.. perhaps the
>> outer
>> >> form
>> >> has to extend the inner one if it should be act like 1 big form, if
>> you
>> >> dont extend it, they are acting as 2 own forms instead?
>> >>
>> >> Regards
>> >>
>> >> > -Ursprüngliche Nachricht-
>> >> > Von: Matej Knopp [mailto:[EMAIL PROTECTED]
>> >> > Gesendet: Samstag, 4. November 2006 18:38
>> >> > An: wicket-dev@incubator.apache.org
>> >> > Betreff: Re: AW: Nested forms
>> >> >
>> >> > Indeed, nesting html forms it not allowed. Therefore we have
>> >> > nested forms support in 2.0. If you nest form copmonents, the
>> >> > inner s.
>> >> >
>> >> > When the inner form is submitted, it actually means
>> >> > submitting the outerform, but only the fieds from inner form
>> >> > will be validated and updated.
>> >> >
>> >> > -Matej
>> >> >
>> >> > Korbinian Bachl wrote:
>> >> > > Emm, Martinj,
>> >> > >
>> >> > > im not sure but as far as I know, nested forms are not allowed in
>> >> > > HTML3, 4 and XHTML 1.0 and 1.1. Furthermore, as its not allowed
>> you
>> >> > > dont know what the browser will do.
>> >> > >
>> >> > > Regards
>> >> > >
>> >> > >> -Ursprüngliche Nachricht-
>> >> > >> Von: Martijn Dashorst [mailto:[EMAIL PROTECTED]
>> >> > >> Gesendet: Samstag, 4. November 2006 17:49
>> >> > >> An: Wicket Development
>> >> > >> Betreff: Nested forms
>> >> > >>
>> >> > >> I was surprised to see the nested forms working, but I have a
>> >> > >> question on what happens with the inner form inputs when the
>> outer
>> >> > >> form is
>> >> > >> submitted:
>> >> > >>
>> >> > >>
>> >> > >>
>> >> > >>
>> >> > >>
>> >> > >>
>> >> > >>
>> >> > >>
>> >> > >>
>> >> > >> public class MyPage extends WebPage {
>> >> > >> private String inner;
>> >> > >> private String outer;
>> >> > >>
>> >> > >> public MyPage() {
>> >> > >> Form outer = new Form(this, "outer");
>> >> > >> new TextField(outer, "field", new PropertyModel(this,
>> >> > >> "outer"));
>> >> > >> Form inner = new Form(outer, "inner");
>> >> > >> new TextField(inner, "field", new PropertyModel(this,
>> >> > >> "inner"));
>> >> > >> new Button(outer, "outerSave") {};
>> >> > >> new Button(inner, "innerSave") {};
>> >> > >> }
>> >> > >> }
>> >> > >>
>> >> > >> If the user clicks the inner button, only the inner fields are
>> >> > >> processed.
>> >> > >>
>> >> > >> If the user clicks the outer button, both the inner and
>> >> > outer fields
>> >> > >> are processed, but the inner forms 'onSubmi
