[OpenAjaxIDE] OAA IDE WG Minutes 2007-12-06

Kevin Hakman khakman at tibco.com
Thu Dec 6 10:29:41 PST 2007

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> 
*	Stu 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

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

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 arguments
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

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 namespace.foo.bar.do()
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

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

Lori: If your widget 

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

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. 

Retrieved from



Kevin Hakman

Director, Developer Evangelism 

Co-Founder General Interface Enterprise Ajax Toolkit          

P: (415) 225-4259  E: khakman at tibco.com

TIBCO Software Inc.  


All information in this email is proprietary and confidential.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/ide/attachments/20071206/ceec22d0/attachment.html 

More information about the IDE mailing list