7 Feb 2012 1:12 PM #21
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
7 Feb 2012 1:58 PM #22
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.
7 Feb 2012 3:38 PM #23
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:
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).