Best Practices Libraries
From MemberWiki
(Placeholder wiki page. No content yet.)
This wiki page is meant for gathering a list of candidate Ajax best practices. This page is one of a series of wiki pages that collect candidate Ajax best practices broken down as follows:
- Best Practices Applications - Best practices for Ajax applications (i.e., the software developed by the Ajax application developer, who is likely to build his application using an Ajax toolkit)
- Best Practices Browsers - Best practices for Web browsers so that they support Ajax and OpenAjax in an optimal manner
- Best Practices IDEs - Best practices for IDEs that support Ajax developments
- Best Practices Libraries - Best practices for Ajax JavaScript runtime libraries
- Best Practices Servers - Best practices for server frameworks that produce Ajax-powered user interfaces
Contents |
Approved Best Practices
Note: the official list of approved best practices probably will be located somewhere else, perhaps on the public part of http://www.openajax.org, but we haven't decided on the location yet.
Candidate Best Practices
This section is meant to capture candidate best practices that at least one Member believes we should evangelize to the browser vendors. This list has yet to be discussed and approved by the rest of OpenAjax Alliance.
- (just getting started - not much here yet)
General/uncategorized
- Do we want to have a best practice that tells developers to avoid for(in) on arrays and instead use for(;;)? This would be to deal with the reality of the industry that lots of toolkits include prototype.js and prototype.js overrides the array class which causes for(in) on arrays to not work as expected.
- (Something to the effect of) Ajax runtime libraries need to address the scenario where multiple components are using a given library, including scenarios where different components use different versions of the given library.
- Future versions of Ajax toolkits (runtime libraries) should (not must!) be upwardly compatible with the publicly documented feature set and APIs from previous versions.
- Complete specifications for Ajax toolkits should (not must!) be available that clearly document the available interfaces and the behaviors that occur from exercising those interfaces.
Globals
- (Something to the effect of) Libraries must restrict themselves to small modifications to the global state of the browser JavaScript environment, usually restricted to adding 1-3 objects on the window object where these new objects are named such that the first <n> letters match the first <n> letters of the toolkit's prefix. For example, to conform to our best practices, the OpenAjax library would use the prefix "OpenAjax" and all of its global objects would begin with "OpenAjax".
- In particular, libraries must not modify the prototypes of core objects. (Note: there are special treatment exceptions to this rule for a small number of industry leading Ajax libraries. See Exceptions below.)
Exceptions
- (Something to the effect of) In recognition of existing industry widespread adoption of certain Ajax technologies, some existing Ajax libraries are granted special treatment in how they modify the JavaScript run-time environment. Two libraries have been identified so far as having strong enough marketplace presence to get special treatment: Prototype and json.js. These libraries extend the JavaScript run-time environment in significant ways, and OpenAjax Alliance has allocated special-case entries to them in the Global Object Registry.
