7 Feb 2012 2:48 PM #1
Why have AppName at the start of fully qualified class paths?
(prompted by a late reply on a bug already marked as fixed - custom folder structure)
The reply was about adopting some first letter uppercase vs lowercase convention to differentiate namespace (alias?) from package path in a class path.
I assume what is meant is having 'MyPath.MyClass' as a shorthand reference to 'MyApp.path.to.MyClass', while having used setAlias('MyApp.path.to', 'MyPath')?
The truth is that most languages that rely on packages don't have the AppName as first item in the path. You would use 'path.to.MyClass' and it would be assumed that it matches the folder structure starting from the source or the app folder. The avoidance of a mention of the AppName in the package path makes the code more portable (easier to re-use the same code across projects).
If you use these other languages as inspiration, 'MyApp.path.to.MyClass' could be instead expressed as package: path.to.MyClass and, optional, a second parameter that let you define a baseFolder (or namespace) 'MyApp'. I think you already have some aspect of that baseFolder functionality in, through the 'alias' property. [Wondering, could you have more than one application loaded from an index.html? If not, the appName is completely predictable and therefore of no value as information.]
This would solve the problem without requiring a mix of conventions within a single item. With editors like Sublime Text allowing to refer to folders outside of your project, it is possible to think of building a library of components re-used across applications.
There seems to be an interest from Sencha to attract people from an entreprise background (e.g., Flex). However, small deviations from the usual conventions, like the addition of MyApp at the start of the path easily create major headaches for code structure and re-use in larger applications.
7 Feb 2012 5:42 PM #2
Another aspect of these reverse url conventions for namespaces is how easy or difficult you can make it to re-use community contributed components.
With Sencha, it looks like the practice is to release official plugins and name them something like Ext.layout.AccordionLayout or Ext.ux.touch.Rating. Implicit to this naming convention is the expectation that there can ever be one trustworthy accordion layout or rating component.
To better support fully qualified namespaces (without AppName at the start of the path) could more explicitly encourage average Joe's contributions, with com.average-joe.Rating happily co-existing in the ecosystem with Ext.ux.touch.Rating.
The reverse url is widely adopted in communities that show a very strong ecosystem, with many quality libraries and components contributed on github and google code.
8 Feb 2012 1:03 PM #3
- Join Date
- Mar 2007
- Gainesville, FL
- Vote Rating
Sorry it has taken me this long to jump on this thread... forgot about it but I promised I would jump on it so I am
We have used the naming convention Ext.grid.Panel where the root (Ext) and the actual name (Panel) are UpperCamelCase and the inner namespaces (grid) are all lowercase. We have been using this naming convention since all of this was started in 2006.
That being said, you are not force to. If you name your classes something like com.users.list then you actually can. The only thing we do force is that the file structure matches your class name and is case sensitive. We recommend you use the UpperCamelCase but it's really not required.
Now the plugins that aren't actually part of the framework are up to the author of those classes. For instance I used to use the Ext.ux (kind of an unspoken namespace for 3rd party extensions) but have now started to use the Ux namespace instead of Ext.
So to sum it up... we have naming conventions and recommendations but not really requirements.
Sencha Inc, Senior Software Engineer
Check out my GitHub, lots of nice things for Ext JS 4 and Sencha Touch 2
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 email@example.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.
8 Feb 2012 3:40 PM #4
I would really appreciate if you could provide a working example. I have been looking on github and googlecode and couldn't find any example using custom path structure.
If I try to deviate from the app>[controller/view/model] recommended structure, then I end up with a lot of weird outcomes (v2pr3).
(using AppName at the start of the class path)
I can only get the code to work if the controller that is defined in app.js (main script, declared in the index.html file) is in a folder app/controller. If I do something as simple as renaming app/controller to app/controllers (making all necessary changes), the app stops working. The culprit is an attempt to load a view dynamically from a controller, using Ext.ClassManager.get('AppName.AppView').create(); (using AppName.view.AppView makes no difference). I grant you, not an orthodox approach, but the issue is that as soon as you deviate a tiny bit from the app/[controller/view/model] basic structure, other, seemingly unrelated, part of the sencha code starts to break in odd ways.
(not using AppName at the start of the class path, using fully qualified names of the type com.domain.project)
If I use views : [ 'com.domain.project.AppView' ], sencha tries and load the file from app/view/com/domain/project/AppView.js, not com/domain/project/AppView.js.
If you name your classes something like com.users.list then you actually can.
8 Feb 2012 4:46 PM #5
The second aspect of the discussion was how the recommendation of using Ext.ux (or ux) for user contributed content could hinder the development of an ecosystem around Sencha.
If I go to codeCanyon, I get 750 matches for jQuery, One for ext (but nothing to do with ext-js). One match for sencha.
Is the lack of availability of components outside of those provided by the official routes something that you perceive as a problem or not? Yes, you can find some (touch-datepicker, touch-calendar) but they seem to be few, or at the least, difficult to find.
9 Feb 2012 3:40 PM #6
I've updated how this works as of the next release. There's no longer any guesswork based on the case of the package - instead Application will just interrogate Ext.Loader to resolve dependencies. This means that for any external dependencies (things from outside your app) you'll just have to specify the path above your Ext.application.
Hopefully this gives a good balance of flexibility and convenience. The docs are also updated for the next release to show the changes.
13 Feb 2012 7:15 PM #7
Thanks for that. Patiently waiting for next release, then.
14 Feb 2012 11:55 AM #8
B3 is now live at http://www.sencha.com/blog/sencha-to...hrome-support/ - hope the updated dependency management better meets your needs
19 Feb 2012 3:20 AM #9
Thanks Ed. I will check it out.
What I am trying to do is figure out a good way to write re-usable widgets. A widget could capture an editable event calendar such as this one: http://widged.github.com/FrontierCalendar--OO-version/
(ignore the glitches, tested on safari)
A mvc separation is applied, but it is done in each folder, agenda (catalogue of events) and calendar (day views), with class names that are closer to the ones I am used to (Flex conventions) than the ones in Sencha.
Some components used by the widget have the potential to be reused across projects. The ui/MoreOverflow.js class could be used in a todo list application or other list contexts. As such, there are better kept outside of the calendar folder and in a more neutral ui one.
It should be possible to add variations without modifying any file in the original author's namespace. The original Frontier calendar provided a typical monthly view. I was after a week by week one. A day view could be contributed by another user later on, without a need for me to update my own plugin. That other user should be able to link to my library and extend it, by adding and editing files in a separate namespace.
I will give a shot a turning that jQuery plugin into a Sencha one. I will keep track of the problems I come across.
20 Feb 2012 6:48 PM #10
Still getting the same errors. Code that was working with touch 2 pr 3 doesn't run with any of the beta versions, including beta 3.
If, in the main app controller, I specify
views : [ 'AppName.AppView', ]
Two problems. (1) I don't have a folder app. I renamed it to app1 for the purpose of testing custom path support. (2) AppView is at "app1/AppView.js", not "app/view/AppView/AppView.js" (3) AppView shows up twice in the path ('../AppView/AppView.js') though this happens inconsistently, most of the time, I get 'Failed loading 'app/view/AppName/AppView.js''?