Success! Looks like we've fixed this one. According to our records the fix was applied for TOUCH-1554 in a recent build.
  1. #21
    Sencha - Community Support Team edspencer's Avatar
    Join Date
    Jan 2009
    Location
    Palo Alto, California
    Posts
    1,939
    Vote Rating
    9
    edspencer is a jewel in the rough edspencer is a jewel in the rough edspencer is a jewel in the rough

      0  

    Default


    I've loosened this up a little for b2. The thing about fully qualifying nested view/model/controller/store/profile classes is that although it's correct, it doesn't optimize for the most common use case. As of b2 you'll be able to locally qualify nested classes so long as you follow the simple convention that top-level namespaces are capitalized and packages are lowercase. The docs are once again updated for b2 to give examples of how this works
    Ext JS Senior Software Architect
    Personal Blog: http://edspencer.net
    Twitter: http://twitter.com/edspencer
    Github: http://github.com/edspencer

  2. #22
    Sencha User
    Join Date
    Jan 2012
    Posts
    16
    Vote Rating
    0
    widged is on a distinguished road

      0  

    Default


    Is what you call 'namespace' the alias to a package path?
    (namespaces are typically embodied in packages in java-like languages)

    'MyPath.MyClass' as a shorthand reference to 'MyApp.path.to.MyClass',
    while having used setAlias('MyApp.path.to', 'MyPath')?

    Discussion on why to remove the requirement of having MyApp as first item of a fully qualified path name would lead to various benefits moved to discussion (as this was a bug report marked as fixed).

    If the uppercase convention is about imposing some folders in the package space to start with uppercase, then it may make the code more arbitrary. The absence of documents describing the language logic (at high levels) makes it difficult for persons without prior extJS experience to find out about these sencha-specific code conventions. Even if this gets documented, the information often only exists at class level and finding out about such idiosyncrasies too often turns into a 'find Wally' type of exercise.

  3. #23
    Sencha User
    Join Date
    Mar 2010
    Location
    Seattle, WA
    Posts
    137
    Vote Rating
    1
    wprater is on a distinguished road

      0  

    Default


    It's been common for me to follow the conventions of the framework Im building with. So with Ext (Sencha etc.) I tend to follow their lead. Which is documented here:
    http://docs.sencha.com/touch/2-0/#!/...stem-section-2

    I like to package my classes with a top-level domain of sorts so it's easier to integrate others' libraries into mine that may have the same class names. Furthermore, it's fairly common to have a folder structure that relates to the class's namespace (at least when I build the main app).



    Quote Originally Posted by widged View Post
    Is what you call 'namespace' the alias to a package path?
    (namespaces are typically embodied in packages in java-like languages)

    'MyPath.MyClass' as a shorthand reference to 'MyApp.path.to.MyClass',
    while having used setAlias('MyApp.path.to', 'MyPath')?

    Discussion on why to remove the requirement of having MyApp as first item of a fully qualified path name would lead to various benefits moved to discussion (as this was a bug report marked as fixed).

    If the uppercase convention is about imposing some folders in the package space to start with uppercase, then it may make the code more arbitrary. The absence of documents describing the language logic (at high levels) makes it difficult for persons without prior extJS experience to find out about these sencha-specific code conventions. Even if this gets documented, the information often only exists at class level and finding out about such idiosyncrasies too often turns into a 'find Wally' type of exercise.