Re: Re: Short term road map for Wicket 1.3
you mean the removal of the object param? -igor On 11/6/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote: On 11/7/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > * IModel hierarchy improvements > whats that? The simplifications in IModel hierarchy of 2.0 applied to 1.3 i.e. collapsing of models. You did it, don't you remember? :D 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: Short term road map for Wicket 1.3
On 11/7/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > * IModel hierarchy improvements whats that? The simplifications in IModel hierarchy of 2.0 applied to 1.3 i.e. collapsing of models. You did it, don't you remember? :D 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] Should submit of outer forms process inner forms?
I like the simple solution: b) Inner forms should not be processed, just preserving user input is fine. Dirk
Re: [VOTE] Nested forms - don't process inner form fields in outer form submit
Wicket is a component framework. A reusable component might be one which has the html form element in its markup. I want to reuse this component in every possible place. This might even be inside a component which is another form. I really don't care where it is. I don't care when I create my reusable component and I don't care, when I use this component somewhere. If I had to, this would be counter-intuitive. Dirk 2006/11/6, Ryan Sonnek <[EMAIL PROTECTED]>: My vote is to not allow for inner forms either. It's too much framework "magic". Wicket is a web framework, and html doesn't allow for nested forms, so this seems totally counter-intuitive. On 11/6/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > but how does this happen? > why is the panel that has the search box and the button put _inside_ > another > form? > > let me give you the opposite example: > right now i create a lot of editor objects that are panels with > formcomponents. it would be great if i could have the panel also have a > form > so i can use an editor by itself and not need an external form. > > which usecase is more common? > > -igor > > > On 11/6/06, Johan Compagner <[EMAIL PROTECTED]> wrote: > > > > I already did that in that other thread. > > > > One outer form where you can edit some database data and submit it > > and an inner form that is just a search box so field and button'. > > Then if i submit the edit for the outer form i really don't want to > > process > > the inner form.. > > That inner form could be for example to search a value for that outer > > form. > > > > So i am: > > [X] Yes, don't process those pesky little fields > > > > to me it just doesn't make sense if you do it the other way why have > that > > inner form > > where is the usecase for that? That one i can't think of immediately > > > > johan > > > > > > On 11/6/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > > > > > 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
compile errors in wicket-auth-roles (2.0)
Could someone please fix the compile errors in wicket-auth-roles (trunk): 'The method getSecuritySettings() is undefined for the type WicketTester'. Cheers, Eelco
Re: SF RFEs
yes, logging in made the difference. Thanks Juergen On 11/6/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote: On 11/6/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > apache jira contains ~35 entries but as far as I can tell only new > ones. I tried sourceforge but the bug and rfe pages are no longer > accessible. Is that by purpose? Yes, there is no way of disabling new additions to the sf.net bug trackers without disabling them. You can still see them (I think) if you log on to sf.net as you are a wicket admin. Martijn > > Juergen > -- 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: Short term road map for Wicket 1.3
* IModel hierarchy improvements whats that? -igor
Creating 1.2.x branch
All, The time has come to finalize 1.2 and start work on 1.3. There will be a 1.2.4 release, but it will have low priority unless warranted by a major discovery of a bug. Is anyone currently busy with a bug that absolutely needs to get into 1.2.4? If so, please let me know before tuesday 10:30am CET. I'll create a branch for 1.2.x at that moment based on the current HEAD. From then on, all backports to branch 1.2.x should be voted on first. This is a minor barrier to minimize the work of maintaining 3 branches. 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
6 +1's (iiuJc), vote has passed. Martijn 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! -- 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: Short term road map for Wicket 1.3
On 11/6/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: * SecondLevelCacheSessionStore * deferred sessions * stateless components (forms, links, but basically what we have now in 2.0). +1 on all, and add: * nested forms * validator changes * IModel hierarchy improvements * API clean up ([re]move RequiredTextField?) * reference guide 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: Short term road map for Wicket 1.3
well, my personal todo then :P On 11/6/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: Yeah, the license header stuff is not so much a wish as a must-have if we want to incubate :). On 11/6/06, Frank Bille <[EMAIL PROTECTED]> wrote: >- Fix license header stuff >- Synchronize WicketTester with Juergens changes >- Backport some fixes >- (2.0 and 1.3) Take a look at WicketTester to get it consistent with >AJAX generated content. > > Frank
Re: Short term road map for Wicket 1.3
Yeah, the license header stuff is not so much a wish as a must-have if we want to incubate :). On 11/6/06, Frank Bille <[EMAIL PROTECTED]> wrote: - Fix license header stuff - Synchronize WicketTester with Juergens changes - Backport some fixes - (2.0 and 1.3) Take a look at WicketTester to get it consistent with AJAX generated content. Frank
Re: Short term road map for Wicket 1.3
That was my personal roadmap :) On 11/6/06, Frank Bille <[EMAIL PROTECTED]> wrote: - Fix license header stuff - Synchronize WicketTester with Juergens changes - Backport some fixes - (2.0 and 1.3) Take a look at WicketTester to get it consistent with AJAX generated content. Frank On 11/6/06, Eelco Hillenius < [EMAIL PROTECTED]> wrote: > > Hi, > > I know we've been here before, but that was a couple of months ago, > and opinions might have changed by now. > > What are your ideas about the /immediate/ roadmap for Wicket 1.3? I'm > interested to learn what the first things will be that people will be > working on when we start 1.3, and/ or what everyone's most important > wishes are for this version. > > I'm not totally sure myself, but as Teachscape is nearing production > and a conversion to 2.0 seems unlikely, I'm very interested in > anything that will help it scale better: > > * SecondLevelCacheSessionStore > * deferred sessions > * stateless components (forms, links, but basically what we have now in > 2.0). > > Of course, you opinions make more sense if you are planning on helping > with implementing them, and if you have no real pressing wishes, don't > state them here :) > > Eelco >
Re: Short term road map for Wicket 1.3
- Fix license header stuff - Synchronize WicketTester with Juergens changes - Backport some fixes - (2.0 and 1.3) Take a look at WicketTester to get it consistent with AJAX generated content. Frank On 11/6/06, Eelco Hillenius < [EMAIL PROTECTED]> wrote: Hi, I know we've been here before, but that was a couple of months ago, and opinions might have changed by now. What are your ideas about the /immediate/ roadmap for Wicket 1.3? I'm interested to learn what the first things will be that people will be working on when we start 1.3, and/ or what everyone's most important wishes are for this version. I'm not totally sure myself, but as Teachscape is nearing production and a conversion to 2.0 seems unlikely, I'm very interested in anything that will help it scale better: * SecondLevelCacheSessionStore * deferred sessions * stateless components (forms, links, but basically what we have now in 2.0). Of course, you opinions make more sense if you are planning on helping with implementing them, and if you have no real pressing wishes, don't state them here :) Eelco
Short term road map for Wicket 1.3
Hi, I know we've been here before, but that was a couple of months ago, and opinions might have changed by now. What are your ideas about the /immediate/ roadmap for Wicket 1.3? I'm interested to learn what the first things will be that people will be working on when we start 1.3, and/ or what everyone's most important wishes are for this version. I'm not totally sure myself, but as Teachscape is nearing production and a conversion to 2.0 seems unlikely, I'm very interested in anything that will help it scale better: * SecondLevelCacheSessionStore * deferred sessions * stateless components (forms, links, but basically what we have now in 2.0). Of course, you opinions make more sense if you are planning on helping with implementing them, and if you have no real pressing wishes, don't state them here :) Eelco
Re: onestat.js and wicket-ajax-debug-drag.js
the only wicket specific thing was the change of
var Drag = { to var WicketDrag = { :)
is that license compatible or do we need to ditch that?
-igor
On 11/6/06, Frank Bille <[EMAIL PROTECTED]> wrote:
When going through the files to add/ignore license headers I came across
these two javascript files. The onestat.js I think is easy enough
(ignore),
but what about wicket-ajax-debug-drag.js? It says something about CC
license
but the content is clearly Wicket specific. Anyone having an idea of the
license of this file? (Matej?)
Frank
Re: Re: [Vote] Should submit of outer forms process inner forms?
well, and in our application we *mostly* uses the button.onsubmit but for a
search field we use the form.onsubmit.
Frank
On 11/6/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
Typically I never have more than one button on a form that matters:
save. This is then the submit button (no wicket component), and the
cancel is just a link. So I've probably never implemented
button.onSubmit() other then for examples.
Martijn
On 11/6/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> fwiw, in my time as a wicket dev/user i dont think ive ever overridden
> form.onsubmit(), i always put that behavior into the button's
onsubmit().
>
> -igor
>
> On 11/6/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
> >
> > C with default value 'false' -> default does not process inner form.
> > IMO a form in a panel is not *typically* designed for processing in an
> > outer form.
> >
> > Take for instance:
> >
> > Form outer = new Form(this, "outer") {
> > protected void onSubmit() {
> > session.save(getModelObject());
> > }
> > }
> >
> > Form inner0 = new Form(outer, "inner0") {
> > protected boolean processOnParentSubmit() {
> > return false;
> > }
> > protected void onSubmit() {
> > session.save(getModelObject());
> > }
> > }
> >
> > Form inner1 = new Form(outer, "inner1") {
> > protected boolean processOnParentSubmit() {
> > return false;
> > }
> > protected void onSubmit() {
> > session.save(getModelObject());
> > }
> > }
> >
> > Form inner2 = new Form(inner1, "inner2") {
> > protected void onSubmit() {
> > session.save(getModelObject());
> > }
> > }
> >
> > This could lead to double saves, or save and delete, or any other
> > strange behavior. Setting the default to process inner form breaks the
> > encapsulation of the form.
> >
> > Also what is the semantics of the flag on inner form 1 with regards to
> > the processing of inner form 2?
> >
> > Martijn
> >
> > On 11/6/06, Matej Knopp <[EMAIL PROTECTED]> wrote:
> > > Hi.
> > >
> > > As you may have noticed, we have nested forms support in Wicket 2.0.
> > >
> > > (Please, this is not about whether we should/should not support
nested
> > > forms, so don't discuss it in this thread).
> > >
> > > The question is, what should happen with inner forms, when outer
forms
> > > are submitted.
> > >
> > > a) Inner forms should be processed, calling onSubmit() on each of
them
> > > b) Inner forms should not be processed, just preserving user input
is
> > fine.
> > > c) Make this configurable per form,
> > > e.g. each form would have method like processOnParentSubmit(),
which
> > > could return true, which would cause this form to be processed, when
a
> > > form in parent hierarchy is submitted.
> > >
> > > I vote for C.
> > >
> > > -Matej
> > >
> >
> >
> > --
> > 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!
onestat.js and wicket-ajax-debug-drag.js
When going through the files to add/ignore license headers I came across these two javascript files. The onestat.js I think is easy enough (ignore), but what about wicket-ajax-debug-drag.js? It says something about CC license but the content is clearly Wicket specific. Anyone having an idea of the license of this file? (Matej?) Frank
Re: Re: [Vote] Should submit of outer forms process inner forms?
Typically I never have more than one button on a form that matters:
save. This is then the submit button (no wicket component), and the
cancel is just a link. So I've probably never implemented
button.onSubmit() other then for examples.
Martijn
On 11/6/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
fwiw, in my time as a wicket dev/user i dont think ive ever overridden
form.onsubmit(), i always put that behavior into the button's onsubmit().
-igor
On 11/6/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
>
> C with default value 'false' -> default does not process inner form.
> IMO a form in a panel is not *typically* designed for processing in an
> outer form.
>
> Take for instance:
>
> Form outer = new Form(this, "outer") {
> protected void onSubmit() {
> session.save(getModelObject());
> }
> }
>
> Form inner0 = new Form(outer, "inner0") {
> protected boolean processOnParentSubmit() {
> return false;
> }
> protected void onSubmit() {
> session.save(getModelObject());
> }
> }
>
> Form inner1 = new Form(outer, "inner1") {
> protected boolean processOnParentSubmit() {
> return false;
> }
> protected void onSubmit() {
> session.save(getModelObject());
> }
> }
>
> Form inner2 = new Form(inner1, "inner2") {
> protected void onSubmit() {
> session.save(getModelObject());
> }
> }
>
> This could lead to double saves, or save and delete, or any other
> strange behavior. Setting the default to process inner form breaks the
> encapsulation of the form.
>
> Also what is the semantics of the flag on inner form 1 with regards to
> the processing of inner form 2?
>
> Martijn
>
> On 11/6/06, Matej Knopp <[EMAIL PROTECTED]> wrote:
> > Hi.
> >
> > As you may have noticed, we have nested forms support in Wicket 2.0.
> >
> > (Please, this is not about whether we should/should not support nested
> > forms, so don't discuss it in this thread).
> >
> > The question is, what should happen with inner forms, when outer forms
> > are submitted.
> >
> > a) Inner forms should be processed, calling onSubmit() on each of them
> > b) Inner forms should not be processed, just preserving user input is
> fine.
> > c) Make this configurable per form,
> > e.g. each form would have method like processOnParentSubmit(), which
> > could return true, which would cause this form to be processed, when a
> > form in parent hierarchy is submitted.
> >
> > I vote for C.
> >
> > -Matej
> >
>
>
> --
> 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: [Vote] Should submit of outer forms process inner forms?
fwiw, in my time as a wicket dev/user i dont think ive ever overridden
form.onsubmit(), i always put that behavior into the button's onsubmit().
-igor
On 11/6/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
C with default value 'false' -> default does not process inner form.
IMO a form in a panel is not *typically* designed for processing in an
outer form.
Take for instance:
Form outer = new Form(this, "outer") {
protected void onSubmit() {
session.save(getModelObject());
}
}
Form inner0 = new Form(outer, "inner0") {
protected boolean processOnParentSubmit() {
return false;
}
protected void onSubmit() {
session.save(getModelObject());
}
}
Form inner1 = new Form(outer, "inner1") {
protected boolean processOnParentSubmit() {
return false;
}
protected void onSubmit() {
session.save(getModelObject());
}
}
Form inner2 = new Form(inner1, "inner2") {
protected void onSubmit() {
session.save(getModelObject());
}
}
This could lead to double saves, or save and delete, or any other
strange behavior. Setting the default to process inner form breaks the
encapsulation of the form.
Also what is the semantics of the flag on inner form 1 with regards to
the processing of inner form 2?
Martijn
On 11/6/06, Matej Knopp <[EMAIL PROTECTED]> wrote:
> Hi.
>
> As you may have noticed, we have nested forms support in Wicket 2.0.
>
> (Please, this is not about whether we should/should not support nested
> forms, so don't discuss it in this thread).
>
> The question is, what should happen with inner forms, when outer forms
> are submitted.
>
> a) Inner forms should be processed, calling onSubmit() on each of them
> b) Inner forms should not be processed, just preserving user input is
fine.
> c) Make this configurable per form,
> e.g. each form would have method like processOnParentSubmit(), which
> could return true, which would cause this form to be processed, when a
> form in parent hierarchy is submitted.
>
> I vote for C.
>
> -Matej
>
--
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] Should submit of outer forms process inner forms?
C with default value 'false' -> default does not process inner form.
IMO a form in a panel is not *typically* designed for processing in an
outer form.
Take for instance:
Form outer = new Form(this, "outer") {
protected void onSubmit() {
session.save(getModelObject());
}
}
Form inner0 = new Form(outer, "inner0") {
protected boolean processOnParentSubmit() {
return false;
}
protected void onSubmit() {
session.save(getModelObject());
}
}
Form inner1 = new Form(outer, "inner1") {
protected boolean processOnParentSubmit() {
return false;
}
protected void onSubmit() {
session.save(getModelObject());
}
}
Form inner2 = new Form(inner1, "inner2") {
protected void onSubmit() {
session.save(getModelObject());
}
}
This could lead to double saves, or save and delete, or any other
strange behavior. Setting the default to process inner form breaks the
encapsulation of the form.
Also what is the semantics of the flag on inner form 1 with regards to
the processing of inner form 2?
Martijn
On 11/6/06, Matej Knopp <[EMAIL PROTECTED]> wrote:
Hi.
As you may have noticed, we have nested forms support in Wicket 2.0.
(Please, this is not about whether we should/should not support nested
forms, so don't discuss it in this thread).
The question is, what should happen with inner forms, when outer forms
are submitted.
a) Inner forms should be processed, calling onSubmit() on each of them
b) Inner forms should not be processed, just preserving user input is fine.
c) Make this configurable per form,
e.g. each form would have method like processOnParentSubmit(), which
could return true, which would cause this form to be processed, when a
form in parent hierarchy is submitted.
I vote for C.
-Matej
--
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
Actually, I have to reconsider my non-binding -1. I ran into a situation today where I needed nested forms with the Wizard. On 11/6/06, Matej Knopp <[EMAIL PROTECTED]> wrote: Counter intuitive? Then don't use it. We have lot of use cases for this, components that need to be independent of whether parent contains form or not. No one forces you to nest forms, so take this just as a possibility. -Matej Ryan Sonnek wrote: > My vote is to not allow for inner forms either. It's too much framework > "magic". Wicket is a web framework, and html doesn't allow for nested > forms, so this seems totally counter-intuitive. > > On 11/6/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: >> >> but how does this happen? >> why is the panel that has the search box and the button put _inside_ >> another >> form? >> >> let me give you the opposite example: >> right now i create a lot of editor objects that are panels with >> formcomponents. it would be great if i could have the panel also have a >> form >> so i can use an editor by itself and not need an external form. >> >> which usecase is more common? >> >> -igor >> >> >> On 11/6/06, Johan Compagner <[EMAIL PROTECTED]> wrote: >> > >> > I already did that in that other thread. >> > >> > One outer form where you can edit some database data and submit it >> > and an inner form that is just a search box so field and button'. >> > Then if i submit the edit for the outer form i really don't want to >> > process >> > the inner form.. >> > That inner form could be for example to search a value for that outer >> > form. >> > >> > So i am: >> > [X] Yes, don't process those pesky little fields >> > >> > to me it just doesn't make sense if you do it the other way why have >> that >> > inner form >> > where is the usecase for that? That one i can't think of immediately >> > >> > johan >> > >> > >> > On 11/6/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: >> > > >> > > 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 >> > > > >> > >
Re: SF RFEs
On 11/6/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: apache jira contains ~35 entries but as far as I can tell only new ones. I tried sourceforge but the bug and rfe pages are no longer accessible. Is that by purpose? Yes, there is no way of disabling new additions to the sf.net bug trackers without disabling them. You can still see them (I think) if you log on to sf.net as you are a wicket admin. Martijn Juergen -- 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!
SF RFEs
apache jira contains ~35 entries but as far as I can tell only new ones. I tried sourceforge but the bug and rfe pages are no longer accessible. Is that by purpose? Juergen
XForms & Wicket (was: Nested forms)
That should be doable, but someone with enough knowledge of XForms, and preferably someone who is actually going to use that should implement it. Maybe you? ;) Eelco On 11/6/06, Paolo Di Tommaso <[EMAIL PROTECTED]> wrote: Maybe is off topic in this thread, but what about XForm in wicket? http://ibm.com/developerworks/xml/library/x-xformstipmultipleforms/index.html?ca=drs- Do plan to support it in future releases? Bye - Paolo On 11/5/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > 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: AW: Nested forms
Maybe is off topic in this thread, but what about XForm in wicket? http://ibm.com/developerworks/xml/library/x-xformstipmultipleforms/index.html?ca=drs- Do plan to support it in future releases? Bye - Paolo On 11/5/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > 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] Should submit of outer forms process inner forms?
Frank Bille wrote: I think for completeness we should have: d) Throw a RuntimeException when nested forms are detected, because it's not allowed in HTML. No we shouldn't. If you want to discuss this, go ahead, but in a different thread. :) -Matej But personally I vote for (C) Frank On 11/6/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: imho it is the inner forms that knowsif they were designed to be embeddable or not, so i am for (c) -igor On 11/6/06, Matej Knopp <[EMAIL PROTECTED]> wrote: > > Hi. > > As you may have noticed, we have nested forms support in Wicket 2.0. > > (Please, this is not about whether we should/should not support nested > forms, so don't discuss it in this thread). > > The question is, what should happen with inner forms, when outer forms > are submitted. > > a) Inner forms should be processed, calling onSubmit() on each of them > b) Inner forms should not be processed, just preserving user input is > fine. > c) Make this configurable per form, > e.g. each form would have method like processOnParentSubmit(), which > could return true, which would cause this form to be processed, when a > form in parent hierarchy is submitted. > > I vote for C. > > -Matej >
Re: [Vote] Should submit of outer forms process inner forms?
I think for completeness we should have: d) Throw a RuntimeException when nested forms are detected, because it's not allowed in HTML. But personally I vote for (C) Frank On 11/6/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: imho it is the inner forms that knowsif they were designed to be embeddable or not, so i am for (c) -igor On 11/6/06, Matej Knopp <[EMAIL PROTECTED]> wrote: > > Hi. > > As you may have noticed, we have nested forms support in Wicket 2.0. > > (Please, this is not about whether we should/should not support nested > forms, so don't discuss it in this thread). > > The question is, what should happen with inner forms, when outer forms > are submitted. > > a) Inner forms should be processed, calling onSubmit() on each of them > b) Inner forms should not be processed, just preserving user input is > fine. > c) Make this configurable per form, > e.g. each form would have method like processOnParentSubmit(), which > could return true, which would cause this form to be processed, when a > form in parent hierarchy is submitted. > > I vote for C. > > -Matej >
Just an FYI [Fwd: REMINDER: *** BOARD REPORTS DUE ***]
--- Begin Message --- Yes, its that time of the month again, so this should not come as a surprise to anyone. Reports are due on or by Friday. Yes, THIS FRIDAY. Henri's https://svn.apache.org/repos/private/committers/board/incubator-info.txt shows the list of projects needing to report, plus any that are newly accepted. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- End Message ---
Re: [VOTE] Cutting to the chase: create branch 1.2.x, start 1.3
+1 Martijn Dashorst 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
Re: MockWebApplication and WicketTester no longer derived from WebApplication
just making sure you knew about it to save you some work :) -igor On 11/6/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: I didn't like the patch. It only merged MockWebApplication and WebTester into a single big class. The author assumed it works, but as the patch didn't include the modification necessary to the existing junit test cases, ... Juergen On 11/6/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > didnt someone already submit a patch that does this? > > -igor > > > On 11/6/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > > > > Currently MockWebApplication and WicketTester are derived from > > WebApplication which requires us to copy & paste code from > > MyApplication to MyWicketTester which is kind of ugly. I changed > > MockWebApplication to delegate to an application instead. It seems to > > work fine but most xxxExpectedResult.html files must be changed. > > Example > > > > > href="/WicketTester/WicketTester?wicket:interface=:0:link::ILinkListener" > > wicket:id="link">test > > --- > > > href="/DummyApplication/DummyApplication?wicket:interface=:0:link::ILinkListener" > > wicket:id="link">test > > > > I guess that is ok, but I want to check with you first. Any thought? > > > > Juergen > > > >
Re: MockWebApplication and WicketTester no longer derived from WebApplication
I didn't like the patch. It only merged MockWebApplication and WebTester into a single big class. The author assumed it works, but as the patch didn't include the modification necessary to the existing junit test cases, ... Juergen On 11/6/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: didnt someone already submit a patch that does this? -igor On 11/6/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: > > Currently MockWebApplication and WicketTester are derived from > WebApplication which requires us to copy & paste code from > MyApplication to MyWicketTester which is kind of ugly. I changed > MockWebApplication to delegate to an application instead. It seems to > work fine but most xxxExpectedResult.html files must be changed. > Example > > href="/WicketTester/WicketTester?wicket:interface=:0:link::ILinkListener" > wicket:id="link">test > --- > href="/DummyApplication/DummyApplication?wicket:interface=:0:link::ILinkListener" > wicket:id="link">test > > I guess that is ok, but I want to check with you first. Any thought? > > Juergen >
Re: [Vote] Should submit of outer forms process inner forms?
imho it is the inner forms that knowsif they were designed to be embeddable or not, so i am for (c) -igor On 11/6/06, Matej Knopp <[EMAIL PROTECTED]> wrote: Hi. As you may have noticed, we have nested forms support in Wicket 2.0. (Please, this is not about whether we should/should not support nested forms, so don't discuss it in this thread). The question is, what should happen with inner forms, when outer forms are submitted. a) Inner forms should be processed, calling onSubmit() on each of them b) Inner forms should not be processed, just preserving user input is fine. c) Make this configurable per form, e.g. each form would have method like processOnParentSubmit(), which could return true, which would cause this form to be processed, when a form in parent hierarchy is submitted. I vote for C. -Matej
Re: [Vote] Should submit of outer forms process inner forms?
I vote for C Eelco On 11/6/06, Matej Knopp <[EMAIL PROTECTED]> wrote: Hi. As you may have noticed, we have nested forms support in Wicket 2.0. (Please, this is not about whether we should/should not support nested forms, so don't discuss it in this thread). The question is, what should happen with inner forms, when outer forms are submitted. a) Inner forms should be processed, calling onSubmit() on each of them b) Inner forms should not be processed, just preserving user input is fine. c) Make this configurable per form, e.g. each form would have method like processOnParentSubmit(), which could return true, which would cause this form to be processed, when a form in parent hierarchy is submitted. I vote for C. -Matej
[Vote] Should submit of outer forms process inner forms?
Hi. As you may have noticed, we have nested forms support in Wicket 2.0. (Please, this is not about whether we should/should not support nested forms, so don't discuss it in this thread). The question is, what should happen with inner forms, when outer forms are submitted. a) Inner forms should be processed, calling onSubmit() on each of them b) Inner forms should not be processed, just preserving user input is fine. c) Make this configurable per form, e.g. each form would have method like processOnParentSubmit(), which could return true, which would cause this form to be processed, when a form in parent hierarchy is submitted. I vote for C. -Matej
Re: [VOTE] Nested forms - don't process inner form fields in outer form submit
Counter intuitive? Then don't use it. We have lot of use cases for this, components that need to be independent of whether parent contains form or not. No one forces you to nest forms, so take this just as a possibility. -Matej Ryan Sonnek wrote: My vote is to not allow for inner forms either. It's too much framework "magic". Wicket is a web framework, and html doesn't allow for nested forms, so this seems totally counter-intuitive. On 11/6/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: but how does this happen? why is the panel that has the search box and the button put _inside_ another form? let me give you the opposite example: right now i create a lot of editor objects that are panels with formcomponents. it would be great if i could have the panel also have a form so i can use an editor by itself and not need an external form. which usecase is more common? -igor On 11/6/06, Johan Compagner <[EMAIL PROTECTED]> wrote: > > I already did that in that other thread. > > One outer form where you can edit some database data and submit it > and an inner form that is just a search box so field and button'. > Then if i submit the edit for the outer form i really don't want to > process > the inner form.. > That inner form could be for example to search a value for that outer > form. > > So i am: > [X] Yes, don't process those pesky little fields > > to me it just doesn't make sense if you do it the other way why have that > inner form > where is the usecase for that? That one i can't think of immediately > > johan > > > On 11/6/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > > > 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
Re: [VOTE] Nested forms - don't process inner form fields in outer form submit
My vote is to not allow for inner forms either. It's too much framework "magic". Wicket is a web framework, and html doesn't allow for nested forms, so this seems totally counter-intuitive. On 11/6/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: but how does this happen? why is the panel that has the search box and the button put _inside_ another form? let me give you the opposite example: right now i create a lot of editor objects that are panels with formcomponents. it would be great if i could have the panel also have a form so i can use an editor by itself and not need an external form. which usecase is more common? -igor On 11/6/06, Johan Compagner <[EMAIL PROTECTED]> wrote: > > I already did that in that other thread. > > One outer form where you can edit some database data and submit it > and an inner form that is just a search box so field and button'. > Then if i submit the edit for the outer form i really don't want to > process > the inner form.. > That inner form could be for example to search a value for that outer > form. > > So i am: > [X] Yes, don't process those pesky little fields > > to me it just doesn't make sense if you do it the other way why have that > inner form > where is the usecase for that? That one i can't think of immediately > > johan > > > On 11/6/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > > > 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 compon
Re: MockWebApplication and WicketTester no longer derived from WebApplication
didnt someone already submit a patch that does this? -igor On 11/6/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: Currently MockWebApplication and WicketTester are derived from WebApplication which requires us to copy & paste code from MyApplication to MyWicketTester which is kind of ugly. I changed MockWebApplication to delegate to an application instead. It seems to work fine but most xxxExpectedResult.html files must be changed. Example test --- test I guess that is ok, but I want to check with you first. Any thought? Juergen
Re: [VOTE] Nested forms - don't process inner form fields in outer form submit
but how does this happen? why is the panel that has the search box and the button put _inside_ another form? let me give you the opposite example: right now i create a lot of editor objects that are panels with formcomponents. it would be great if i could have the panel also have a form so i can use an editor by itself and not need an external form. which usecase is more common? -igor On 11/6/06, Johan Compagner <[EMAIL PROTECTED]> wrote: I already did that in that other thread. One outer form where you can edit some database data and submit it and an inner form that is just a search box so field and button'. Then if i submit the edit for the outer form i really don't want to process the inner form.. That inner form could be for example to search a value for that outer form. So i am: [X] Yes, don't process those pesky little fields to me it just doesn't make sense if you do it the other way why have that inner form where is the usecase for that? That one i can't think of immediately johan On 11/6/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > 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 >
Re: [VOTE] Cutting to the chase: create branch 1.2.x, start 1.3
It should be done now! ;) 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: MockWebApplication and WicketTester no longer derived from WebApplication
if it does the same in the end. go ahead. johan On 11/6/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote: Currently MockWebApplication and WicketTester are derived from WebApplication which requires us to copy & paste code from MyApplication to MyWicketTester which is kind of ugly. I changed MockWebApplication to delegate to an application instead. It seems to work fine but most xxxExpectedResult.html files must be changed. Example test --- test I guess that is ok, but I want to check with you first. Any thought? Juergen
Re: Re: AW: [VOTE] Nested forms - don't process inner form fields in outer form submit
On 11/6/06, Matej Knopp <[EMAIL PROTECTED]> wrote: Well... Semantically span is an inline element. Form is a block element, as well as div. Correct. So I don' think so substituting it for a span is a good idea. Div itself has no styling at all, unless you style it by css. OK, fair enough. 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!
MockWebApplication and WicketTester no longer derived from WebApplication
Currently MockWebApplication and WicketTester are derived from WebApplication which requires us to copy & paste code from MyApplication to MyWicketTester which is kind of ugly. I changed MockWebApplication to delegate to an application instead. It seems to work fine but most xxxExpectedResult.html files must be changed. Example test --- test I guess that is ok, but I want to check with you first. Any thought? Juergen
Re: AW: [VOTE] Nested forms - don't process inner form fields in outer form submit
Does it means that if the inner is replaced with that it might look different (preview different from rendered output)? Juergen On 11/6/06, Matej Knopp <[EMAIL PROTECTED]> wrote: Well... Semantically span is an inline element. Form is a block element, as well as div. So I don' think so substituting it for a span is a good idea. Div itself has no styling at all, unless you style it by css. -Matej Martijn Dashorst wrote: > On 11/6/06, Matej Knopp <[EMAIL PROTECTED]> wrote: >> Every inner form is going to be written to output as div. > > Just one last thing: can we substitute the div with a span? A span > typically has no styling and doesn't affect layout, just like forms. > > Martijn >
Re: AW: [VOTE] Nested forms - don't process inner form fields in outer form submit
Well... Semantically span is an inline element. Form is a block element, as well as div. So I don' think so substituting it for a span is a good idea. Div itself has no styling at all, unless you style it by css. -Matej Martijn Dashorst wrote: On 11/6/06, Matej Knopp <[EMAIL PROTECTED]> wrote: Every inner form is going to be written to output as div. Just one last thing: can we substitute the div with a span? A span typically has no styling and doesn't affect layout, just like forms. Martijn
Re: Re: AW: [VOTE] Nested forms - don't process inner form fields in outer form submit
On 11/6/06, Matej Knopp <[EMAIL PROTECTED]> wrote: Every inner form is going to be written to output as div. Just one last thing: can we substitute the div with a span? A span typically has no styling and doesn't affect layout, just like forms. 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: AW: [VOTE] Nested forms - don't process inner form fields in outer form submit
Yeah, indeed this is a pissing content :) So again, just in case anyone still thinks that we are going to output nested html forms: WE ARE NOT GOING TO OUTPUT NESTED HTML FORMS. Every inner form is going to be written to output as div. Outer form is going to be submitted, but only the inner form is going to be processed. That's it. :) -Matej Martijn Dashorst wrote: 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
Re: License headers
My point is that in checkstyle you are free to enforce both the presence _and absence_ of anything that can be expressed as a regular expression. So that includes the $Id$ tag. That I always enforce inclusion of an $Id$ is just an example. In most of my projects I don't have a lot of merging to do. I can imagine that you would enforce exclusion of $Id$ for Wicket. Regards, Erik. Johan Compagner schreef: i don't hope that #Id# is mandatory! I hate those things. Because those things mess up merging of branches because they constantly change. It is totally stupid that this is the case. A merge should ignore those completely. johan -- Erik van Oosten http://www.day-to-day-stuff.blogspot.com/
Re: License headers
On 11/6/06, Johan Compagner <[EMAIL PROTECTED]> wrote: ...i don't hope that #Id# is mandatory!.. It is not required by the ASF license header requirements, if that's what you mean. -Bertrand
Re: License headers
i don't hope that #Id# is mandatory! I hate those things. Because those things mess up merging of branches because they constantly change. It is totally stupid that this is the case. A merge should ignore those completely. johan On 11/6/06, Erik van Oosten <[EMAIL PROTECTED]> wrote: 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
I already did that in that other thread. One outer form where you can edit some database data and submit it and an inner form that is just a search box so field and button'. Then if i submit the edit for the outer form i really don't want to process the inner form.. That inner form could be for example to search a value for that outer form. So i am: [X] Yes, don't process those pesky little fields to me it just doesn't make sense if you do it the other way why have that inner form where is the usecase for that? That one i can't think of immediately johan On 11/6/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: 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
Yeah, so do I, but lot of people think that should be the default behavior. I personally, don't really care. I'm +-0 on this. So maybe we should make it configurable? -Matej Igor Vaynberg wrote: 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! >> > >> >> >
