DateField getValue() vs getCurrentValue() javadoc improvement suggestion.

[Foxtrot]

Required Information
Version(s) of GXT

• GXT 3.0.1

Description
Javadoc for getValue() :

Gets this object's value. Specified by: getValue() in HasValue, getValue() in TakesValue
Returns: the object's value

Javadoc for getCurrentValue():

Returns the field's current value. The value of the field is not updated until the field is blurred when editing.

Returns: the current value

I might be wrong but these should be switched arround to match theire behaviour. It often often happens that the getValue method returned an old value() untill it is unblured, unfocused.

Update:
The real cause of the problem : http://www.sencha.com/forum/showthre...ng-date-picker

[Colin Alworth]

The method getValue() should return the last finished value - this matches the last ValueChangeEvent (and the DOM ChangeEvent), and follows how html elements work. In contrast, getCurrentValue() is present in ValueBaseField and all subclasses to allow someone to read a *possibly inconsisent* value as the user is entering it.

The standard workflow for a user is to enter a field, make changes, and leave after they are finished. While it is true that they might not leave right away after they are finished, it is certainly true that they will not leave *before* they are finished.

Consider a DateField - if I am manually typing in the date, getCurrentValue() will return a value when my characters can be construed to be valid (1/1/2012), but if I continue making changes, it may change (1/21/2012). Then, other changes will make the value null (1/1 or 1/41/2012) when the user is probably not finished, but doesn't intend to leave the field as invalid.

The TakesValue, HasValueChangeHandlers interfaces are being used to indicate "here is a value the user has settled on and accepted". HasValue brings these two together, and we see this as the most consistent way to satisfy the declared methods getValue() and addValueChangeHandler(...). We provide getCurrentValue in case you really want a moment-by-moment view of what other modification they have made.

If we fired a ValueChangeEvent after every keystroke, I could see a case for changing getValue's behavior, but we do not, and do not intend to change that event.

We are certainly open to discussion on these matters though - an API describes how the library can be used, so the users should certainly be involved in helping to mold it.

From Darrell's recent post, it appears the linked thread you provided is behaving correctly - do you have an example of it not working?

[Foxtrot]

Thanks for the compleet writeout now I understand why there are two methods. To prevent the user form typing a strange dateformat , I set the editable property to false, the user is then forced to choose a date using the datepicker.

Here is a simple code example:

public class Main implements EntryPoint {

	public void onModuleLoad() {
		FormPanel rootPanel =  new FormPanel();
		VerticalLayoutContainer rootContainer = new VerticalLayoutContainer();
		final DateField dateField = new DateField();
		dateField.setEditable(false);
		TextButton submit = new TextButton("Submit");
		
		TextField txtName = new TextField();
		
		
		submit.addSelectHandler(new SelectHandler() {
			
			public void onSelect(SelectEvent event) {
				Window.alert(dateField.getValue().toString());
			}
		});
		rootContainer.add(new FieldLabel(dateField,"Select a date"));
		rootContainer.add(new FieldLabel(txtName,"Enter your name"));
		rootContainer.add(submit);
		
		rootPanel.add(rootContainer);
		
		RootPanel.get().add(rootPanel);
	}
  
}

However I can't reproduce the behavior at the moment. Ill try some variations and try to find out the root cause :-)