Results 1 to 7 of 7

Thread: [Suggestion] Consistency naming/behavior

  1. #1
    Ext JS Premium Member
    Join Date
    Apr 2007
    Posts
    228
    Vote Rating
    4
      0  

    Default [Suggestion] Consistency naming/behavior

    It would be nice to have more consistent naming schema(or common/shared implementation,preferred) for children of container controls-menu,form etc.,such as CheckBox=CheckItem,DateField=DateItem,... rendering of course is context dependent,only widget model is shared.

    Thanks a lot.

  2. #2
    Sencha User jack.slocum's Avatar
    Join Date
    Mar 2007
    Location
    New York, NY
    Posts
    6,956
    Vote Rating
    20
      0  

    Default

    I don't understand what you are suggesting exactly? The only similar parts of the examples you gave are shared. e.g. DateField and DateItem both share DatePicker. The actual rendering and events of each of those components is context specific.
    Jack Slocum
    Sencha Co-Founder, Ext JS Founder
    Original author of Ext JS 1, 2 & 3.
    Twitter: @jackslocum

  3. #3
    Ext JS Premium Member
    Join Date
    Apr 2007
    Posts
    228
    Vote Rating
    4
      0  

    Default

    I suggest similar elements to have same names,or more proper solution to be context independent,hence one element per behavior.All context dependent details must be incapsulated in context element itself,see dependency properties in WPF for analogy.
    And another one-why Element dosen't inherit behavior of widget it was created from.For example,object I get from Ext.getEl() dosen't have Ext.form.TextField methods,though it has behavior of TextField,because it was created as TextField.

    Thanks.

  4. #4
    Sencha User
    Join Date
    Apr 2012
    Location
    Austin, Texas
    Posts
    4
    Vote Rating
    1
      0  

    Default

    I suggest similar elements to have same names,or more proper solution to be context independent,hence one element per behavior.
    I still don't follow what you mean. Ext's naming is quite consistent with what the components do and follow well-established design patterns. Can you provide a concrete example in Ext of what you're getting at? (By the way, to be frank with you -- we can have a nice discussion about this, but the odds of us mass-renaming classes in our library because one person doesn't care for the naming are pretty much zero as it would break every single user of Ext).

    I get from Ext.getEl() dosen't have Ext.form.TextField methods,though it has behavior of TextField,because it was created as TextField.
    Ext.getEl() returns an Ext.Element object by element (DOM) id. Ext.ComponentMgr.get() will return a component (TextField, or other component) by the component id. Depending on what you are doing, you might want to do one or the other. Think of it like "interface programming" in static languages. Even though you may be accessing the same object on one level, the way in which you choose to access it can change the actual interface that you're dealing with (as expected). Again, this is pretty common, and works the way most people would expect it to.

  5. #5
    Ext JS Premium Member
    Join Date
    Apr 2007
    Posts
    228
    Vote Rating
    4
      0  

    Default

    Quote Originally Posted by brian.moeskau View Post
    I still don't follow what you mean. Ext's naming is quite consistent with what the components do and follow well-established design patterns. Can you provide a concrete example in Ext of what you're getting at? (By the way, to be frank with you -- we can have a nice discussion about this, but the odds of us mass-renaming classes in our library because one person doesn't care for the naming are pretty much zero as it would break every single user of Ext).
    so,discussion on this theme is closed to foreseeable futureI provide examples before-DateField/DateItem=DateComponent and could be placed in "components" namespace,not in "form" or "menu",because they provide similar UI experience,all container specific details must be refactored in container itself IMHO.And better start to refactor earlier,but maybe through iterative steps,don't you think?

    Quote Originally Posted by brian.moeskau View Post
    Ext.getEl() returns an Ext.Element object by element (DOM) id. Ext.ComponentMgr.get() will return a component (TextField, or other component) by the component id. Depending on what you are doing, you might want to do one or the other. Think of it like "interface programming" in static languages. Even though you may be accessing the same object on one level, the way in which you choose to access it can change the actual interface that you're dealing with (as expected). Again, this is pretty common, and works the way most people would expect it to.
    Under "consistent" in this case,I understand "common/shared=one entry point" experience for entire ext component model-that return by Ext.getEl() is not DOM/BOM element per se,it's ext's wrapper to provide "basic" level of ext's functionality already.So,I expect "shortcut" to full one,but not another functional/API path to complete "picture" for the same element.And what if I want to select "working set" of elements by css?I thought ext "extend" dom model,providing component services and new component model layered on top of dom as is(JQuery philosophy ),that sounds logical to me...

    Thanks.

  6. #6
    Sencha User jack.slocum's Avatar
    Join Date
    Mar 2007
    Location
    New York, NY
    Posts
    6,956
    Vote Rating
    20
      0  

    Default

    so,discussion on this theme is closed to foreseeable futureI provide examples before-DateField/DateItem=DateComponent and could be placed in "components" namespace,not in "form" or "menu",because they provide similar UI experience,all container specific details must be refactored in container itself IMHO.And better start to refactor earlier,but maybe through iterative steps,don't you think?
    No, that would be severely flawed. The container should not have the logic for contained components, they should operate over a common interface. For example, a Menu contains MenuItems - so there is an interface that MenuItem's implement and Menu can call interface methods to trigger specific behaviors - but each child component defines how it needs to perform those behaviors. In Menu there are common base classes for MenuItem's that provide some common behaviors for reuse. There's even an adapter class that provides a simple mechanism for adapting any Ext.Component to a menu.

    Implementing logic in the container means the container has to have knowledge of everything that it can possibly contain and that would be a maintenance nightmare - not to mention kill how easy it is to create new, custom child components.

    Under "consistent" in this case,I understand "common/shared=one entry point" experience for entire ext component model-that return by Ext.getEl() is not DOM/BOM element per se,it's ext's wrapper to provide "basic" level of ext's functionality already.So,I expect "shortcut" to full one,but not another functional/API path to complete "picture" for the same element.And what if I want to select "working set" of elements by css?I thought ext "extend" dom model,providing component services and new component model layered on top of dom as is(JQuery philosophy ),that sounds logical to me...
    As Brian said, an Element is nothing more than a wrapper around a DOM element. Component != Element. Although there is plenty of inheritance in Ext, for the most part Ext uses composition over inheritance. Composition is much more flexible, decouples classes and provides a more solid foundation for reuse. So, most components "contain an Element" (or Elements) instead of "are an Element".

    --

    I would recommend reading up on OO design patterns and getting to know the benefits of the various way objects can relate to each other using different patterns. This will help you to understand why Ext does many of the things that it does in the way that it does.
    Jack Slocum
    Sencha Co-Founder, Ext JS Founder
    Original author of Ext JS 1, 2 & 3.
    Twitter: @jackslocum

  7. #7
    Ext JS Premium Member
    Join Date
    Apr 2007
    Posts
    228
    Vote Rating
    4
      0  

    Default

    Quote Originally Posted by jack.slocum View Post
    No, that would be severely flawed. The container should not have the logic for contained components, they should operate over a common interface. For example, a Menu contains MenuItems - so there is an interface that MenuItem's implement and Menu can call interface methods to trigger specific behaviors - but each child component defines how it needs to perform those behaviors. In Menu there are common base classes for MenuItem's that provide some common behaviors for reuse. There's even an adapter class that provides a simple mechanism for adapting any Ext.Component to a menu.

    Implementing logic in the container means the container has to have knowledge of everything that it can possibly contain and that would be a maintenance nightmare - not to mention kill how easy it is to create new, custom child components.
    Good point,I think about that,but as with all good patterns-it's context specific,I was talking about something like http://blogs.msdn.com/nickkramer/arc...25/456024.aspx.


    Quote Originally Posted by jack.slocum View Post
    As Brian said, an Element is nothing more than a wrapper around a DOM element. Component != Element. Although there is plenty of inheritance in Ext, for the most part Ext uses composition over inheritance. Composition is much more flexible, decouples classes and provides a more solid foundation for reuse. So, most components "contain an Element" (or Elements) instead of "are an Element".
    I understand that Component != Element and composition(through interfaces in OO) is nice thing,much better than rigid class structure.But "inheritance" in context of composition can have it's place toohttp://blogs.msdn.com/nickkramer/arc...18/705116.aspx or CSS as example...I understand there's a difference between logical&visual tree,in WPF terminology
    I just feels you overly complicate things a little in javascript case-it's highly dynamic language and even MS lean in that direction from pure OO design to functional/aop concepts(I like JQuery+http://www.ajaxpro.info/ much more than AJAX.NET exactly because latter still in pure OO age),don't pull all legacy garbage blindly.Ruby supports OO design too but which flavour...
    http://wesnerm.blogs.com/net_undocum...ntbased_a.html
    One thing clear to me is that Avalon framework is very different from other object-oriented frameworks. I have seen or used quite a number of frameworks in the past such as OWL, VCL, MFC, MacApp, and TCL.
    ...
    The first version of Avalon had an overly complicated Model-Presenter-View paradigm, with two trees; the current version simplifies this by removing the Presenter and merging the Model and View into, I believe, a single tree which can be view independently as either a logical tree of nodes or a visual tree. (I had initially believed that two trees were maintained in current version, but Chris Anderson, Avalon program manager indicated otherwise in a post.) The visual tree view, even in this single tree, can be changed independently of the logical view. If you asking yourself, "Huh?" you know what exactly what I feeling.
    Do you smell analogy?I certainly do:-)

    Several points:
    • components consist from elements or defined through elements anyway-why can't be provided some kind of mapping?
    • components have elements granularity/boundary
    • so, I can't get back and forth from component to element?=>can't use standard html access patterns for components,throgh css syntax particularly
    • composition presume max reuse/repurpose of existent object model-not creating parallel or deeper object graph
    • element's dualism is nice but not in all cases,I understand,but AOP philosophy(you follow) presumes exactly this IMHO,isn't it?
    • I thought ext is more about "attached"(extend) behaviors than "element"(expand) one,saying IE's way.Suppose,I was wrong...

    Quote Originally Posted by jack.slocum View Post
    I would recommend reading up on OO design patterns and getting to know the benefits of the various way objects can relate to each other using different patterns. This will help you to understand why Ext does many of the things that it does in the way that it does.
    thanks for suggestion,as with all things,patterns-not all,not everywhere works as expected or best suited and must be blindly applied

    Regards.

Posting Permissions

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