Why don't we just make it the simple way like SWING and have a Button
that acts like a Button?
When i make a new button i will juust have something like
Button.onClick(), not Button.unSubmit() not Form.onSubmit() or what ever.
I don't want to care also how a button is implemented in HTML/HTTP.
That's exactly the reason why wicket is so nice:
It behaves like a "real" Application rather than some crapy HTML/HTTP
stuff...
I think wicket should hide all this implementation Details of HTML and
the HTTP Protocol and should act like a real Application (Like SWIG does
for exmaple).
So my suggestion would be:
One class Button with .onClick() and in the onClick method i can do what
ever i want. And for those who want to have it like it's now a
FormProcessButton class should do the job.
Let's just make a Button what a Button is: Something i click on and a
method is called then (Nice event handling! Something we all have missed
in HTML/HTTP and now we got it with wicket. So please don't destroy this
nice feature with getting to much specific to HTML/HTTP implementation
Details).
I hop you understand my viewpoint.
Thanks,
Dave
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.
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
