Why have AppName at the start of fully qualified class paths?

[widged]

(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.

[widged]

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.

The problem then is to balance out the benefits and costs of this approach. Custom paths give more freedom but make the code more bloated and more difficult to read if you have to write fully qualified class names everywhere. Javascript doesn't really offer any opportunity for an import statement that would let you define the fully qualified class reference first and then access it via the className only later. Alias could help with this but only to some extend. Aliases appear to be global when the import statement defines a reference that is active only in the current class.

[mitchellsimoens]

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.

[widged]

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.

In theory, it should be possible. What about practically? Until yesterday, none of your test cases covered the use of fully qualified path name. Have any in your team tried? If yes, I would be grateful if you could provide an example.

[widged]

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.

[edspencer]

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.

[widged]

Thanks for that. Patiently waiting for next release, then.

[edspencer]

B3 is now live at http://www.sencha.com/blog/sencha-to...hrome-support/ - hope the updated dependency management better meets your needs

[widged]

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)

And ideally, it should be possible to organize the javascript code in a way similar to this:
https://github.com/widged/FrontierCa...alendar/widged

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.

[widged]

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',
]

I get as error message: "Error: [Ext.Loader] Failed loading 'app/view/AppView/AppView.js', please verify that the file exists"

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''?