IDE Minutes 2008 10-28

From MemberWiki

Jump to: navigation, search




  • Lori Hylan-Cho, Aptana
  • Kin Blas, Adobe
  • Jon Ferriaolo, IBM
  • Phil Berkland, IBM
  • Stew Nickolas, IBM
  • Rich Thompson, IBM
  • Javier Pedemonte, IBM


Mashable widgets: Splitting out into separate specification

Stew: The benefit was always to have a single markup for both types of widgets. I think from a Google perspective there are some things we need to address… something about Caha, you need to write for Caha. Unless we solve the Caha or inlining problem [Lori: What is Caha?] It's an interpreter that lets you take untrusted Javascript… [and bring it with you?] They dropped inlining from Google Gadgets, but you need inlining for speed reasons.

We'll end up with an OAA metadata and a Google metadata. We'll need some tools for moving back and forth.

Jon: We're splitting off temporarily, but we intended to bring it back in for maybe a 1.1 version.

Kin: What does inline mean?

Stew: e.g., when I insert a widget…

Kin: When you insert a gadget, it *is* actually inserting a table into the page. The code is inline.

Stew: It's actually in an iFrame or a Caha.

Kin: I didn't see an iFrame when I was playing around with Gadgets last week.

Jon: The main reason for splitting it off into a separate spec is so that we don't slow down the IDE parts. Anyone have any comments about splitting off and then figuring out how to bring it back in? Unless someone speaks up, I'll start making changes to the spec to reflect that.

Passing object literals to constructors and methods

Jon proposed adding a <config> element; Lori concurred.

Jon asserted that <config> properties would not be part of any property dialog; Lori disagreed. Kin wanted to know whether individual config properties could be accessed with @@configPropname@@.

Proposal #1: We have a <config> element, and that we also add a config attribute to the property element.

Proposal #2: We have <config> element and property attribute on the <config> element that references a property. (? I'm not sure I get this; Jon will send out e-mail.)

YUI OAM Issues

Jon created a YUI JSON -> OAA metadata converter, and Lori created a YUI JSON -> ScriptDoc XML converter, and both ran into issues, documented at

Re: <event>, we need Bertrand for that.

Do we really need <field>? Could we just assume that the absence of getterPattern and setterPattern mean that the property can be set by direct assignment? [Probably.]

Jon noticed that HTMLElement was listed as a datatype; OAA metadata does not allow for this, so he converted to Object. Lori opined that we should provide more info, not less, and let the IDEs devolve to String (our default datatype) if necessary. Jon reworded this (speaking as an IDE) as "if this is a datatype defined in the OAA spec, do what the spec says; else, if this is a datatype I recognize, do what I know to do; else, assume it's String."

Personal tools