[B3]Enhancement - API style guide suggestions before release

[CasualNetworks]

This is an enhancement requesting further cleanup of some of the root classes.

I have considered writing this post for a while and with the upcoming "API style guide" mentioned in the Ext Js 4 Beta 3 release notes, I would like to request that further review be done related to the class structure. I am not sure if this is too late in the release cycle for this type of cleanup. If it is then maybe this can be added to a future release.

This is not a complete review (If requested, I would be glad to spend additional time on this), but aimed to highlight at some level, the current namespace and some possible duplicate, confusing or complicated relationships. This all adds to the learning curve of Ext JS for new developers and product managers looking to evaluate Ext JS for larger projects.

My suggested goals for this enhancement would be:

• Consistency
• Intuitive
• Logical Grouping

Example Set #1 - Native (like) Objects
Ext.Array
Ext.Date
Ext.Number
Ext.Object
Ext.String

Ext.Function
Ext.Img

Reasoning:
As you can see, this set of classes make up a very logical grouping of objects, as they extend or represent native level representations. These classes seem to be a strong candidate for moving into some type of related namespace. As they seem to have very little relationship to classes like "Ext.ProgressBar"

Example Set #2 - Environment
Ext.is
Ext.supports

Reasoning: We already have a Ext.env, which has classes like "Ext.env.Browser" or "Ext.env.FeatureDetector", can we combine these all into Ext.env.*?

Example Set #3 - Are you my Manager?
Ext.ClassManager
Ext.ComponentManager
Ext.EventManager
Ext.FocusManager
Ext.ModelManager
Ext.PluginManager
Ext.TaskManager
Ext.WindowManager
Ext.ZIndexManager

Ext.data.StoreManager
Ext.dd.DragDropManager
Ext.dd.ScrollManager
Ext.direct.Manager
Ext.menu.Manager
Ext.state.Manager
Ext.tip.QuickTipManager

Source Only
Ext.fx.Manager
Ext.AbstractManager

Concerns:
- Who gets a manager and who does not?
- Why are some manager’s namespaced, Example - Ext.ModelManager versus Ext.data.StoreManager?
-- Some have documentation
- Overall objectively looking at the Ext Js 4, how would one consistently know what to expect when it comes to Managers and their use

Example Set #4 - Abstracts
Ext.AbstractComponent
Ext.AbstractContainer
Ext.AbstractDataView
Ext.AbstractPanel
Ext.AbstractPlugin

Ext.data.AbstractStore
Ext.layout.AbstractContainer
Ext.layout.container.AbstractCard
Ext.layout.container.AbstractContainer

Source Only
Ext.chart.axis.Abstract
Ext.AbstractDataView
Ext.layout.component.AbstractDock
Ext.layout.container.AbstractFit
Ext.AbstractManager
Ext.util.AbstractMixedCollection
Ext.grid.feature.AbstractSummary

Concerns:
- Similar to "Are you my Manager?"
- What should I use? (Ext.AbstractContainer, or Ext.layout.AbstractContainer, or Ext.layout.container.AbstractContainer)
- Some things have an Abstract while others do not.
- Some have documentation
- Overall objectively looking at the Ext Js 4, how would one consistently know what to expect when it comes to Abstracts and their intended use

Example Set #5 - Communication
Ext.Ajax
Ext.data.Connection
Ext.data.Request
(more, such as Proxy, JsonP,etc.)

Request:
The implementation of communication is coupled tightly with Ext.data.*
- It would seem that a logical distinction exists between the use of data and the ability to 'move' data
- Is an Ext.data.communication or Ext.communication an option?


Example Set #6 - Proxy
Ext.data.Batch
Ext.data.Operation
Ext.data.ResultSet

Request:
These are all Ext.data.proxy, functions, so should they also go under this namespace?


Example Set #7 - Models
Ext.data.Association
Ext.data.BelongsToAssociation
Ext.data.HasManyAssociation
Ext.data.Model
Ext.data.validations (Notice the lowercase v, which is in the source)

Request:
It would be helpful to have a single namespace when working with Models, like we currently have with Proxy's or Reader's

Example Set #8 - JSON vs JsonP vs JsonP vs Json vs JsonProvider
Ext.JSON
Ext.data.JsonP
Ext.data.reader.Json
Ext.data.proxy.JsonP
Ext.direct.JsonProvider

Request:
Those are the JSON classes in Ext JS 4, I am not sure if this is simply a cleanup of the names, or is there an opportunity for further cleaning up, DRY code, or things like the Adapter pattern.

Example Set #9 - Stores

No examples

Request:
This could also be cleaned up within Ext.data, following the same pattern as Ext.data.Proxy

[CasualNetworks]

With work being queued for Ext JS 4.1, are plans still in motion to review the above and/or release the API Style Guide? The API Style Guide I see as one of those best practice items, provide another tool for consitency and education on developing/extending on top of a framework like Ext JS.

Ext JS 4.0 Final Available Today
As well as the new guides and expanded documentation, we’ve also vastly improved our naming conventions — standardizing how we name classes, configurations, methods and events. We’ll release an Ext JS style guide explaining these rules shortly, but in the meantime checkout the newly revamped documentation center.