Re: Doubt about form components
Pedro,
personally I love Wicket due its capability to split input value and raw
input. I find it very helpful when user makes typo and have a chance to
correct just sinle char after form submit. It also comes in handy
when the user navigates tabbed panel or wizard which contain empty required
fields - without default form processing lifecycle raw input of component is
filled in and rendered back when user returns back.
It is always possible to subclass core components and provide some sort of
model change listeners.
From my perspective what you are asking about seems to be Wicket
competitors' inherent shortcomings.
Anyway I believe it is a core functionality and nobody is going to break the
world applications.
Pedro H. O. dos Santos wrote:
In the step 3, the user isn't changing the model value, so
setDefaultModelObject don't call internalOnModelChanged. The user intent
that can be update the component markup will fail, unless he call
modelChanged by his own.
On Tue, Feb 23, 2010 at 9:59 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Hi!
I don't see the problem, setDefaultModelObject also clears input via
internalOnModelChanged:
public final Component setDefaultModelObject(final Object object)
{
final IModel model =
(IModel)getDefaultModel();
// Check whether anything can be set at all
if (model == null)
{
throw new IllegalStateException(
Attempt to set model object on null model
of component: +
getPageRelativePath());
}
// Check authorization
if (!isActionAuthorized(ENABLE))
{
throw new UnauthorizedActionException(this,
ENABLE);
}
// Check whether this will result in an actual change
if (!getModelComparator().compare(this, object))
{
modelChanging();
model.setObject(object);
modelChanged();
}
return this;
}
public final void modelChanged()
{
// Call user code
internalOnModelChanged();
onModelChanged();
}
protected void internalOnModelChanged()
{
// If the model for this form component changed, we should
make it
// valid again because there can't be any invalid input
for
it anymore.
valid();
}
public final void valid()
{
clearInput();
onValid();
}
**
Martin
2010/2/23 Pedro Santos pedros...@gmail.com:
Hi Martin, call get or set defaultModel is not the solution, consider
this
another test case:
The new link implementation:
AjaxLink link = new AjaxLink(reload)
{
@Override
public void onClick(AjaxRequestTarget target)
{
textField.setDefaultModelObject(new Integer(30));
target.addComponent(textField);
}
};
new test script:
1- click on the reload link, then you has as expected the text field
markup
presenting the new value on model
2 - type something wrong on the text field, like some non numeric
characters
3 - submit the form. At this moment, you has your forms components on
the
server with the raw input
3 - press reload link, to update the markup of the component
4 - you has now an text field markup presenting the wrong user typed
value,
and the original one on the component model
For this case modelChanged or clearInput method solves the problem of
render
the form component with his actual model value.
It brings me an question, does store the raw input on server worth?
pro: user can go back to his form, and has all his input back
cons: he already get his input back on the render parse, and the
browser
can
remember just using html meta tags that require cache
On Tue, Feb 23, 2010 at 9:06 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Yes.. don't use referenceToModel. Instead call
textField.getDefaultModelObject();
**
Martin
2010/2/23 Pedro Santos pedros...@gmail.com:
Hi Martin, consider this form:
java code:
Form form = new Form(form);
add(form);
final TextFieldInteger textField = new TextField(tf, new
Model());
textField.setType(Integer.class);
textField.setOutputMarkupId(true);
form.add(textField);
AjaxLink link = new AjaxLink(reload) {
public void onClick(AjaxRequestTarget target) {
IModel referenceToModel =
textField.getDefaultModel();
referenceToModel.setObject(new Integer(30));
Re: Doubt about form components
Hi Martin, consider this form:
java code:
Form form = new Form(form);
add(form);
final TextFieldInteger textField = new TextField(tf, new
Model());
textField.setType(Integer.class);
textField.setOutputMarkupId(true);
form.add(textField);
AjaxLink link = new AjaxLink(reload) {
public void onClick(AjaxRequestTarget target) {
IModel referenceToModel = textField.getDefaultModel();
referenceToModel.setObject(new Integer(30));
target.addComponent(textField);
}};
form.add(link);
form.add(new FeedbackPanel(fp));
markup code:
form wicket:id=form
input wicket:id=tf type=text /
a wicket:id=reloadreload/a
input type=submit /
div wicket:id=fp /div
/form
In the browser:
1 - you type something wrong on the text field, like some non numeric
characters
2 - submit the form. At this moment, you has your forms components on the
server with the raw input
3 - press reload link, to change the value on the text field model
4 - you has now an text field presenting the wrong user typed value, and the
new one on the component model on server.
On Mon, Feb 22, 2010 at 5:55 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Hi!
What's the difference whether it's thrown away or not if the next step
is re-submit with new values?
**
Martin
2010/2/22 Pedro Santos pedros...@gmail.com:
IMO the form processing can be:
1. validate
2. detect error
3. keep rawinput
4. re-render error components with red border AND rawinput
4.1. throw away the raw input in some detach method
5. user retry form submit
6. all form components get they raw input again since they get rendered
before some detach method clear they raw input, no need to maintain those
values on the server
--
Pedro Henrique Oliveira dos Santos
--
Pedro Henrique Oliveira dos Santos
Re: Doubt about form components
Yes.. don't use referenceToModel. Instead call
textField.getDefaultModelObject();
**
Martin
2010/2/23 Pedro Santos pedros...@gmail.com:
Hi Martin, consider this form:
java code:
Form form = new Form(form);
add(form);
final TextFieldInteger textField = new TextField(tf, new
Model());
textField.setType(Integer.class);
textField.setOutputMarkupId(true);
form.add(textField);
AjaxLink link = new AjaxLink(reload) {
public void onClick(AjaxRequestTarget target) {
IModel referenceToModel = textField.getDefaultModel();
referenceToModel.setObject(new Integer(30));
target.addComponent(textField);
}};
form.add(link);
form.add(new FeedbackPanel(fp));
markup code:
form wicket:id=form
input wicket:id=tf type=text /
a wicket:id=reloadreload/a
input type=submit /
div wicket:id=fp /div
/form
In the browser:
1 - you type something wrong on the text field, like some non numeric
characters
2 - submit the form. At this moment, you has your forms components on the
server with the raw input
3 - press reload link, to change the value on the text field model
4 - you has now an text field presenting the wrong user typed value, and the
new one on the component model on server.
On Mon, Feb 22, 2010 at 5:55 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Hi!
What's the difference whether it's thrown away or not if the next step
is re-submit with new values?
**
Martin
2010/2/22 Pedro Santos pedros...@gmail.com:
IMO the form processing can be:
1. validate
2. detect error
3. keep rawinput
4. re-render error components with red border AND rawinput
4.1. throw away the raw input in some detach method
5. user retry form submit
6. all form components get they raw input again since they get rendered
before some detach method clear they raw input, no need to maintain those
values on the server
--
Pedro Henrique Oliveira dos Santos
--
Pedro Henrique Oliveira dos Santos
Re: Doubt about form components
Or, call modelChanged()?
On Tue, Feb 23, 2010 at 7:06 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Yes.. don't use referenceToModel. Instead call
textField.getDefaultModelObject();
**
Martin
2010/2/23 Pedro Santos pedros...@gmail.com:
Hi Martin, consider this form:
java code:
Form form = new Form(form);
add(form);
final TextFieldInteger textField = new TextField(tf, new
Model());
textField.setType(Integer.class);
textField.setOutputMarkupId(true);
form.add(textField);
AjaxLink link = new AjaxLink(reload) {
public void onClick(AjaxRequestTarget target) {
IModel referenceToModel = textField.getDefaultModel();
referenceToModel.setObject(new Integer(30));
target.addComponent(textField);
}};
form.add(link);
form.add(new FeedbackPanel(fp));
markup code:
form wicket:id=form
input wicket:id=tf type=text /
a wicket:id=reloadreload/a
input type=submit /
div wicket:id=fp /div
/form
In the browser:
1 - you type something wrong on the text field, like some non numeric
characters
2 - submit the form. At this moment, you has your forms components on the
server with the raw input
3 - press reload link, to change the value on the text field model
4 - you has now an text field presenting the wrong user typed value, and the
new one on the component model on server.
On Mon, Feb 22, 2010 at 5:55 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Hi!
What's the difference whether it's thrown away or not if the next step
is re-submit with new values?
**
Martin
2010/2/22 Pedro Santos pedros...@gmail.com:
IMO the form processing can be:
1. validate
2. detect error
3. keep rawinput
4. re-render error components with red border AND rawinput
4.1. throw away the raw input in some detach method
5. user retry form submit
6. all form components get they raw input again since they get rendered
before some detach method clear they raw input, no need to maintain those
values on the server
--
Pedro Henrique Oliveira dos Santos
--
Pedro Henrique Oliveira dos Santos
Re: Doubt about form components
In the step 3, the user isn't changing the model value, so
setDefaultModelObject don't call internalOnModelChanged. The user intent
that can be update the component markup will fail, unless he call
modelChanged by his own.
On Tue, Feb 23, 2010 at 9:59 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Hi!
I don't see the problem, setDefaultModelObject also clears input via
internalOnModelChanged:
public final Component setDefaultModelObject(final Object object)
{
final IModelObject model =
(IModelObject)getDefaultModel();
// Check whether anything can be set at all
if (model == null)
{
throw new IllegalStateException(
Attempt to set model object on null model
of component: +
getPageRelativePath());
}
// Check authorization
if (!isActionAuthorized(ENABLE))
{
throw new UnauthorizedActionException(this, ENABLE);
}
// Check whether this will result in an actual change
if (!getModelComparator().compare(this, object))
{
modelChanging();
model.setObject(object);
modelChanged();
}
return this;
}
public final void modelChanged()
{
// Call user code
internalOnModelChanged();
onModelChanged();
}
protected void internalOnModelChanged()
{
// If the model for this form component changed, we should
make it
// valid again because there can't be any invalid input for
it anymore.
valid();
}
public final void valid()
{
clearInput();
onValid();
}
**
Martin
2010/2/23 Pedro Santos pedros...@gmail.com:
Hi Martin, call get or set defaultModel is not the solution, consider
this
another test case:
The new link implementation:
AjaxLink link = new AjaxLink(reload)
{
@Override
public void onClick(AjaxRequestTarget target)
{
textField.setDefaultModelObject(new Integer(30));
target.addComponent(textField);
}
};
new test script:
1- click on the reload link, then you has as expected the text field
markup
presenting the new value on model
2 - type something wrong on the text field, like some non numeric
characters
3 - submit the form. At this moment, you has your forms components on the
server with the raw input
3 - press reload link, to update the markup of the component
4 - you has now an text field markup presenting the wrong user typed
value,
and the original one on the component model
For this case modelChanged or clearInput method solves the problem of
render
the form component with his actual model value.
It brings me an question, does store the raw input on server worth?
pro: user can go back to his form, and has all his input back
cons: he already get his input back on the render parse, and the browser
can
remember just using html meta tags that require cache
On Tue, Feb 23, 2010 at 9:06 AM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
Yes.. don't use referenceToModel. Instead call
textField.getDefaultModelObject();
**
Martin
2010/2/23 Pedro Santos pedros...@gmail.com:
Hi Martin, consider this form:
java code:
Form form = new Form(form);
add(form);
final TextFieldInteger textField = new TextField(tf, new
Model());
textField.setType(Integer.class);
textField.setOutputMarkupId(true);
form.add(textField);
AjaxLink link = new AjaxLink(reload) {
public void onClick(AjaxRequestTarget target) {
IModel referenceToModel = textField.getDefaultModel();
referenceToModel.setObject(new Integer(30));
target.addComponent(textField);
}};
form.add(link);
form.add(new FeedbackPanel(fp));
markup code:
form wicket:id=form
input wicket:id=tf type=text /
a wicket:id=reloadreload/a
input type=submit /
div wicket:id=fp /div
/form
In the browser:
1 - you type something wrong on the text field, like some non numeric
characters
2 - submit the form. At this moment, you has your forms components on
the
server with the raw input
3 - press reload link, to change the value on the text field model
4 - you has now an text field presenting the wrong user typed value,
and
the
new one on the component model on server.
On Mon, Feb 22, 2010 at 5:55 PM, Martin Makundi
Re: Doubt about form components
Hi! Hi, the form component clearInput method that clean this state is called on the valid method. I'm trying to guess why the form component keep his raw input after an form processing with errors. I can't figure out why don't clear the raw input in this situation, since on the next form submit the raw input will to be updated any way. I don't know the original design but if you (e.g., ajax) redraw some components it's goddamn useful to have the raw input. Say that you redraw erroneous components with red border like I do. You would lose the raw value if you clear that and the user would lose the input. 3 - the user perform some ajax work that update some form components model objects, and add then to the response. If you chaneg model value you should call setmodelobject which clears raw input (note: only if model really changes)! ** Martin -- Pedro Henrique Oliveira dos Santos
Re: Doubt about form components
Hi Martin, thanks for the reply! Hi, the form component clearInput method that clean this state is called on the valid method. I'm trying to guess why the form component keep his raw input after an form processing with errors. I can't figure out why don't clear the raw input in this situation, since on the next form submit the raw input will to be updated any way. I don't know the original design but if you (e.g., ajax) redraw some components it's goddamn useful to have the raw input. Say that you redraw erroneous components with red border like I do. You would lose the raw value if you clear that and the user would lose the input. Actually this statement make sense if you are telling me: is very useful keep the raw input during all rendering process. After render parse, I can't see any good reason to maintain the raw input. 3 - the user perform some ajax work that update some form components model objects, and add then to the response. If you chaneg model value you should call setmodelobject which clears raw input (note: only if model really changes)! Consider that the user can use the same model instance on more than one component. Or that he can have controllers that only keep reference to the model. ** Martin -- Pedro Henrique Oliveira dos Santos -- Pedro Henrique Oliveira dos Santos
Re: Doubt about form components
Hi! I don't know the original design but if you (e.g., ajax) redraw some components it's goddamn useful to have the raw input. Say that you redraw erroneous components with red border like I do. You would lose the raw value if you clear that and the user would lose the input. Actually this statement make sense if you are telling me: is very useful keep the raw input during all rendering process. After render parse, I can't see any good reason to maintain the raw input. I must elaborate: 1. validate 2. detect error 3. keep rawinput 4. re-render error components with red border AND rawinput 5. user retry form submit If you chaneg model value you should call setmodelobject which clears raw input (note: only if model really changes)! Consider that the user can use the same model instance on more than one component. Or that he can have controllers that only keep reference to the model. Well.. then you just call clearinput yourself or implement a wrapped model with something happening when it changes... ... or maybe the gurus here have even better suggestions for your special case. ** Martin
Re: Doubt about form components
IMO the form processing can be: 1. validate 2. detect error 3. keep rawinput 4. re-render error components with red border AND rawinput 4.1. throw away the raw input in some detach method 5. user retry form submit 6. all form components get they raw input again since they get rendered before some detach method clear they raw input, no need to maintain those values on the server -- Pedro Henrique Oliveira dos Santos
Re: Doubt about form components
Hi! What's the difference whether it's thrown away or not if the next step is re-submit with new values? ** Martin 2010/2/22 Pedro Santos pedros...@gmail.com: IMO the form processing can be: 1. validate 2. detect error 3. keep rawinput 4. re-render error components with red border AND rawinput 4.1. throw away the raw input in some detach method 5. user retry form submit 6. all form components get they raw input again since they get rendered before some detach method clear they raw input, no need to maintain those values on the server -- Pedro Henrique Oliveira dos Santos
Re: Doubt about form components
if a user refreshes the browser or does some other action (go first to another form in another page and back again) then we still can render the latest user output just fine the next time On Mon, Feb 22, 2010 at 21:42, Pedro Santos pedros...@gmail.com wrote: IMO the form processing can be: 1. validate 2. detect error 3. keep rawinput 4. re-render error components with red border AND rawinput 4.1. throw away the raw input in some detach method 5. user retry form submit 6. all form components get they raw input again since they get rendered before some detach method clear they raw input, no need to maintain those values on the server -- Pedro Henrique Oliveira dos Santos
Re: Doubt
Perhaps the Wicket framework needs some way to call it ;) Regards, Erik. Pedro Santos wrote: Why do onClick method from Link is public? Who would want or need to call it from outside? -- Send from my SMTP compliant software Erik van Oosten http://day-to-day-stuff.blogspot.com/
Re: Doubt
From an instance of what class, other than Link and it subclasses? On Fri, Feb 5, 2010 at 1:20 PM, Erik van Oosten e.vanoos...@grons.nlwrote: Perhaps the Wicket framework needs some way to call it ;) Regards, Erik. Pedro Santos wrote: Why do onClick method from Link is public? Who would want or need to call it from outside? -- Send from my SMTP compliant software Erik van Oosten http://day-to-day-stuff.blogspot.com/ -- Pedro Henrique Oliveira dos Santos
Re: Doubt
Perhaps in IVisitor? Martijn On Fri, Feb 5, 2010 at 4:33 PM, Pedro Santos pedros...@gmail.com wrote: From an instance of what class, other than Link and it subclasses? On Fri, Feb 5, 2010 at 1:20 PM, Erik van Oosten e.vanoos...@grons.nlwrote: Perhaps the Wicket framework needs some way to call it ;) Regards, Erik. Pedro Santos wrote: Why do onClick method from Link is public? Who would want or need to call it from outside? -- Send from my SMTP compliant software Erik van Oosten http://day-to-day-stuff.blogspot.com/ -- Pedro Henrique Oliveira dos Santos -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.4 increases type safety for web applications Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4
Re: Doubt about wicket ajax
It's line 1003 in trunk, and associated with commit 518643. So, looking at that commit yields this: svn log -r 518643 r518643 | knopp | 2007-03-15 09:40:44 -0500 (Thu, 15 Mar 2007) | 1 line fixed a problem with ajax request initiated from success script -- Jeremy Thomerson http://www.wickettraining.com On Fri, Jan 22, 2010 at 6:45 AM, Pedro Santos pedros...@gmail.com wrote: Why do Wicket call abort method on XMLHttpRequest after process it? (wicket-ajax.js line 1001) It doesn't cause any damage, just the response get the error flag set to true. http://www.w3.org/TR/XMLHttpRequest/#the-abort-method -- Pedro Henrique Oliveira dos Santos
