IDE Minutes 2007-12-06
Attendees this week
- Lori Hylan-Cho <lorihc(at)adobe.com>
- Ingo Muschenetz <ingo(at)aptana.com>
- Kevin Hakman <khakman(at)tibco.com>
- Jon Ferraiolo <jferrai(at)us.ibm.com>
- Bertrand Le Roy <Bertrand.Le.Roy(at)microsoft.com>
- Stew Nickolas <nickolas(at)us.ibm.com> (QEDWiki)
- Phil Berkland <berkland(at)us.ibm.com>
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: http://www.openajax.org/member/wiki/IDE_API_Metadata_Strawman_Proposal_DojoDatePicker
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: http://www.openajax.org/member/wiki/IDE_API_Sample_Google_Map
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.
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)
- 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.
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 http://www.openajax.org/member/wiki/IDE_Issue_1
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.