IDE Minutes 2008 11-18

From MemberWiki

Jump to: navigation, search




  • Jon Ferraiolo, IBM
  • Rich Thompson, IBM
  • Nitin Dahyabhai, IBM
  • Lori Hylan-Cho, Aptana
  • Javier Pedemonte, IBM
  • Bertrand Le Roy, Microsoft


Topic: Some advanced Dojo cases


Jon: I believe we should address the two use cases that Dojo has that we aren't supporting yet.

Bertrand: Singleton case is really common

Jon: How about the single property mixin case?

Bertrand: Not very common. Can accomplish by making a mixin out of a property.

Jon: I'm in favor of addressing the mixin case because if you have a foo class and a bar class, the foo developer cannot know what the bar class wants to mixin one of its properties.

Bertrand: Yes, sure.

Rich: If trying to accomplish finer-grain control, is there a more general mechanism?


Jon/Rich: One at a time is likely to be more straightforward.

Rich: I can buy this.

Jon: One proposal is 'fromProperty' and 'toProperty' attributes, where 'toProperty' defaults to 'fromProperty'. How does this sound?

(no objections)

RESOLUTION: Add 'fromProperty' and 'toProperty' attributes to <mix>

(discussion of singleton classes)

Jon: Three options come to mind:

  • (a) <object> element as a sibling to <class>
  • (b) add static="true|false" to <class>
  • (c) <staticClass> element as a sibling to <class>

Lori: ScriptDoc has (b)

Rich: I prefer (b) since static class uses all of the same things as an instantiated class

RESOLUTION: Add 'static' attribute to <class>

ACTION: Jon to send email to Tom Trenka

Topic: Spec and schema changes for <config>


Jon: If anyone see anything wrong with the changes I made, please speak up.

(no comments)

Topic: Please review new spec sections on <handlerFunction>


Jon: Is the proposed write-up OK?

Rich: Does it need to be a pattern?

Bertrand: Yes, you want to say it once and apply it to random properties

Jon: It's an inherited property, like our getters and setters.

Bertrand: Also need a pattern for unregister

Jon: OK, I will add that

Jon: OK that Template:Callback is a function?

Bertrand: That's fine

Rich: Need to say crisply that function parameters are required and that define the signature of the callback.

RESOLUTION: Add 'unregisterCallbackPattern' attribute

Topic: Cleanups to the write-up on 'datatype'


I can see datatype="[Object]|String" being useful: the method here could
take a comma-separated list that it knows how to parse to an array.

Bertrand: My email about comma-separated lists is that sometimes a function might take an Array or a String. If Array, then it is a true JavaScript array. If String, then a comma-separate list that gets converted into an array.

RESOLUTION: We will support "[Object]|String"

Personal tools