Why using name instead of id?

edited February 2012 in General
Hi all,

I wondering why we should use "name" to change attributes and content instead of "id" (like we did it in mojo or any other normal js app). Here a part of a enyo example by you:
components: [
    { tag: "img", name: "icon",
      style: "width: 50px; height: 50px; float: left; padding-right: 10px" },
    { tag: "b", name: "handle"}, /* why name instead of id?*/
    { tag: "span", name: "text" }
  ],

  create: function() {
    this.inherited(arguments);
    this.iconChanged();
    this.handleChanged();
    this.textChanged();
  },

  iconChanged: function() {
    this.$.icon.setAttribute("src", this.icon);
  },

  handleChanged: function() {
    this.$.handle.setContent(this.handle + ": ");
  },

  textChanged: function() {
    this.$.text.setContent(this.text);
  }
});
Is there no way to do this with id? For me, it does not work with id.
What's the reason why we should use name?

At this time, I would say it's better to give the element a ID and access with document.getElementById() gut it seems like this does not work.

Hope I get some interesting reply about this topic!
Thank you all

Comments

  • edited February 2012
    The reason you don't use id is that the DOM node for the widget may not have been created when you want to use it. One of the key ideas in Enyo is that the enyo control is the true object, and the DOM node is just a rendering of it. That DOM node could go away or be recreated depending on the bigger needs of your app's UI. So, we store things in the JS object, and to get to that object, you use the "$" hashes as a dictionary mapping names to objects.

    Also, usually the ids of DOM nodes are auto-generated by the framework. When you call the hasNode() method of a enyo.Control, that finds the appropriate node for you if it's already been rendered into the document.
  • Well, thanks for the fast reply!

    Btw, is there a way to access the function of a kind from a separate js file? E.g. the textChanged function above. I guess it's not good to do this but is some cases - at least - it's just good to know.

    Thank you
  • You just call it. Usually, you'll have a package.js file that pulls in all your different source JS files, and they'll all go into your main runtime environment.
  • ok everything works fine. But this framework is definitely something special in web technology.
Sign In or Register to comment.