IDE Minutes 2008 08 05
- Bertrand Le-Roy (Microsoft)
- Lori Hylan-Cho (Adobe)
- Jon Ferraiolo (IBM)
- Kin Blas (Adobe)
- Stew Nikolas (IBM)
- Wayne Vicknair (IBM)
- Phil Thibideau (OpenLink)
- Ted Berkland (IBM)
- Javier Pedemonte (IBM)
- Rich Thompson (IBM)
Topic: Email The default for returns is void
Jon: Kin points out that there is no void type in ECMA/JS, why not use undefined instead of void
Jon: Proposal is that we change the data type section to say instead of a void type we have an undefined type.
Jon: Void is in the spec but it is a unary operator not a data type.
Bertrand: Personally I would prefer void. Disambiguates from purposely returning undefined. Firefox generates a warning if you return an undefined versus returning nothing.
Kin: Was merely trying to suggest a term that was familiar to folks with
Jon: Ok, default for return should be void. Should we have an Undefined type?
Wayne: It's just an internal type in the language. Not something to express things in a program.
Topic: Macro substitution on the <require> tag.
Jon: Lori and I think there should not be substitution on that
Jon: Talked to Javier and it would be difficult to do the substitution on a JS file.
Jon: Could be messy. Should have the same processing model for inline and external.
Lori: Then we need to answer
Jon: Scenario one, developer using a widget developed by someone else.
Jon: Then you have the end-user mashup scenario.
Jon: Developer shouldn't be changing the widget meta-data file.
Kin: Some developers code their widget js so that users can override defaults
Jon: Outside the scope of what we're defining in the widget meta data file?
Kin: But the developer who defined the meta data file is explicitly stating they want the users to be able to override the defaults by exposing these as properties.
Jon: Yes we have a property model.
Lori: Kin is saying that this block should go before any require files. You still need substitution in that case.
Lori: Our only model for getting JS code in the head is <require>. So all we're saying is that macro substitution needs to happen on blocks of code we insert into the head.
Lori: She agrees that there is no substitution necessary for external <require> files.
Jon: We need some text to state that substitution happens on inline <require> code.
Jon: We will substitute properties, localization, and gadget __GID__ substitutions.
Jon: In the IDE case, there's a batch generation of an HTML file. That HTML gets loaded in a browser.
Jon: Wayne is saying In the mashup scenario, the properties aren't known at the time the widget is first loaded. You can't do the substitution until later in the process after the markup has been inserted.
Wayne: The preload blocks are slammed in the head and we can't guarantee that widgets have all been loaded.
Jon: There needs to be JS that is inserted in the head that has the transformations applied to it. The natural place is an inline <require>. We need to get together and re-visit the gadget model where its a little more complicated. Can we take this to email to discuss it over the next few days?
Topic: Event element
Jon: Aptana doesn't have it, JavaDocs had it, but it was taken out. Bertrand says they'll use it.
Jon: I guess we keep it then. I just want to make sure it has the right sub elements and things.
Bertrand: I think this is useful if you have the patterns for events.
Jon: It has the patterns in there too.
Bertrand: You have functions that take a handler ...??
Jon: Do we need a returns element?
Bertrand: Maybe, a framework can return a transport handler ... that's forseeable for training purposes. So I'd keep it there.
Jon: Anybody have comments on event?
Bertrand: Another scenario is that you can return a token like the hub?
Bertrand: Is used to describe DOM events?
Jon: SPec defines events that are used in internally in the system.
Topic: Which attributes should be required by the schema
Jon: Kin sent an email on why the name attribute on <property> is optional. Then I went through the entire language to see what attributes should be required.
'name' attribute: --------------------- <alias name=> <category name=> <class name=> <enum name=> <field name=> <interface name=> <method name=> <mixin name=> <namespace name=> <parameter name=> <property name=> <topic name=> 'datatype' attribute: --------------------- <ancestor datatype=> <mix datatype=> 'type' attribute: --------------------- <require type=> 'src' attribute: --------------------- <icon src=> <include src=> 'value' attribute: --------------------- <option value=>
Jon: I may have overlooked something else.
Lori: what about default on <property>
Jon: We say that the default is whatever JS defines for string, number, boolean, etc.
Wayne: It's unset or undefined?
Lori: It seems like you need a default.
Jon: We need to say what the defaults are for each property? Or for each type?
Lori: The former.
Jon: It's ok for strings to be empty.
Lori: Suppose you have to do a substitution and a property has no default. What do you put there?
Wayne: You leave the double @@prop@@ sign in.
Jon: that should happen when there is no property or no default.
Lori: I think that's what we're doing. Implementation guys wanted to make sure that was correct.
Wayne: If it is in script you'll get a syntax error if you leave @@ in there. It won't do type coersion if its a string.
Wayne: In the case of undefined values, you get NaN for number so that won't work.
Jon: Lori your assuming there will be 3rd party widgets built on top of toolkits. It would be better if we made default required so that when the validated during author time ...
Wayne: If you default data type is string then the default behavior is to return the string "undefined".
Lori: What if the person has specified a data type of integer or array, and they don't supply.
Wayne: if they specify a data type then force them to use a default.
Lori: Situation i'm worried about is the case where the IDE doesn't handle the property element, doesn't display a way to enter the values, then we're inserting broken code.
Jon: 1. Tough luck 2. Make default required. or 3. For string we may not need a default value.
Lori: but we'd need to define what the defaults are.
Wayne: Default of Number is NaN
Wayne: You need to look at chapter 9 for type conversion. There are all these behviors that are outlined in the spec but they don't necessarily work for us.
Wayne: We don't know if we're in a JS context, we could be doing substitution in markup.
Wayne: I like Jon's approach of tough luck
Lori: that won't work for DW users. The whole point is to make it easier for people not writing this code to be able to get something that works. That's the whole reason for having property sheets etc. Some of them are going to look at @@ and think that is JS.
Wayne: Yeah this is thorny.
Jon: Look at option 2 or 3. And hope that widget developers validate their widgets. 3rd option attempt to come up with defaults that don't break things.
Jon: But we can't tell if its being applied to JS or HTML Markup.
Lori: I think this is a case for requiring .. the code may break if you don't supply one. We should notate this in the spec.
Wayne: If we guess, we're going to guess wrong.
Jon: Will remove the question mark from the spec.
Jon: Keep an eye on the spec and mention if we missed anything.
Wayne: I agree what you currently have on the list.
Jon: need better checking the validator to make sure values are correct.
Topic: How to get a handle to the OAA Hub
Jon: We haven't decided how a widget can get a handle to the OAA hub so it can publish/subscribe.
Jon: Need to run this past the gadgets task force.
Jon: Javier propsed that the widget wrapper has register/unregister callbacks ... getHubConnectionHandle().
Jon: My email shows a snippet. Make sure I'm not missing something.
Stew: Seems reasonable.
Jon: Do you want me to add this?
Stew: You can add it.