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
