Thank you for reporting this bug. We will make it our priority to review this report.
Ext JS Premium Member
[B3]Enhancement - API style guide suggestions before release
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:
- Logical Grouping
Example Set #1 - Native (like) Objects
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
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?
- 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
- 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
(more, such as Proxy, JsonP,etc.)
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
These are all Ext.data.proxy, functions, so should they also go under this namespace?
Example Set #7 - Models
Ext.data.validations (Notice the lowercase v, which is in the source)
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
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
This could also be cleaned up within Ext.data, following the same pattern as Ext.data.Proxy
Last edited by CasualNetworks; 14 Apr 2011 at 9:14 PM.
Reason: BB code edits
Ext JS Premium Member
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.