Registry Issues
From MemberWiki
Registry Issues
This wiki page lists the open and closed issues relative to the OpenAjax Registry. Usually, the issues listed here have to do with overall policy and process having to do with developing and maintaining the Registry. Discussion about the Registry entries for a particular toolkit happens elsewhere, such as on the wiki page "Registry Candidates for Foo" (where Foo is the name of the toolkit), although if general policy issues arise during the discussion, those policy issues might appear here.
The write-ups on this wiki page for individual issues should not go beyond executive summaries. Detailed write-ups should be posted elsewhere and referenced from this page.
OPEN ISSUES (most recent issues listed at top)
Issue 7: New fields for CSS classnames and HTML attributes
Original write-up
There has been some email discussion on the interop mailing list recently about whether the Registry should list the CSS classnames and HTML attributes used by a particular Ajax library.
Regarding CSS classnames, Ajax toolkits that ship with a set of UI controls typically allow styling of those controls via CSS, where CSS classnames are a prime mechanism for allowing an individual developer to control the styling of particular contols. If two toolkits happen to use the same CSS classnames (e.g., class="combobox"), then styling collisions can occur. Obviously, interoperability would be improved if the "foo" library prefixed all classnames with their registered prefix (e.g., "foocombobox").
Regarding HTML attributes, some Ajax libraries add their attributes to HTML elements. Lightstreamer, for example, adds source="...", table="...", item="..." and field="..." attributes to DIV elements. Dojo adds various attributes, including dojoType="..." to DIV elements and an event="..." attribute to SCRIPT elements. Two primary reasons why Ajax libraries do not leverage XML namespaces for their custom attributes are: (a) XML namespaces are not implemented satisfactorily across today's crop of commonly used browsers, (b) it's faster and simpler to just add new HTML attributes, which the browsers allow today with no problems.
Discussion
Adam Peller said that these are important interoperability issues, perhaps more important than JavaScript global collisions, but that there are practical issues which might prevent the Ajax libraries from doing proper "namespacing" (i.e., prefixing) of their classnames and attributes. The main worry is that classnames and attribute names are part of the "API contract" that a toolkit has with its developers. Potentially, toolkits that do not prefix their classnames and attributes today could offer redundancy where newer versions support both the older syntax and the newer (namespaced) syntax, but then the users of the toolkits would have to be educated about this. (Note: these questions overlap with the "relocatable" question for JavaScript globals).
Proposed resolution
Here is a specific proposal for people to consider:
Add the following 2 fields to a registry entry for CSS classnames
-
classnames_to_approve -
classnames_to_acknowledge
Add the following fields to a registry entry for HTML attributes
-
attributes_to_approve -
attributes_to_acknowledge
As Bertrand said in the phone call on 2008-03-05, we could apply the same criteria for CSS classnames and HTML attributes as we do for globals, where prefixed entries are "approved" but non-prefixed entries are simply "acknowledged".
CLOSED ISSUES (most recent issues listed at top)
Issue 6: OpenAjax.Registry.libraries instead of OpenAjax.Registry
Original write-up
During discussions within the IDE WG and Gadgets TF on OpenAjax Metadata Specification, we have discovered the possible need in the future to use the OpenAjax Registry as an industry-standard registry for (micro)formats, particularly for payloads within pub/sub messaging over the OpenAjax Hub.
Proposed resolution
Store the list of approved Ajax libraries at OpenAjax.Registry.libraries instead of OpenAjax.Registry. This will allow future extensions to the Registry, such as OpenAjax.Registry.formats.
Discussion
An alternative was mentioned in email, where instead of OpenAjax.Registry.formats and OpenAjax.Registry.libraries, we might go with OpenAjax.Registry.formats (for libraries) and OpenAjax.formats (or OpenAjax.microformats) for
standardizing the format of particular payloads associated with particular standardized
topic names.
Resolution and rationale
Approved at 2008-01-30 teleconference) Store the list of approved Ajax libraries at OpenAjax.Registry.libraries instead of OpenAjax.Registry.
The main rationale was that we might want to have multiple registration collections,
and when communicating with the public, it is probably better to keep it simple
and say that there is a single OpenAjax Registry, but it manages muliple types of
information.
Issue 5: Need text to talk about jQuery and DWR approaches for avoiding name conflicts
Original write-up
jQuery allows the user to use "$" as a convenient shorthand to some frequently used features, but in recognition that it isn't the best thing to snatch this global and in recognition of likely conflicts when multiple toolkits are used on the same page (e.g., Prototype.js also uses "$"), it allows the user to control whether "$" is activated.
We need to study jQuery and determine what features we can adopt as OpenAjax Best Practices.
Proposed resolution
Add a new section to the Registry wiki page that discusses the techniques used by jQuery and recommends them as best practices for similar situations. (Note: such as section was added on 2008-01-28).
Discussion of proposed resolutions
At the 2008-01-30 teleconference, the consensus was that the current write-up is generally good, but we need to make some additions and fixes. Therefore, leave open and Jon should propose updated text for review.
Resolution and rationale
New text was submitted in advance of the 2008-02-20 phone call and there were no objections to the proposed text, although some wanted to see the final details about how OpenAjax Conformance works and relate that back to the 3 new conformance criteria.
Issue 4: Stack traces in IDEs and impact on Registry
Original write-up
Bertrand has put together a wiki page that explains why wildcard approaches can benefit developers using an IDE:
The IDE WG will discuss Bertand's email. Based on that discussion, we might want to change some of the wording in the Registry wiki page to talk about acknowledging how some developer tools use prefix approaches in order to provide better stack traces to developers.
Proposed resolution
The following proposal is a copy/paste from the following email:
The IDE WG discussed Bertrand's write-up on the problem with IDEs doing stack traces for anonymous functions and MS's solution where they ship both a debug and release version of the Ajax library, where the debug version includes some additional features to facilitate development within Visual Studio:
- type checking information
- additional metadata to help with code completion,
- (this is the one that is pertinent to the Registry discussion) an aliasing strategy for anonymous functions such that that each Sys.foo.bar() function has an alias named Sys$foo$bar() so that stack traces are more understandable
During the IDE WG discussion on the aliasing approach to improve stack tracing, the consensus was:
- Microsoft's approach is an "interesting solution to a real problem".
- It would be OK for the Registry to somehow acknowledge (or to some level even condone) this practice
Note that MS's solution requires that the toolkit defines the alias objects. Microsoft is using Sys$*, but other toolkits could use alternate naming approaches. For example, Ext.js has global object "Ext". Let's suppose that Ext wanted to integrate with Visual Studio and other IDEs such that stack traces were better, but felt that reserving Ext$* was not a good thing for the world. Therefore, instead of Ext$*, they might use global variable names something more obscure such as Ext$DBG$*.
My proposal:
- 1) In the specific case of MS Ajax, we should _acknowledge_ Sys$* and include a comment in the Registry entry that explains when and why it is used.
- 2) For the more general case, we should add a new section to the Registry wiki page (http://openajax.org/member/wiki/OpenAjax_Registry) that discusses the stack trace issue and gives best practice guidelines to Ajax toolkit developers about what they should do if they want to take advantage of this aliasing approach. (Note: these changes were added to the Registry wiki page on 2008-01-28.)
Resolution and rationale
At the 2008-01-30 teleconference, we agreed it was OK to close this issue. We have already decided at a previous teleconference that the above proposal was good, but we wanted to be careful and give the committee members another chance to review and provide feedback. No one objected, so we decided to close the issue.
Issue 3: Criteria for judging Registry submissions
Original write-up
(This is just a placeholder to remind us to develop a list of criteria for judging Registry submissions.)
Resolution and rationale
Jon included some proposed criteria on the OpenAjax Registry wiki page. The initial draft was received favorably. Therefore, it makes sense to close this issue. If controversial things come up about particular aspects of the criteria, then we will raise new issues.
Issue 2: Wildcard registrations
Original write-up
Bertrand submitted an email to the group (http://openajax.org/pipermail/interop/2007q2/000132.html) where he proposes the convention that whenever a particular toolkit is recognized to use a given namespace Foo, that should mean not only that Foo.* is ok to use by that toolkit, but also Foo$*. The reason why we're doing that (i.e., Microsoft Ajax) in this particular circumstance is so that the method is no longer anonymous and thus appears in a debugger's stack trace. We've found that to be extremely useful and a great help to our customers. It is consistent with EcmaScript specs in that Ecma recommends the use of the dollar sign for machine-generated identifiers.
Jon's proposed resolution
I propose a slight modification to Bertrand's proposal. Instead of always reserving "Foo$*" whenever "Foo." is registered, I suggest:
- We offer wildcard registrations where a final "*" in the name of the global is used as a wildcard registration
- We do not automatically reserve "Foo$*" for each "Foo." but instead have toolkits explicitly register both globals (i.e., ["Foo", "Foo$*"]) if they so choose.
Resolution and rationale
There was extension discussion at a telecon (/member/wiki/Interoperability_Minutes_2007-10-31#Topic:_Wildcards). The resolutions:
- We offer wildcard registrations where a final "*" in the name of the global is used as a wildcard registration
- We do not automatically reserve "Foo$*" for each "Foo." but instead have toolkits explicitly register both globals (i.e., ["Foo", "Foo$*"]) if they so choose.
- In most cases, we will only allow wildcards for "acknowledged" globals rather than "approved" globals.
The rationale is that we want the Registry to be a good source of information for developers so that they can code their JavaScript in order to avoid name collisions. Therefore, we want to make developers aware of existing or legacy use of prefixing techniques (e.g., Foo* instead of Foo.*) within popular Ajax toolkits, even if we do consider such techniques as inconsistent with our recommended best practices.
It is also important to note that we believe that sometimes it is better to explicitly list each global separately (e.g., FooApple, FooOrange, FooBanana) versus wildcarding (e.g., Foo*) because that provides more detailed and explicit information about what developers should expect, but when there are large numbers of such globals with a common prefix or if there is uncertainty about which distinct globals were used, then wildcards might be justified.
Issue 1: How to represent DOM extensions within the Registry
Original write-up
Some Ajax toolkits extend the W3C DOM. How best to express that within the Registry database?
Bertrand has suggested that we adopt the convention HTMLElement.prototype.foo, but Jon has two reasons why this doesn't feel right:
- It seems dangerous to tie the definition to HTMLElement since other presentation languages might be useful. In particular, SVG is supported on 3 of 4 major browsers now as native features and SVGElement would be more appropriate when the Ajax application leverages the browser's support for SVG. (Not sure how the DOM works with VML.)
- You would expect that some DOM extensions would only apply to a subset of HTML elements. For example, you could imagine someone adding DOM extensions to HTML table elements but not impacting other HTML elements such as DIV or P.
Proposed resolution
Bertrand recommended the format HTMLElement.foo, but I don't think that is general enough. Some extensions aren't for all elements in the HTML language and instead only target a subset of the elements. Also, browsers are adding support for elements from other languages. Most notably, Firefox, Safari, and Opera all support SVG elements, which build from SVGElement, not HTMLElement. Therefore, I propose the following invention/convention: !DOM.<DOM-interface>.prototype.whatever. For example, !DOM.HTMLElement.prototype.foo indicates a new foo property on the HTMLElement interface. !DOM indicates a DOM extension. The "!" character is used because that is an invalid character for a JavaScript object and therefore won't conflict with any global names.
Resolution and rationale
At the 2008-01-30 teleconference, we accepted the above proposal. We agreed that it was appropriately flexible and had sufficient extensibility provisions.
