IDE Minutes 2008-06-05

From MemberWiki

Jump to: navigation, search




  • Kevin Hakman, Aptana
  • Jon Ferraiolo, IBM
  • Phil Berkland, IBM
  • Rich Thompson, IBM
  • Lori Hylan-Cho, Adobe
  • Bertrand Le Roy, Microsoft


Lori's questions

Starting with Lori's question: There's a note that we approved <availability> and <deprecated> as children of the <property> tag, but these are not described in the Widget metadata. Shouldn't these be attributes rather than tags?

Kevin: Was there a rationale for these being elements?

Jon: No. Perhaps because for Aptana they were elements?

Lori: Any objections to making them attributes?

Jon: No, but I have a follow-on question. Syntax for user-agent: 1.0-2.0 means available in 1.0, but then unavailable in 2.0.

Rich: There's a distinction between deprecated and unavailable.

Deprecated should be a single value indicating the version it was deprecated in.

Jon: <property> is available in both Widget and API metadata, but not all attributes/children apply for both.

Kevin: available and deprecated have more applications in the API metadata.

Jon: I propose available attribute take a range.

No range (single number) means made available in that version, and still available now.

Lori: I think the range should be inclusive.

Rich: Me too -- that's more intuitive.

Jon: So it's [single number]-[single number] (inclusive) or just [single number].

All in favor (indicate with silence). APPROVED with silence.

Jon explains namespacing to Lori. (Thanks! :)

Jon: We should mention in the spec what the expected behavior is for tags, attributes, and values that are unrecognized.

Some discussion of <useragent>, at which point Lori asked where that tag was in the Widget metadata. It wasn't referenced, so we all agreed by vote of silence to include it.

We decide to move the regular meetings to Tuesdays at 1pm PST/4pm EST.

Reviewed the reorganization of the Wiki; we liked it.

Red Item Review

All Widget items for Stu. On to Properties.

Lori asks for a refresher on getterPattern, setterPattern, onchangePattern. [I still don't really get it, will need to see an example in the wiki. All agree that we need to fill in all the "not yet written" bits sooner rather than later.]

Jon: Do these only make sense for APIs?

Phil: I would have thought these were only applicable to widgets.

Rich: I think they make sense for both.

Phil and Bertrand talk about expansion of properties into getter/setter pattern and levels of indirection.

Jon recalls that the pattern on the IDE side has value in that it allows an IDE to recognize that a function *is* a property getter or setter and can do automatic code completion or hinting at editing time. On the widget side, it allows a mashup tool to determine from the metadata what function to call in a gadget wrapper... [sorry, not getting this].

You've got this canvas that owns a set of things. It instantiates a widget wrapper that provides services to the widget that's placed on the canvas. The widget gets to specify a jsClass that the canvas will instantiate and associate with that widget. The setters and getters are on that jsClass.

Bertrand has action item to research <see> element for Tuesday. Jon will try to make sure Stu comes next week.

Personal tools