[OpenAjaxIDE] Microsoft Ajax metadata format quick start guide
alex at dojotoolkit.org
Thu Jul 12 12:04:43 PDT 2007
On Thursday 12 July 2007 11:08 am, Bertrand Le Roy wrote:
> That subject was discussed at yesterday's meeting.
> Actually, it's a fact that many existing and widely used frameworks
> extend built-in prototypes and instances.
Hence we have a problem that needs solving. That it is so today creates
no viable case that it *should* be so or that we as a body have any
business sanctioning such interoperability-destroying practices.
> Even frameworks that make a
> major point of having minimal impact on the global namespace actually
> introduce potential conflicts in ways that are not always easy to
> see. For example, it's common practice to have APIs that query the
> DOM and return DOM elements that are mixed-in with additional
Lets be VERY clear about this: toolkit vendors do this because IE does
not allow any useful form of subclassing of DOM elements. Dojo provides
a widget system and the NodeList classes for this very reason (we wrap
but never extend). Other browsers have some means of DOMElement
subclassing although they are far from ideal or coherent at this point.
Every toolkit vendor I know would like to have this fixed, but so far
MSFT has neither shared any data about IE.next WRT this issue (or any
others), nor have repeated calls for a solution to this issue been
heeded in previous IE releases. Perhaps you can press the case
> Do you also want to prohibit that?
I'm in favor of documenting these hacks and noting the interop pitfalls.
That said, what you're describing only happens once a node is "owned"
by a block of code, it's not a global, de-facto and by-default behavior
imposed on every node in the system. It is, clearly, a distinct and
separate question from that of root object prototypes.
> I think it's a fact
> that built-in objects will be extended because it's very useful to do
It's this body's job to set standards for interoperability, not to
condone a race to the bottom.
> I'm sure Dojo does a much better job than we do at never adding
> an expando to any object that it doesn't own but we chose to be very
> open about everything we had so that we can spot problems that are
> likely to be found in other libraries too.
Dojo is not (and never has been) 100% "clean". What OAA needs to do is
to set standards that libraries need to meet. Setting them high is a
point of leverage in getting toolkit vendors (Dojo included) to do the
right thing. Dojo only has less work to do because we knew these
standards were coming when we sat down to do 0.9. I actually think
that's a great case for why we should set the standards high.
> You could take the approach of prohibiting everything but the likely
> result would probably be that toolkit vendors would just go "ok,
> fine, we won't be OpenAjax-compliant then" rather than break their
> customers' applications. I don't think that's what we're trying to
> achieve here.
Fair enough, but this one is straightforward and has known interop
issues which aren't discoverable except at runtime in composed systems.
It's hell to debug and easily avoidable through social pressure on
> The goal of the registry as far as I understand it is to manage
> conflicts while allowing the flexibility that is required by existing
Yep. I think the resolution would need to be something like "we'll
accept these 10 but not these other 5, therefore you can't claim
to "own" them and must warn your users about them". That seems
equitable to the state of the art.
> I think it would also be useful if the Alliance provided guidelines
> in the form of "SHOULD" recommendations such as "libraries SHOULD NOT
> extend Object.prototype or Array.prototype". Whether they should
> extend instances of DOM elements
Note the terminology here. "instances" vs. "prototypes". If root DOM
Node prototypes were exposed sanely across browsers, I'd be advocating
just as strongly against extensions to them. Instances are a different
ballgame than prototypes.
> or prototypes of other objects is
> still, I believe, a subject to debate in the community and certainly
> a common practice so if we provide recommendation here it should
> probably be to limit the number of extensions rather than prohibit
> them entirely. Let's focus on making the registry a useful tool to
> the community instead of trying to impose rules that are too
> restrictive to be followed.
> -----Original Message-----
> From: ide-bounces at openajax.org [mailto:ide-bounces at openajax.org] On
> Behalf Of Alex Russell Sent: Thursday, July 12, 2007 10:15 AM
> To: ide at openajax.org
> Subject: Re: [OpenAjaxIDE] Microsoft Ajax metadata format quick start
> On Thursday 12 July 2007 7:46 am, Jon Ferraiolo wrote:
> > Hi everyone,
> > Bertrand has sent in some emails describing the list of globals and
> > been going through some of these documents and I found it a bit
> > hard to figure out where I could find an executive summary and some
> > examples. Here is what I found:
> > Executive summary of XML metadata format:
> > *
> > http://weblogs.asp.net/bleroy/archive/2007/04/23/the-format-for-jav
> >as cript-doc-comments.aspx
> > Ajax: * http://openajax.org/pipermail/interop/2007q2/000168.html
> Ouch...that's a long list. Are we going to allow any vendor to
> "register" globals which extend root object prototypes? I had thought
> that the consensus was "no", and that they should be flagged as
> dangerous and potentially conflicting (otherwise interop is a joke).
> Alex Russell
> alex at sitepen.com A99F 8785 F491 D5FD 04D7 ACD9 4158 FFDF 2894
> 6876 alex at dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242
> 59C3 9723
alex at sitepen.com A99F 8785 F491 D5FD 04D7 ACD9 4158 FFDF 2894 6876
alex at dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 186 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20070712/d1f280b2/attachment.bin
More information about the IDE