would be to pluralize the directories under 'app' in keeping with most other mvc frameworks available.
also, it would seem that we are going down the convention over configuration path with Ext that we've seen in Rails, et al. It would be logical to assume that the great majority of Ext apps will have more than 1 class in each of these directories so assuming the directory name represents the contents, it would make sense to pluralize the directories (model -> models, view -> views, controller -> controllers)
We chose the singular approach because it matches our class naming conventions. Each of those directories maps to a package namespace, e.g.:
MyApp.model.User vs MyApp.models.User
MyApp.view.user.Edit vs MyApp.views.users.Edit
We never pluralize package names in the framework and want application code and framework code to feel as alike as possible. By keeping to these naming conventions we can leverage our strong class model and tooling to make applications easier to write and deploy.
Ed can you speak a little about what happened to the routing functionality in prior revisions of MVC?
Absolutely. We tried hard to make this server-inspired pattern work on the server but have had to rethink our approach. I think we have a great solution lined up for deep linking and application-wide history management lined up but we decided to push it to 4.1 to be sure that we could deliver the right solution. Turns out it's not quite as simple as we would have liked...
The great thing about what we have in 4.0 though is that it's only 3 classes, yet delivers an enormous amount of power. I love writing apps with this stuff
Simplicity is great but I would rather have to worry about 5 classes and have the routing and history management. The routing functionality becomes very important with larger applications (especially direct navigation to secondary screens to accelerate development). I had experimented a bit with the functionality you had and it seemed promising but I am sure there are complexities I have not considered.