1. #1
    Ext JS Premium Member
    Join Date
    Sep 2010
    Posts
    331
    Vote Rating
    4
    stewardsencha is on a distinguished road

      0  

    Default Why do you want these config arrays to contain unqualified names?

    Why do you want these config arrays to contain unqualified names?


    From the new 4.2 docs

    Request clarification please.

    The list of namespace prefixes used in the application to resolve dependencies like Views and Stores:
    You don't need to include main namespace (MyApp), it will be added to the list automatically.
    Code:
     Ext.application({
         name: 'MyApp',
    
         namespaces: ['Common.code'],
    
         controllers: [ 'Common.code.controller.Foo', 'Bar' ]
     });
    
     Ext.define('Common.code.controller.Foo', {
         extend: 'Ext.app.Controller',
    
         models: ['Foo'],    // Loads Common.code.model.Foo
         views:  ['Bar']     // Loads Common.code.view.Bar
     });
    
     Ext.define('MyApp.controller.Bar', {
         extend: 'Ext.app.Controller',
    
         models: ['Foo'],    // Loads MyApp.model.Foo
         views:  ['Bar']     // Loads MyApp.view.Bar
     });
    There is a fair bit of discussion in the docs, I have had pain here as I learned.
    So it is hard to be certain what was due to ignorance vs what is now fixed or improved.

    May I ask, what is the point here, why are we doing this?

    a) we get setters and setters "for free".
    b) models and stores are instantiated in the getter if they do not exist. But not views.

    ...so this is shorthand for requiring and creating?

    Why is it that you want these config arrays to contain unqualified names?

    There are so many places to "resolve dependencies" I have lost it.
    Changing one upsets the others and around in circles I go.
    The application has name, namespaces, paths, appfolder and now this.
    And still the dependencies are a problem.

    Yet there they are in an organized files system.

    I do not have a great deal of real-world experience (I can't get a fricking product out the door), but it seems to me it would be very simple to have one namespace and I reach into it by completely specifying a path. If I want cool/code/controller.js then I write require [''cool.code.Controller'].

    Why the complications and automation?
    What does this buy me?
    Why do I want to hide information from myself?

    models: ['Foo'], // Loads Common.code.model.Foo Surprise!! You thought it was something else!

  2. #2
    Sencha - Senior Forum Manager mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    35,677
    Vote Rating
    749
    mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute

      0  

    Default


    It assumes you are using the same namespace as the class you are in which is valid for the exact same reason you are using. If you have a controller that is not under your application's namespace, so it could be a shared class, then you have to assume the models and stores you specify are under the same namespace of that shared class. If you assume it is the same as your application class then that can break your shared class assumption.

    I personally do not use the models, stores and views properties on controllers anymore. For models and stores is because they are made global so that means (to me) that Application would need to require them; only case against this is if you are requiring a shared namespace class in which I would want it to require other same namespace files. For views, for the most part other views should be requiring other views, a controller shouldn't be requiring a view; only exception is if the view would never belong to a parent.
    Mitchell Simoens @SenchaMitch
    Sencha Inc, Senior Forum Manager
    ________________
    Check out my GitHub, lots of nice things for Ext JS 4 and Sencha Touch 2
    https://github.com/mitchellsimoens

    Think my support is good? Get more personalized support via a support subscription. https://www.sencha.com/store/

    Need more help with your app? Hire Sencha Services services@sencha.com

    Want to learn Sencha Touch 2? Check out Sencha Touch in Action that is in print!

    When posting code, please use BBCode's CODE tags.

  3. #3
    Ext JS Premium Member
    Join Date
    Sep 2010
    Posts
    331
    Vote Rating
    4
    stewardsencha is on a distinguished road

      0  

    Default


    You went a little fast for me there but I think I got the jist.

    I have a workspace and several apps and I am trying to share classes.

    So it's all about "assumptions". Meaning it is just shorthand.

    If I always fully qualify then I don't worry about it ?

    I don't see a clear advantage to ['Fred'] over ['here.be.Fred']

    I grow weary of magic, assumptions and automation at this early stage. I think that stuff is great only once you have bumped into all the 'assumptions' personally and know what's going to happen. I only bring it up in case I am missing something vital. Your answer seems to say don't sweat it.

    I will let is pass. Thanks for your answer.

Thread Participants: 1

film izle

hd film izle

film sitesi

takipci kazanma sitesi

takipci kazanma sitesi

güzel olan herşey

takipci alma sitesi

komik eğlenceli videolar