1. #1
    Sencha User
    Join Date
    Mar 2007
    Location
    London, UK
    Posts
    143
    Vote Rating
    0
    albeva is infamous around these parts albeva is infamous around these parts

      0  

    Default 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:
    1. Some components support 'icon', others 'iconCls' and some both. There is no clear consistency
    2. 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'
    3. 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.

  2. #2
    jay@moduscreate.com's Avatar
    Join Date
    Mar 2007
    Location
    Frederick MD, NYC, DC
    Posts
    16,361
    Vote Rating
    81
    jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all jay@moduscreate.com is a name known to all

      0  

    Default


    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.

  3. #3
    Sencha User
    Join Date
    Mar 2007
    Location
    London, UK
    Posts
    143
    Vote Rating
    0
    albeva is infamous around these parts albeva is infamous around these parts

      0  

    Default


    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.

  4. #4
    Sencha User steffenk's Avatar
    Join Date
    Jul 2007
    Location
    Haan, Germany
    Posts
    2,664
    Vote Rating
    7
    steffenk has a spectacular aura about steffenk has a spectacular aura about steffenk has a spectacular aura about

      0  

    Default


    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