IDE Minutes 2007-12-06

From MemberWiki

Jump to: navigation, search

Attendees this week

  • Lori Hylan-Cho <lorihc(at)>
  • Ingo Muschenetz <ingo(at)>
  • Kevin Hakman <khakman(at)>
  • Jon Ferraiolo <jferrai(at)>
  • Bertrand Le Roy <Bertrand.Le.Roy(at)>
  • Stew Nickolas <nickolas(at)> (QEDWiki)
  • Phil Berkland <berkland(at)>


Kevin: Work and learnging from API expressions in API Metadata strawman format?

Bertrand: Worked in API metadata strawman example dojo data picker expressed in the metadata. Added a few comments after the XML on the wiki page. One of the things the descriptions are in the same file. For localization… you could have a separate file for the text. What can we do about methods that can take several types, for example a datepicker can take date object or string. Getters and Setters could have indicators that they both access the same property somehow? For more see:

Ingo: added Google Map as an API metadata example. In general I have same comments as Bertrand. “jsType” should probably be just “type”. In GMAP they often pass in object literals as params for constructors. Perhaps need to provide more specifics on what those object literals are and the requirements for that object literal as a “property bag”. For more see:

Bertrand: it’s very common to do that. Perhaps we need some was to describe the pseudo-class.

Lori: That was the point of my email last night.

Jon: Is that the same as the

Kevin: TIBCO GI does that too. Uses object literals for some arguements in methods.

Bertrand: so maybe in that case the jsType can be a special pointer to a description somewhere else in the metadatafile.

Bertrand: for HTML elements we probably need the same, since it's not a javascript type, put again perhaps place a pointer to a description to some other location in the file, like the object literal.

Jon: process recording issues that Info and Bertrand have come across.

Info: I’ll will add open items to the IDE API metadata.

Bertrand: why <returnTypes> with an "s", plural?

Ingo: There are examples like $ that can potentially return multiple types.

Bertrand: perhaps just return "object" in that case thus enabling <returnType> (no s)

Open issues:

  • localization,
  • pointers to more complex type
  • possibility of multiple parameters and variants
  • returnType or returnTypes

Jon: I can take a crack at writing up these issues

Kevin: Thanks Jon.

Stack Trace:

Bertrand: problem is that if you have anonymous function, which is most fns in modern frameworks, the javascript engine does not know what this got assigned to, and what we thing of as the function is not the variable to which we assign the function. Some js debuggers have logic to look at where the function was designed to show you the local name (the name of the variable when it can) of the function in firebug and venkman and other debuggers – but this is not the case in Visual Studio. So what MSFT is doing the debug version of the script, we assign a variable but we replace the dots with $. Thus becomes namespace$foo$bar$do() which enables a clearer stack trace. The probably is that this adds hundreds or thousands of global variables….but nonetheless it’s only a debug issue.

The debug and runtime version are different. The $ substitutions for . are only present in the debug version.

Jon: Ingo, Phil… any reason that the registry in somecases will use this technique and therefore should stay clear of using things like dojo$ as the first 5 letters of the variable name.

Bertrand: global names stem form the globalnamespace so collisions are very unlikely and can be under the control of the library creators.

Phil: I do not see a problem. I do not know that we’d implement this, but not problem with that being registered.

Kevin: Jon of the open issues from last week is there one that we can begin to address in the next 20 minutes.

Jon: Let’s start with issue #1: “Toolkit identification, configuration, loading, and initialization”

Jon: If you have dojo date picker, then this info is about loading, initializing, c

Jon: what features, what approach, then what markup to convey that approach:

Jon: Workflow: the IDE would know that it needs to load a version of a library, IDE would need to know root directory, either in IDE distribution, or on the disk, then it would scan through directory tree, then scan through widget files, then assuming it has a particular widget, then load the right js files that are needed including the ones for the toolkit.

Discussion of the examples

jMaki approach: point to library, then resource directory Dreamweaver approach: point to each asset, no provision for wild card asset directory

Lori: If your widget

Jon: case of dojo suggesting for deployment you use the fully qualified AOL URL.

Jon: dominant paradigm: even if you do not know what you’re doing

Purpose of asset files: which files need to be uploaded to deploy.

Lori: what DW can’t handle is if one file depends on a bunch of other file, but is not specifically included anywhere.

Jon: couldn’t you write a bit more code to handle that case?

Lori: yes but not in this release and it’s more complex since DW looks to the HTML page for it’s dependencies and such a case (a collection of dependent files at a path) would not be explicitly expressed in standard HTML at this time.

Jon: Metadata could handle both cases. I think need jMaki guys involved in this discussion.

Kevin: Hey we’re 9 minutes past the hour and I want to respect people’s time. Let’s continue this next week, hopefully with jMaki.

Thanks all this has been quite useful.

Personal tools