PDA

View Full Version : [CLOSED][3.0RC2,2.x] DateField: altFormats is cached



valcamo
16 Jun 2009, 5:58 AM
The DateField's altFormats property is cached inside parseDate, so it is not possibile to change it after the field has been created.


var df = new Ext.form.DateField({altFormats:'Y-m-d'});
alert(df.parseDate('2009-01-23')); // ok
df.altFormats = 'm-d-Y';
alert(df.parseDate('01-23-2009')); // undefined


I understand that the caching is used to improve performance and a possible workaround is to clear the altFormatsArray property whenever altFormats is changed, but this prevents the use of altFormats at the prototype level:


Ext.form.DateField.prototype.altFormats = 'Y-m-d';


The expected behavior of the above code is that any DateField component already created, where the config object didn't explicitly have the altFormat property, will now use the prototype's altFormats.

Condor
16 Jun 2009, 6:02 AM
Simply use:

delete df.altFormatsArray;
df.altFormats = 'm-d-Y';

ps. The docs say altFormats is a config option and NOT a writable property, so the expected behavior is actually correct.

valcamo
16 Jun 2009, 6:15 AM
Yes, I understand this and have already said that your workaround is a possible solution.

It should be noted that almost all config options are not listed as writable properties, but I think that is a common use to change it *after* the component has been created.

For example: if I set the format property based on the language of the user that is logging in, then I have to destroy all components already created and rebuild them again, because the format config is not listed as a writable property.

If I can set the format property at the prototype level (and this is possible right now, because format is not cached) then I will easily change the behavior of all components already created.
This is not possible for the altFormats property.

Take this as a possible suggestion then.

evant
16 Jun 2009, 6:53 AM
In general unless there's some kind of setter method you can't assume that setting the property will work, say for example, putting floating = true on a panel won't work, whereas setting allowBlank on a text field will. The general assumption then is that any modifying config properties don't have any effect. Marking this as closed.

valcamo
16 Jun 2009, 7:12 AM
In general unless there's some kind of setter method you can't assume that setting the property will work, say for example, putting floating = true on a panel won't work, whereas setting allowBlank on a text field will. The general assumption then is that any modifying config properties don't have any effect. Marking this as closed.

Thanks for your reply.

The documentations should be improved to mark each config options in some way to specify that it is writable after the component has been created.
Most config properties are writable and it is very useful to change them after creation (allowBlank is an example, format is another).

mjlecomte
16 Jun 2009, 11:59 AM
Thanks for your reply.

The documentations should be improved to mark each config options in some way to specify that it is writable after the component has been created.
Most config properties are writable and it is very useful to change them after creation (allowBlank is an example, format is another).

Config options are used at creation.

Properties are identified separately in the API docs. Properties are typically identified "read only" when altering them directly would not have the correct affect. If you have specific examples of properties that are missing or need to be updated to indicate read only suggest you add those to the doc bugs thread.