sounds to me like we still don't quite know what it is. how about this?
you guys agree on this and then go do the refactor and see how it works.
if the experiment seems to be great, we can take a look at it and vote
on that. this way, we're not talking around in circles like we have been
for the past couple days.
Igor Vaynberg wrote:
LOL, ok here it is as far as I can see it, and we can vote on it.
Interface Ibuttonlistener { public void onButtonClicked() }
Public abstract class AbstractButton extends FormComponent {
(abstract?) void onClick();
... All common stuff goes here, if there isnt any we can get rid of
this class ...
}
Public class Button extends AbstractButton implements Ibuttonlistener {
...
final void onButtonClicked() {
onClick();
}
}
Public class SubmitButton extends AbstractButton implements IButtonListener
{
...
final void onButtonClicked() {
getForm().process();
onClick();
}
}
Lets worry about the implementation details later, the gist is:
You have a Button class which works like an immediate button, and you have a
SubmitButton class which works like a non-immediate button. In either class
you can override onClick() - in SubmitButton class this gets called AFTER
the form has been processed.
-Igor
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jonathan Locke
Sent: Thursday, August 11, 2005 4:47 PM
To: [email protected]
Subject: Re: [Wicket-user] Problem with CompoundPropertyModel
and multiple Submit Buttons
i just can't follow this discussion any more. please let me
know when everyone agrees so i can think and/or vote on the proposal.
thanks,
jon
Igor Vaynberg wrote:
Its not that I don't trust the user, the point is to
automate the 90%
use case which is to have something happen after the default form
processing updates your model.
The internalOnClick will be finalized. So if you don't want default
form processing you extend from Button, and if you do want it you
extend from SubmitButton and onclick in that class gets called AFTER
the form has been processed and model updated.
-Igor
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Michael
Jouravlev
Sent: Thursday, August 11, 2005 4:30 PM
To: [email protected]
Subject: Re: [Wicket-user] Problem with CompoundPropertyModel and
multiple Submit Buttons
So the call chain would be:
Button.internalOnClick()
form.process();
onClick();
Where I can override onClick() for regular button, or override
internalOnClick() for Cancel button, right?
I still cannot get why it cannot simply be like your
previous version,
but without onSubmit():
Button {
public void onClick() {}
}
SubmitButton {
public void onClick() {
form.process();
// add custom code here
}
}
What, you do not trust a user, who might throw away
form.process() call?
Michael.
On 8/11/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
OR
To make it cleaner the button can have an internal method
Button {
public void internalOnClick() {
onClick();
}
public void onClick() {}
}
SubmitButton {
public void internalOnClick() {
form.process();
onClick();
}
public void onClick() {}
}
Yes, I think that's much better
-------------------------------------------------------
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
