Re: svn commit: r1051262 - in /wicket/trunk/wicket-datetime/src: main/java/org/apache/wicket/extensions/yui/calendar/ test/java/org/apache/wicket/extensions/yui/calendar/
DateField is no more FormComponentPanel, but now extends DateTimeField and
just sets the time related components to invisible.
Should we do the same for the recently added TimeField ?
On Mon, Dec 20, 2010 at 8:51 PM, jdonners...@apache.org wrote:
Author: jdonnerstag
Date: Mon Dec 20 19:51:09 2010
New Revision: 1051262
URL: http://svn.apache.org/viewvc?rev=1051262view=rev
Log:
WICKET-3249 fixed DateConverter improperly converts time, causing different
results between DateField and DateTimeField
Removed:
wicket/trunk/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/DateField.html
Modified:
wicket/trunk/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/DateField.java
wicket/trunk/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/DateTimeField.java
wicket/trunk/wicket-datetime/src/test/java/org/apache/wicket/extensions/yui/calendar/DatePickerTest.java
Modified:
wicket/trunk/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/DateField.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/DateField.java?rev=1051262r1=1051261r2=1051262view=diff
==
---
wicket/trunk/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/DateField.java
(original)
+++
wicket/trunk/wicket-datetime/src/main/java/org/apache/wicket/extensions/yui/calendar/DateField.java
Mon Dec 20 19:51:09 2010
@@ -19,10 +19,7 @@ package org.apache.wicket.extensions.yui
import java.util.Date;
import org.apache.wicket.datetime.markup.html.form.DateTextField;
-import org.apache.wicket.markup.html.form.FormComponentPanel;
import org.apache.wicket.model.IModel;
-import org.apache.wicket.model.PropertyModel;
-import org.joda.time.MutableDateTime;
/**
* Works on a {...@link java.util.Date} object. Displays a {...@link
DateTextField} and a
@@ -53,14 +50,10 @@ import org.joda.time.MutableDateTime;
*
* @author eelcohillenius
*/
-public class DateField extends FormComponentPanelDate
+public class DateField extends DateTimeField
{
private static final long serialVersionUID = 1L;
- private MutableDateTime date;
-
- private DateTextField dateField;
-
/**
* Construct.
*
@@ -80,116 +73,9 @@ public class DateField extends FormCompo
public DateField(String id, IModelDate model)
{
super(id, model);
- setType(Date.class);
- }
-
- /**
-* Gets date.
-*
-* @return date
-*/
- public Date getDate()
- {
- return (date != null) ? date.toDate() : null;
- }
-
- /**
-* @see org.apache.wicket.markup.html.form.FormComponent#getInput()
-*/
- @Override
- public String getInput()
- {
- // since we override convertInput, we can let this method
return a value
- // that is just suitable for error reporting
- return dateField.getInput();
- }
-
- /**
-* Sets date.
-*
-* @param date
-*date
-*/
- public void setDate(Date date)
- {
- this.date = (date != null) ? new MutableDateTime(date) :
null;
- setDefaultModelObject(date);
- }
-
- /**
-* Sets the converted input. In this case, we're really just
interested in the nested date
-* field, as that is the element that receives the real user input.
So we're just passing that
-* on.
-* p
-* Note that overriding this method is a better option than
overriding {...@link #updateModel()}
-* like the first versions of this class did. The reason for that
is that this method can be
-* used by form validators without having to depend on the actual
model being updated, and this
-* method is called by the default implementation of {...@link
#updateModel()} anyway (so we don't
-* have to override that anymore).
-* /p
-*
-* @see
org.apache.wicket.markup.html.form.FormComponent#convertInput()
-*/
- @Override
- protected void convertInput()
- {
- setConvertedInput(dateField.getConvertedInput());
- }
-
- /**
-* create a new {...@link DateTextField} instance to be added to this
panel.
-*
-* @param id
-*The id to be used when creating the component
-* @param dateFieldModel
-*model that should be used by the {...@link
DateTextField}
-* @return a new date text field instance
-*/
- protected DateTextField newDateTextField(final String id,
- final
Re: Tester loses all submit parameters after ajax call
Hi Zilvinas, thank u for the test! We actually have different issues. I described mine at https://issues.apache.org/jira/browse/WICKET-3272 The tester setup the next request cycle just after process the request triggered by the mocked AJAX event. It differs from 1.4 where the request setup was made just before the next processRequestCycle. So in the 1.5 you don't need methods like setParametersForNextRequest, because the current request set on tester is the one that will be dispatched. So if you want to access it after process the request, you need to use methods like getLastRequest. I'm sending your test case back with mentioned changes. On Sat, Dec 18, 2010 at 4:14 PM, zkybar...@gmail.com zkybar...@gmail.comwrote: Pedro, One more thing, i have updated WicketTesterTest, which fails with issue i have described. I'm attaching patch file, maybe it will be of any help for you. On Sat, Dec 18, 2010 at 8:07 PM, zkybar...@gmail.com zkybar...@gmail.comwrote: Pedro, Thanks for reply. Yeah i have workaround for this - i just reset submit parameters from last request to current request. On Sat, Dec 18, 2010 at 6:30 PM, Pedro Santos pedros...@gmail.comwrote: Hi Zilvinas, I'm taking a look at your described issue, for now try to set the parameter as a POST one. On Sat, Dec 18, 2010 at 2:15 PM, zkybar...@gmail.com zkybar...@gmail.comwrote: Hello, I'm experiencing strange behavior with WicketTester in 1.5 when using FormTester with ajax events. It works as follows: 1. Set some value via the FormTester to input field. 2. Invoke ajax event. In my case behaviour is AjaxFormComponentUpdatingBehavior. 3. After the ajax event was executed input fields getInput method returns null. And it should, since there are no submit parameters available anymore. Is that bug? It was working in 1.4, so my guess that its bug. Greetings, Zilvinas. -- Pedro Henrique Oliveira dos Santos -- Pedro Henrique Oliveira dos Santos
Re: Tester loses all submit parameters after ajax call
Hi Pedro, Yeah those are different issues. I understand that in 1.5 its different how tester works. I know how can i access those parameters through request. The issue i have, is that if you do ajax call in the middle between setting value to input and submiting from, FormTester loses that value (unless of course you reset parameters from previous request to current). So, my question is, what should I do with the issue I have, do you want me to create jira task? Is it bug at all? On Tue, Dec 21, 2010 at 4:31 PM, Pedro Santos pedros...@gmail.com wrote: Hi Zilvinas, thank u for the test! We actually have different issues. I described mine at https://issues.apache.org/jira/browse/WICKET-3272 The tester setup the next request cycle just after process the request triggered by the mocked AJAX event. It differs from 1.4 where the request setup was made just before the next processRequestCycle. So in the 1.5 you don't need methods like setParametersForNextRequest, because the current request set on tester is the one that will be dispatched. So if you want to access it after process the request, you need to use methods like getLastRequest. I'm sending your test case back with mentioned changes. On Sat, Dec 18, 2010 at 4:14 PM, zkybar...@gmail.com zkybar...@gmail.comwrote: Pedro, One more thing, i have updated WicketTesterTest, which fails with issue i have described. I'm attaching patch file, maybe it will be of any help for you. On Sat, Dec 18, 2010 at 8:07 PM, zkybar...@gmail.com zkybar...@gmail.com wrote: Pedro, Thanks for reply. Yeah i have workaround for this - i just reset submit parameters from last request to current request. On Sat, Dec 18, 2010 at 6:30 PM, Pedro Santos pedros...@gmail.comwrote: Hi Zilvinas, I'm taking a look at your described issue, for now try to set the parameter as a POST one. On Sat, Dec 18, 2010 at 2:15 PM, zkybar...@gmail.com zkybar...@gmail.comwrote: Hello, I'm experiencing strange behavior with WicketTester in 1.5 when using FormTester with ajax events. It works as follows: 1. Set some value via the FormTester to input field. 2. Invoke ajax event. In my case behaviour is AjaxFormComponentUpdatingBehavior. 3. After the ajax event was executed input fields getInput method returns null. And it should, since there are no submit parameters available anymore. Is that bug? It was working in 1.4, so my guess that its bug. Greetings, Zilvinas. -- Pedro Henrique Oliveira dos Santos -- Pedro Henrique Oliveira dos Santos
Re: Tester loses all submit parameters after ajax call
IMO it is not a bug, rather an improvement: set the form components value as parameter in form submit request. the scenario is: - a new form is created - a form components receive a new value in the first submit - in the second submit the new value at the form component didn't get add as an request parameter, like if the user manually removed the text in an text field for instance, or like if the form component get invisible. I don't know if FormTester was designed to simulate a second submit. On Tue, Dec 21, 2010 at 1:15 PM, zkybar...@gmail.com zkybar...@gmail.comwrote: Hi Pedro, Yeah those are different issues. I understand that in 1.5 its different how tester works. I know how can i access those parameters through request. The issue i have, is that if you do ajax call in the middle between setting value to input and submiting from, FormTester loses that value (unless of course you reset parameters from previous request to current). So, my question is, what should I do with the issue I have, do you want me to create jira task? Is it bug at all? On Tue, Dec 21, 2010 at 4:31 PM, Pedro Santos pedros...@gmail.com wrote: Hi Zilvinas, thank u for the test! We actually have different issues. I described mine at https://issues.apache.org/jira/browse/WICKET-3272 The tester setup the next request cycle just after process the request triggered by the mocked AJAX event. It differs from 1.4 where the request setup was made just before the next processRequestCycle. So in the 1.5 you don't need methods like setParametersForNextRequest, because the current request set on tester is the one that will be dispatched. So if you want to access it after process the request, you need to use methods like getLastRequest. I'm sending your test case back with mentioned changes. On Sat, Dec 18, 2010 at 4:14 PM, zkybar...@gmail.com zkybar...@gmail.comwrote: Pedro, One more thing, i have updated WicketTesterTest, which fails with issue i have described. I'm attaching patch file, maybe it will be of any help for you. On Sat, Dec 18, 2010 at 8:07 PM, zkybar...@gmail.com zkybar...@gmail.com wrote: Pedro, Thanks for reply. Yeah i have workaround for this - i just reset submit parameters from last request to current request. On Sat, Dec 18, 2010 at 6:30 PM, Pedro Santos pedros...@gmail.com wrote: Hi Zilvinas, I'm taking a look at your described issue, for now try to set the parameter as a POST one. On Sat, Dec 18, 2010 at 2:15 PM, zkybar...@gmail.com zkybar...@gmail.comwrote: Hello, I'm experiencing strange behavior with WicketTester in 1.5 when using FormTester with ajax events. It works as follows: 1. Set some value via the FormTester to input field. 2. Invoke ajax event. In my case behaviour is AjaxFormComponentUpdatingBehavior. 3. After the ajax event was executed input fields getInput method returns null. And it should, since there are no submit parameters available anymore. Is that bug? It was working in 1.4, so my guess that its bug. Greetings, Zilvinas. -- Pedro Henrique Oliveira dos Santos -- Pedro Henrique Oliveira dos Santos -- Pedro Henrique Oliveira dos Santos
Re: Tester loses all submit parameters after ajax call
In the 1.4 the executeAjaxEvent method do not create an request to be processed as in the 1.5. I prefer how it works in the 1.5, because when we don't use an AJAX request to trigger the default request cycle we need some hack in the tester, like: checkUsability. Perhaps we can even remove this method in the 1.5. On Tue, Dec 21, 2010 at 1:40 PM, Pedro Santos pedros...@gmail.com wrote: IMO it is not a bug, rather an improvement: set the form components value as parameter in form submit request. the scenario is: - a new form is created - a form components receive a new value in the first submit - in the second submit the new value at the form component didn't get add as an request parameter, like if the user manually removed the text in an text field for instance, or like if the form component get invisible. I don't know if FormTester was designed to simulate a second submit. On Tue, Dec 21, 2010 at 1:15 PM, zkybar...@gmail.com zkybar...@gmail.comwrote: Hi Pedro, Yeah those are different issues. I understand that in 1.5 its different how tester works. I know how can i access those parameters through request. The issue i have, is that if you do ajax call in the middle between setting value to input and submiting from, FormTester loses that value (unless of course you reset parameters from previous request to current). So, my question is, what should I do with the issue I have, do you want me to create jira task? Is it bug at all? On Tue, Dec 21, 2010 at 4:31 PM, Pedro Santos pedros...@gmail.com wrote: Hi Zilvinas, thank u for the test! We actually have different issues. I described mine at https://issues.apache.org/jira/browse/WICKET-3272 The tester setup the next request cycle just after process the request triggered by the mocked AJAX event. It differs from 1.4 where the request setup was made just before the next processRequestCycle. So in the 1.5 you don't need methods like setParametersForNextRequest, because the current request set on tester is the one that will be dispatched. So if you want to access it after process the request, you need to use methods like getLastRequest. I'm sending your test case back with mentioned changes. On Sat, Dec 18, 2010 at 4:14 PM, zkybar...@gmail.com zkybar...@gmail.comwrote: Pedro, One more thing, i have updated WicketTesterTest, which fails with issue i have described. I'm attaching patch file, maybe it will be of any help for you. On Sat, Dec 18, 2010 at 8:07 PM, zkybar...@gmail.com zkybar...@gmail.com wrote: Pedro, Thanks for reply. Yeah i have workaround for this - i just reset submit parameters from last request to current request. On Sat, Dec 18, 2010 at 6:30 PM, Pedro Santos pedros...@gmail.com wrote: Hi Zilvinas, I'm taking a look at your described issue, for now try to set the parameter as a POST one. On Sat, Dec 18, 2010 at 2:15 PM, zkybar...@gmail.com zkybar...@gmail.comwrote: Hello, I'm experiencing strange behavior with WicketTester in 1.5 when using FormTester with ajax events. It works as follows: 1. Set some value via the FormTester to input field. 2. Invoke ajax event. In my case behaviour is AjaxFormComponentUpdatingBehavior. 3. After the ajax event was executed input fields getInput method returns null. And it should, since there are no submit parameters available anymore. Is that bug? It was working in 1.4, so my guess that its bug. Greetings, Zilvinas. -- Pedro Henrique Oliveira dos Santos -- Pedro Henrique Oliveira dos Santos -- Pedro Henrique Oliveira dos Santos -- Pedro Henrique Oliveira dos Santos
Re: Tester loses all submit parameters after ajax call
On Tue, Dec 21, 2010 at 5:04 PM, Pedro Santos pedros...@gmail.com wrote: In the 1.4 the executeAjaxEvent method do not create an request to be processed as in the 1.5. I prefer how it works in the 1.5, because when we don't use an AJAX request to trigger the default request cycle we need some hack in the tester, like: checkUsability. Perhaps we can even remove this method in the 1.5. checkUsability() is there to stop requests to invisible/disabled components/behaviors I think WicketTester call trace doesn't reach to RequestListenerInterface where we recently added checks for that in the real environment On Tue, Dec 21, 2010 at 1:40 PM, Pedro Santos pedros...@gmail.com wrote: IMO it is not a bug, rather an improvement: set the form components value as parameter in form submit request. the scenario is: - a new form is created - a form components receive a new value in the first submit - in the second submit the new value at the form component didn't get add as an request parameter, like if the user manually removed the text in an text field for instance, or like if the form component get invisible. I don't know if FormTester was designed to simulate a second submit. On Tue, Dec 21, 2010 at 1:15 PM, zkybar...@gmail.com zkybar...@gmail.comwrote: Hi Pedro, Yeah those are different issues. I understand that in 1.5 its different how tester works. I know how can i access those parameters through request. The issue i have, is that if you do ajax call in the middle between setting value to input and submiting from, FormTester loses that value (unless of course you reset parameters from previous request to current). So, my question is, what should I do with the issue I have, do you want me to create jira task? Is it bug at all? On Tue, Dec 21, 2010 at 4:31 PM, Pedro Santos pedros...@gmail.com wrote: Hi Zilvinas, thank u for the test! We actually have different issues. I described mine at https://issues.apache.org/jira/browse/WICKET-3272 The tester setup the next request cycle just after process the request triggered by the mocked AJAX event. It differs from 1.4 where the request setup was made just before the next processRequestCycle. So in the 1.5 you don't need methods like setParametersForNextRequest, because the current request set on tester is the one that will be dispatched. So if you want to access it after process the request, you need to use methods like getLastRequest. I'm sending your test case back with mentioned changes. On Sat, Dec 18, 2010 at 4:14 PM, zkybar...@gmail.com zkybar...@gmail.comwrote: Pedro, One more thing, i have updated WicketTesterTest, which fails with issue i have described. I'm attaching patch file, maybe it will be of any help for you. On Sat, Dec 18, 2010 at 8:07 PM, zkybar...@gmail.com zkybar...@gmail.com wrote: Pedro, Thanks for reply. Yeah i have workaround for this - i just reset submit parameters from last request to current request. On Sat, Dec 18, 2010 at 6:30 PM, Pedro Santos pedros...@gmail.com wrote: Hi Zilvinas, I'm taking a look at your described issue, for now try to set the parameter as a POST one. On Sat, Dec 18, 2010 at 2:15 PM, zkybar...@gmail.com zkybar...@gmail.comwrote: Hello, I'm experiencing strange behavior with WicketTester in 1.5 when using FormTester with ajax events. It works as follows: 1. Set some value via the FormTester to input field. 2. Invoke ajax event. In my case behaviour is AjaxFormComponentUpdatingBehavior. 3. After the ajax event was executed input fields getInput method returns null. And it should, since there are no submit parameters available anymore. Is that bug? It was working in 1.4, so my guess that its bug. Greetings, Zilvinas. -- Pedro Henrique Oliveira dos Santos -- Pedro Henrique Oliveira dos Santos -- Pedro Henrique Oliveira dos Santos -- Pedro Henrique Oliveira dos Santos
WICKET-3261
Hi, With https://issues.apache.org/jira/browse/WICKET-3261 I added a new Maven module to 1.5: wicket-core. Its purpose is to create a .jar that contains the classes from wicket.jar, wicket-util.jar and wicket-request.jar (aka uberjar, jarjar, ...). We split wicket/ to three modules : wicket/, wicket-util and wicket-request to make it more modular and easier to maintain, but now (non-Maven) users complain about class loading problems because they didn't add -util and -request in their classpath. The purpose of the new module is to hide the fact that we split the code internally and tell all users to use the new uberjar. We can even not publish the smaller ones in the Maven repos. The open question is: should we rename current wicket module to wicket-core and the new module to become 'wicket' ? Pros: - all user apps will continue to have dependency to org.apache.wicket:wicket Cons: - merging code from 1.4 to 1.5 can become a bit harder If we agree on that renaming of the modules then I need a date when other devs don't commit anything to do it. martin-g
Re: WICKET-3261
+1 to rename current wicket into wicket-core -igor On Tue, Dec 21, 2010 at 6:53 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi, With https://issues.apache.org/jira/browse/WICKET-3261 I added a new Maven module to 1.5: wicket-core. Its purpose is to create a .jar that contains the classes from wicket.jar, wicket-util.jar and wicket-request.jar (aka uberjar, jarjar, ...). We split wicket/ to three modules : wicket/, wicket-util and wicket-request to make it more modular and easier to maintain, but now (non-Maven) users complain about class loading problems because they didn't add -util and -request in their classpath. The purpose of the new module is to hide the fact that we split the code internally and tell all users to use the new uberjar. We can even not publish the smaller ones in the Maven repos. The open question is: should we rename current wicket module to wicket-core and the new module to become 'wicket' ? Pros: - all user apps will continue to have dependency to org.apache.wicket:wicket Cons: - merging code from 1.4 to 1.5 can become a bit harder If we agree on that renaming of the modules then I need a date when other devs don't commit anything to do it. martin-g
