Results 1 to 9 of 9

Thread: ViewController getReference(): Why not just use itemId?

  1. #1
    Sencha Premium Member
    Join Date
    Feb 2012
    Location
    Raleigh, NC
    Posts
    501
    Answers
    23

    Default Answered: ViewController getReference(): Why not just use itemId?

    Looking at the Sencha ViewController and its interaction with the view via getReference(), I'm unsure why the new "reference" config item was introduced. Doesn't "itemId" already fill this need, without having to resort to another config item? "reference" seems superfluous and unnecessary.

  2. They aren't quite the same thing. The itemId needs to be unique within a container hierarchy. Not necessarily so with a reference, the way that references are contained is different. If you were so inclined, you could do something like this:

    Code:
    Ext.require('*');
    
    Ext.onReady(function() {
    
        var p = new Ext.panel.Panel({
            referenceHolder: true,
            items: {
                id: 'item1',
                reference: 'a',
                referenceHolder: true,
                items: {
                    id: 'item2',
                    reference: 'a',
                    referenceHolder: true,
                    items: {
                        id: 'item3',
                        reference: 'a'
                    }
                }
            }
        });
    
        console.log(p.getReference('a').id);
        console.log(p.getReference('a').getReference('a').id);
        console.log(p.getReference('a').getReference('a').getReference('a').id);
    
    });

  3. #2
    Sencha Premium User evant's Avatar
    Join Date
    Apr 2007
    Location
    Sydney, Australia
    Posts
    19,255
    Answers
    759

    Default

    They aren't quite the same thing. The itemId needs to be unique within a container hierarchy. Not necessarily so with a reference, the way that references are contained is different. If you were so inclined, you could do something like this:

    Code:
    Ext.require('*');
    
    Ext.onReady(function() {
    
        var p = new Ext.panel.Panel({
            referenceHolder: true,
            items: {
                id: 'item1',
                reference: 'a',
                referenceHolder: true,
                items: {
                    id: 'item2',
                    reference: 'a',
                    referenceHolder: true,
                    items: {
                        id: 'item3',
                        reference: 'a'
                    }
                }
            }
        });
    
        console.log(p.getReference('a').id);
        console.log(p.getReference('a').getReference('a').id);
        console.log(p.getReference('a').getReference('a').getReference('a').id);
    
    });
    Twitter - @evantrimboli
    Former Sencha framework engineer, available for consulting.
    As of 2017-09-22 I am not employed by Sencha, all subsequent posts are my own and do not represent Sencha in any way.

  4. #3
    Sencha Premium User
    Join Date
    Nov 2010
    Location
    Chicago
    Posts
    2,425
    Answers
    20

    Default

    See this, search for "Why itemId or some other query can't be used in place of reference?"

  5. #4
    Sencha Premium Member
    Join Date
    Feb 2012
    Location
    Raleigh, NC
    Posts
    501
    Answers
    23

    Default

    Thanks, evant. I suppose that makes sense. I'm just thinking about ways this could possibly be streamlined. I think that in many cases, we're going to see components where itemId and reference are both defined, and both have the exact same value.

    One idea: Maybe if itemId is defined but reference is not, the reference could just default to match the itemId? Then folks updating an app to Ext 5 who already use itemIds would avoid having to go through their views just to duplicate the itemId and rename it "reference:". Since we know that itemId is more restrictive from the start, I can't think of any immediate downside to doing that.

    Thoughts?

  6. #5
    Sencha Premium User evant's Avatar
    Join Date
    Apr 2007
    Location
    Sydney, Australia
    Posts
    19,255
    Answers
    759

    Default

    I'm not sure how useful that would be, for 2 main reasons:

    1) It's not a "drop-in" upgrade. To effectively use the view controllers it will require some refactoring of the current code. Assuming you are using the newer architecture, it's quite possible that itemId is used significantly less in favour of reference, probably not together.
    2) reference has a special meaning and it's also opt-in. By "back-porting" it to itemId, we're opting you in automatically.
    Twitter - @evantrimboli
    Former Sencha framework engineer, available for consulting.
    As of 2017-09-22 I am not employed by Sencha, all subsequent posts are my own and do not represent Sencha in any way.

  7. #6
    Sencha Premium User
    Join Date
    Nov 2010
    Location
    Chicago
    Posts
    2,425
    Answers
    20

    Default

    Quote Originally Posted by evant View Post
    The itemId needs to be unique within a container hierarchy.
    Can you expand on the highlighted statement?

    According to the documentation itemIds must be unique only within the container (?).

    "Since itemId's are an index to the container's internal MixedCollection, the itemId is scoped locally to the container -- avoiding potential conflicts with Ext.ComponentManager which requires a unique id."

    I thought that only the immediate children of the container need to have a unique itemId.

    If one of these children is a container, there's no requirement that its children must have different itemIds from the already used. This would contradict your reply.

  8. #7
    Sencha Premium User
    Join Date
    Nov 2010
    Location
    Chicago
    Posts
    2,425
    Answers
    20

    Default

    Quote Originally Posted by evant View Post
    They aren't quite the same thing. The itemId needs to be unique within a container hierarchy. Not necessarily so with a reference, the way that references are contained is different. If you were so inclined, you could do something like this:

    Code:
    Ext.require('*');
    
    Ext.onReady(function() {
    
        var p = new Ext.panel.Panel({
            referenceHolder: true,
            items: {
                id: 'item1',
                reference: 'a',
                referenceHolder: true,
                items: {
                    id: 'item2',
                    reference: 'a',
                    referenceHolder: true,
                    items: {
                        id: 'item3',
                        reference: 'a'
                    }
                }
            }
        });
    
        console.log(p.getReference('a').id);
        console.log(p.getReference('a').getReference('a').id);
        console.log(p.getReference('a').getReference('a').getReference('a').id);
    
    });
    What is referenceHolder? Do I need to specify referenceHolder together with reference? argh...

    Your code uses ids, but the question was about reusing itemIds.

  9. #8
    Sencha Premium Member skirtle's Avatar
    Join Date
    Oct 2010
    Location
    UK
    Posts
    3,791
    Answers
    585

    Default

    From reading here...

    http://docs.sencha.com/extjs/5.0.0/a...iner.Container

    ...it appears that references are passed up the component hierarchy until they find a reference holder. This allows the internal component hierarchy of a reference holder to be changed without breaking the references.

    So references have to be unique, irrespective of depth, within their reference holder. This is a slightly tighter restriction than for itemId but less tight than for id.

    It's still not entirely clear to me why itemId couldn't have been re-purposed for this role (YACO) but I suspect itemIds are going to drop out of common usage in favour of references.

  10. #9
    Sencha Premium User
    Join Date
    Nov 2010
    Location
    Chicago
    Posts
    2,425
    Answers
    20

    Default

    Quote Originally Posted by skirtle View Post
    ... I suspect itemIds are going to drop out of common usage in favour of references.
    Interesting thought... then I'd think the component query machinery will also see less usage.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •