Breaking the grip JS has on the DOM: Difference between revisions

Breaking the grip JS has on the DOM (view source)

Revision as of 12:46, 9 August 2005

2,109 bytes added , 9 August 2005

more info about nsIDOMClassInfo and using nsIScriptGlobalObject as "aScopeObject"

MarkH

32

edits

@@ Line 34: / Line 34: @@
 The existing nsIScriptGlobalObject interface will move towards a model where there is a global script context per language.  GetGlobalJSObject and GetContext would be deprecated, with a new method allowing the desired language to be specified.
-Some concept of a "language ID" will need to be invented. enum/char */atom?
+The 'context stack' will need to be enhanced to allow each language to have their own implementation for pushing and poping context.  Thus, when the DOM requires an item on or off the context stack, each language will be called once to do its own thing.
-The 'context stack' will need to be enhanced to allow each language to have their own implementation for pushing and poping context.  Thus, when the DOM requires an item on or off the context stack, each language will be called once to do its own thing.
+nsDOMClassInfo will be split into a language neutral nsDOMClassInfo, and a JS specific nsIXPCScriptable.  The JS specific code in this file will need to be re-written for Python, but this should allow all DOM knowledge to be reused by the Python implementation.
+Need to agree on a single "script language ID".  nsIProgrammingLanguage defines a set of integers, while nsIScriptElement uses a generic "char *".
-nsDOMClassInfo needs to be addressed - presumably its functionality is necessary for other languages - but it is heavily JS specific.
+Is nsIDOMClassInfo just a poor-man's IDispatch?  Should we just invent a new interface designed for truly dynamic object models, and wrap the DOM in that?  This will require someone from Mozilla driving it.
 Below are specific implementation notes:
@@ Line 45: / Line 47: @@
 * Existing JSObject replaced with void
+* Existing "void *aScopeObject" (ExecuteScript/EvaluateStringWithValue/CompileScript), replaced with nsIScriptGlobalObject.  The language impl can then get the "void *" for their language via either sgo->GetLanguageContext() or (static) nsIScriptGlobalObject::GetDefaultLanguageObject()
 * Need a "WrapNative" type function
-* ExecuteScript - param 2 changes from "void *aScopeObject" to "nsIScriptGlobalObject *aScopeObject".  JS impl fetches underlying JSObject.
 * FinalizeClasses method - JS does the ClearScope/ClearWatchpointsForObject/ClearRegExpStatistics?
@@ Line 59: / Line 61: @@
 nsGlobalWindow is the main implemention of nsIScriptGlobalObject
+* XXXX - Still need to understand GetNativeContext
 * nsIScriptGlobalObject probably needs to remain a single object (ie, not per language).  It will move towards keeping a list of "IScriptContext *ctx, void *global" items, one for each language.  New method:
    nsresult GetLanguageContext( [in] language_id language, [out] nsIScriptContext **retLangContext, [out]void **retLangGlobal);
 mJSObject and mContext will both be dropped in favour of the list.  The concept of a single context/global will be deprecated - callers will be encouraged to use the new method.
-GetContext()/GetGlobalJSObject() remain for b/w compat.  They are equivilent to "GetLanguageContext('js', ...)"
+GetContext()/GetGlobalJSObject() remain for b/w compat.  They are equivalent to "GetLanguageContext('js', ...)"
+* New static method GetDefaultLanguageObject(PRInt32 language, void **retLangGlobal).  For JS, this will return ::JS_GetGlobalObject(ctxt)
 * New method to set and get "properties" - nsGlobalWindow does this for JS.  Setting a property should presumably set it in all languages (via the global attached to the context).  Getting is tricker - what if the property is in a different language?  Or in multiple languages?
@@ Line 83: / Line 89: @@
 Existing nsIJSContextStack "@mozilla.org/js/xpc/ContextStack;1" service is replaced with language generic ContextStack.  This is almost identical to the JS version, but all functions accept a 'language_id' param, to indicate which language they are interested in.  Existing 'js' specific context stack could be re-implemented using the new one.
-Probably need a new interface for each language to do their thing.  The DOM will simply ask for a new context - something must do the delegation to the languages.
+Probably need a new interface for each language to do their thing.  The DOM will simply ask for a new context - something must do the delegation to the languages. XXX - but how do we know what languages we need to work with?  Can we introduce new languages to the mix even after a context has been pushed?
 What about http://lxr.mozilla.org/seamonkey/source/dom/public/nsIScriptContext.h#356 - it
@@ Line 92: / Line 98: @@
 === nsScriptLoader ===
-* nsScriptLoader's interface is language neutral.  Theoretically only the implementation need change.
+nsScriptLoader's interface is language neutral.
+* nsScriptLoadRequest will have either a nsIScriptContext or language ID as a member.
+=== nsScriptLoaderObserver ===
+Presumably will need to become script language aware.  eg, scriptAvailable() method has text of the script passed - not much use without also knowing the language.  Possibly replace with nsIScriptElement, which does have the language ID
 === nsDOMClassInfo ===
-Some of this will need to be generalized for use by multiple languages.  Specifically, the "tables" of interfaces and access to the extended type information would be unmaintainable across multiple languages.
+Lots of DOM namespace magic happens here, but it is very JS specific.  We will:
+* Create ns(I)DOMClassInfo.  It contains all the existing code that works with nsDOMClassInfoData - that includes most of the "tables" defined using macros.
+* nsDOMXPC will have all the JS specific code, which is currently implementing nsIXPCScriptable.  This is the bulk of the existing nsDOMClassInfo implementation.
+* This language neutral interface will allow language "helpers" to be explicitly installed, and will then be able to be fetched by the existing nsIClassInfo::GetLanguageHelper() function.  Thus, anyone with an nsIDOMClassInfo will still be able to get the JS helper.
+* Decide what to do with the various flags - eg, ALLOW_PROP_MODS_TO_PROTOTYPE.  Presumably these will have some meaning to languages other than JS, but they are defined in a JS specific interface (nsIXPCScriptable)
+The Python language implementation will then need to write an equivalent to the new nsDOMXPC.  This will be the magic where attributes are got/set for objects, etc.  This Python implementation will need to lean heavily on nsDOMClassInfo.
 === nsXULPrototypeScript ===