michael's message was confusing to me. i wasn't sure if he was talking
about forms or buttons.
or really what his original problem was.
the original idea with buttons was that the onSubmit() method of the
button could be used to
call public methods on the form to do manual processing. i don't know
when it was that went
away. the nice thing about the fact that these methods are all
protected now in Form is that it
keeps form processing code in the form. i kindof like that
encapsulation. it seems like a button
shouldn't really contain a bunch of form processing logic.
what is it that we gain here michael and what exactly is the proposal?
i still don't quite understand
what you're getting at in terms of the current functionality. how
exactly would you change it?
Igor Vaynberg wrote:
Are we talking about making these changes in the form?!? I thought this
started out talking about buttons not forms. I might want to have two
buttons that bypass form processing and do two different things. Right now
its easy to do, just create two buttons and set their
setDefaultFormProcessing(false) and voila. If I want to have two buttons
that actually update my model side by side with the two that don't, that's
easy too.
I think this is a per-button case problem and has nothing to do with the
forms!
-Igor
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jonathan Locke
Sent: Thursday, August 11, 2005 1:59 PM
To: [email protected]
Subject: Re: [Wicket-user] Problem with CompoundPropertyModel
and multiple Submit Buttons
yeah, final would do the trick all right. i could be +1 on
this breakage if it makes everyone including michael
completely happy. onValidSubmit() is a much more
self-explanatory name.
i'm still mentally searching for the best and most
self-evident names here... what about
onHandleSubmit() instead of onCustomSubmit()? then you override
onValidSubmit() if
you just want to deal with valid submits and if you want more
control you override onHandleSubmit() to take over the form
processing yourself... ??
Martijn Dashorst wrote:
Jonathan Locke wrote:
although fixing this is nice idea, keep in mind that we're
going to
break the whole freaking world and people who have never
even joined
this list will be on hear shouting about a breaking change to
something as important as Form.onSubmit. i think it might
be better
to quietly slip in onValidSubmit() with a comment about
how it works
and then have a flag that basically says "yeah, i know
this is going
to change the way forms work"... if you set this flag, then forms
work the way michael suggests.
Luckily, we don't have a manual to speak of, and I can alter the
reference manual to show the one and only way. But I don't want to
take this lightly.
We could also be very vocal on all our forums concerning
the breaking
of the contract. And of course, have a vote, whether our
users like it
or not. I'm +1 for more clarity, and non-silent breaking code. So
making onSubmit final and deprecated sounds like a very
strong signal
;-)
Martijn
Martijn Dashorst wrote:
BTW,
I don't mean that we shouldn't cater for the advanced
user. But we
should keep in mind that both types of user need special care. I
would hate it when Wicket joins the legions of too complicated
frameworks.
I think the proposals made by Jonathan are pretty solid,
and I might
even be +1 on renaming onSubmit() to onValidSubmit(), and
introduce
onCustomSubmit(), removing onSumit() in order to avoid confusion.
Martijn
Martijn Dashorst wrote:
Michael Jouravlev wrote:
Same happens in Wicket, and a lot. Why do you want to do
everything automatically? I want to have an option: to do it
either myself or to delegate it to the framework.
I like having a framework doing lots of things automatically. I
don't want to have to call process(). That is completely
backwards.
In Struts/etc. I have to perform all those tasks myself, or
introduce yet another layer (interceptors, etc). This automatic
handling is what makes Wicket so easy and user friendly.
Now, if I want to override stuff, then it should be
possible, and
the framework should not be in the way (too much). And
now we are
discussing how we can provide the advanced user with the
simplest
means of overriding the default behaviour.
This discussion has been going on too long, so you all
are focused
on how to do the special, advanced case when you want to
override
the default handling. 90% of the time I don't want to
bypass Wicket
form processing. That 90% should be dead simple, taking no extra
coding.
If you need more control, and can't find it in Wicket, then
probably Wicket isn't the framework that will make you happy.
My 2 cents.
Naming:
- setImmediate() is not quite clear IMO, but I also don'
thave too
much experience in other frameworks +0
- setCustomizedFormProcessing()?
Martijn
Michael Jouravlev wrote:
Well, how Wicket is going to be better than Struts or
JSF if you
are doing the same thing? A lot of built-in call sequences that
are hard to override. Same as with Struts
reset/populate/validate.
Everyone can turn off validation by setting parameter
in xml file,
but it is impossible to turn reset or population off.
Same happens in Wicket, and a lot. Why do you want to do
everything automatically? I want to have an option: to do it
either myself or to delegate it to the framework.
Consider above fragment:
// when processing was triggered by a Wicket button and // that
button indicates it wants to be called immediately // (without
validating), call onSubmit right away.
if (submittingButton != null &&
(submittingButton.isImmediate()))
{ submittingButton.onSubmit(); } else { // validation, error
handling, model updating, // delegating submit (to button and
form) ...
}
Throw out this "immediate" flag and just leave it like this:
// when processing was triggered by a Wicket button and // that
button indicates it wants to be called immediately // (without
validating), call onSubmit right away.
if (submittingButton != null)
{
submittingButton.onSubmit();
}
else
{
// validation, error handling, model updating, // delegating
submit (to button and form) ...
}
Then allow me to call default process() method from my
onSubmit()
method, or to call finer-grained validate(), update(), etc.
instead of
process(). This is it. If I want default event handling
(which I
usually will want to), I will call process(). It is so much
simpler to write one line of code and to see what is actually
happening, than to figure out who and when will can
your handler.
Michael.
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software
Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development
Lifecycle
Practices Agile & Plan-Driven Development * Managing Projects &
Teams * Testing & QA Security * Process Improvement &
Measurement
* http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software
Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development
Lifecycle
Practices Agile & Plan-Driven Development * Managing Projects &
Teams * Testing & QA Security * Process Improvement &
Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software
Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices Agile & Plan-Driven Development * Managing Projects &
Teams * Testing & QA Security * Process Improvement &
Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices Agile & Plan-Driven Development * Managing
Projects & Teams
* Testing & QA Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices Agile & Plan-Driven Development * Managing
Projects & Teams
* Testing & QA Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference &
EXPO September 19-22, 2005 * San Francisco, CA * Development
Lifecycle Practices Agile & Plan-Driven Development *
Managing Projects & Teams * Testing & QA Security * Process
Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
