18 Mar 2010 2:42 AM #1
ExtJS API consistency
ExtJS API consistency
Over the last couple of weeks that I've been actively using ExtJS again and 3.0 in particular I often come across weird, inconsistent, unexplained behaviour in the framework. These hinder people using the api effectively often requiring to go and consult the docs or even look at the source code. While in the end this can't be avoided (and shouldn't) I think the api can be improved significantly if it were following a more consistent design.
Here are but few of such problems:
- Some components support 'icon', others 'iconCls' and some both. There is no clear consistency
- CSS class property is often named differently. Sometimes cssClass whiel at other times shortened to cls. While class can't obviously be used due to it being a reserved keyword I feel it should just use 'cls'
- Class and xtype names are at times nonsensical or mismatching: GridPanel -> grid, TreePanel -> treepanel, TriggerField -> trigger. I think more consistent corrolation between the actual class and xtype would help a lot in code readablity.
This are few pains I've had so far. I do think that there should be more effort in streamlining the api and the framework. For example by stating mismatching properties and xtypes as deprecated in extjs 4.0 and then remove deprecated features from 5.0 and so on.
18 Mar 2010 4:54 AM #2
This is one of those things that I've pinged the team about and they've communicated that they are aware of these issues. Being that changing things in the 3.0 branch would be a breaking change, they are not going to. So i guess they will have to wait till 4.0.
18 Mar 2010 5:39 AM #3
yes that makes sense. Like I said declare methods, classes, properties, etc. as deprecated in the next major version (at least things that can't be easily removed to keep backward compatibility) and then commit to remove in the next version. This would give ample of time and warning for people to stop using deprecated features.
18 Mar 2010 5:41 AM #4
In TYPO3 we have the policy that
* we mark the function as deprecated
* we use a deprecation log where all calls to deprecated functions are logged
* we remove the functions 2 main releases later.
As we keep the "4" as main release, this means:
4.2.x mark as deprecated
4.4.x function will be removed
I know it'S bit different in JS, but you could print deprecation usage to console if console is object.
Btw - would be a nice addition to have Ext.debug(msg)vg Steffen
Release Manager of TYPO3 4.5