[OpenAjaxIDE] Minutes 20071011

Jon Ferraiolo jferrai at us.ibm.com
Thu Oct 11 11:58:54 PDT 2007

Thanks to Lori for taking minutes today.

IDE Minutes 2007-10-11

URL: http://www.openajax.org/member/wiki/IDE_Minutes_2007-10-11

Attendees this week
      Lori Hylan-Cho <lorihc(at)adobe.com>
      Ingo Muschenetz <ingo(at)aptana.com>
      Kevin Hakman <khakman(at)tibco.com>
      Bertrand Le Roy <Bertrand.Le.Roy(at)microsoft.com>
      Greg Murray <greg.murray(at)sun.com>
      Jon Ferraiolo <jferrai(at)us.ibm.com>


Kevin asking about Widget Task Force and whether that would be going

Ingo: We ended last week's discussion by talking about having a few sample
widgets that we'd use as a base for comparing implementations. Did we ever
finish that discussion?

Kevin: We should definitely do this.

Info: Greg suggested the Dojo Clock Widget should be one of them.

Kevin: Yes, because it has a certain degree of depth to it.

Jon: Maybe when we get into a deeper discussion of a spec or an
implementation, it'll be easier to define which widgets should be the base.

Kevin: Let's continue discussing the executive summaries, and then move on
to implementation details.

Ingo: I'd rather have the base widgets sooner rather than later.

Lori: Me too.

Jon: I'm worried about getting into a waterfall approach where we go back
and forth between the implementation details and the base widgets,
expanding the test set, etc. But maybe it'd be ok to have a base set to
start comparing.

Ingo & Lori: That works.

Kevin: OK, so Dojo Clock...

Lori: And I already did Spry Tooltip.

Kevin: Should we do a datagrid? Or a map?

Jon: Or the Open Ajax Hub?

Kevin: So, the clock, the tooltip, the hub, and some standalone function

Bertrand: How about a component that talks to the server? Like an
Auto-Complete component?

Jon: Yes, a widget that talks to the server is something that we should
look at relatively early, but it's OK with me to push this off to the
second wave.

Kevin: We need to find an auto-complete...

Lori: There's a Spry one, a YUI one...

Greg: Scriptaculous seems to be the one everyone likes, prototype has
one... What about a spell-checker?

Jon: Why don't we go with Auto-Complete for now.

Greg: Trees and comboboxes are widgets that everyone wants to use.

Bertrand: Maybe the framework vendors should contribute test cases?

Kevin: Let's try to tackle three widgets/frameworks up front, as a start.
Dojo Clock, Scriptaculous/YUI Auto-Complete, a Spry widget or the Open Ajax
Hub (non-visual), maybe a non-visual XMLHttpRequest widget.

Greg: Flash sound?

Kevin: I'm proposing the OAA Hub, YUI Auto-Complete, Dojo Clock,
straight-up JS function. What should the characteristics of the JS function

Ingo: Is it meant to represent a simple snippet of code, or is it meant to
complement the Hub because the Hub has such a basic API?

Kevin: It's conceivable that someone could write a JS function and document
it such that an IDE could take advantage of the documentation...

Ingo: What about the $ function, which everybody uses?

Jon: I think we should crawl before we walk, and $ is more of a walking

Ingo: I'm OK with just having three right now, since I'll need to write
these, and I'm pretty pressed for time.

[laughter likely indicating agreement]

Ingo: Our current metadata format comes from a library perspective. Looking
at adding more widget-specific descriptions. Currently have two XML files
-- one a library description, and one an (installation?) file. Use
JSDoc-type syntax; also read in XML-style description. Generate
documentation on the fly from XML or meta-data on top of the JS.

Bertrand: What is SUpdate?

Ingo: It's an idea we had... [something about microformats] ...but not part
of our proposal initially.

Ingo: We allow for multiple parameters, multiple return types, info about
browser compatibility, whether it's tied to some sort of standard, etc.

Jon: I'm looking at some of the samples... <availability> tag, <browsers>


Ingo: There's some inheritence here (relating to browsers).

Phil: Any thought to doing it the other way around?

Ingo: You mean specifying the browsers that it *doesn't* work on?

Phil: Yes.

Ingo: We considered it, but we're expecting that people would be relying on
specific browser extensions to HTML, and thus it's easier to say that I
know it works in this browser.

Bertrand: How do you handle the localization of this file?

Ingo: Currently we'd need separate XML files, but ideally we'd just
separate out the localizable bits. All you'd really need to localize are
the descriptions and the examples, which is very straighforward.

Bertrand: You can handle all the languages, not just JavaScript?

Ingo: Yes.

Kevin: Well, all the languages that support constructors, variables, etc.

Ingo: Right. PHP and Ruby are also being considered.

Jon: Any thought to JS 2?

Ingo: First we're focusing on JS 1.8, then JS2.

Jon: What's 1.8?

Ingo: It's going into Firefox 3.

Jon: Does it allow for namespacing?

Ingo: I don't think so; I think that's going into JS2.

Jon: So 1.8 is still based on spidermonkey, and JS2 will be based on

Ingo: We definitely are handling namespaces, because we had to for Adobe
AIR. The types include the class names. We do allow for classing,
superclassing, and there are datatypes. I also like the idea of having
subtypes to prompt the IDE for what *kind* of string, for example, goes

Kevin: I like the subtype stuff that Lori did.

Ingo: We tried to stick to JS as JS to be true to the language. Had to
resist the urge to specify things as "int" rather than "number".

Bertrand: [can't hear]

Ingo: [can't hear]

Bertrand: We have something similar for DOM elements, which are basically
objects... we have a special Boolean for that too.

Ingo: How do you handle the case of a width in CSS, where it could be
anything from pixels to %?

Bertrand: Currently we don't. But we should. We let the code handle it.

Kevin: Ingo, there were some cases too about arrays -- how you would
describe an array or an enumerated list of options. Have you thought a
little bit about that? It goes outside the 'strictly sticking to JS' plan.

Ingo: I think we should allow for a list of valid values supplied by the
developer. It's not in there currently, but it's something we plan to add.

This is, internally, how we describe... [missed]

Kevin: We've talked about whether we could go back and forth between the
XML format and the JavaDoc/JSDoc format to make comments in the code...
Ingo has posted another example that shows that. Can you describe?

Ingo: See
ce. Should look familiar to anyone who knows JavaDoc. 1:1 mapping between
the @things and the tags that exist in XML. Interesting syntax down at
@param... user can put in a list of types, specify that some are optional,
use "..." syntax to specify "1 or more", etc.; not a 1:1 mapping in this

Kevin: Can you describe the other file that handles dependencies and

Ingo: Internally it uses [something] points, but to end user it's just an
XML file. It describes where the dependent files can be found/should be
stored. I can put an example up in a moment; don't have one handy.

Bertrand: Do you have a schema for your XML?

Ingo: Yes. We've been using InfoPath to edit it.

Ingo: We've had pretty good luck documenting the existing libraries out
there using this format, so what we're mostly looking to do is extend this
format based on these discussions.

Bertrand: Sometimes we package the metadata for manage code library along
with the JS library, and we need to differentiate them somehow, and we
can't do that with a fully-qualified name. So we need a unique ID that's
different from the fully-qualified path. It would be helpful to have an ID
attribute for that purpose.

Ingo: Can you send me an example of that?

Bertrand: You can find it in the MS proposal.

Kevin: This has been great. Looking forward to hearing about the Microsoft
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/ide/attachments/20071011/ad202fc5/attachment.html 

More information about the IDE mailing list