IDE Minutes 2009 06-16

From MemberWiki

Jump to: navigation, search




  • Lori Hylan-Cho
  • Camilia Delbrin, Adobe
  • Javier Pedemonte, IBM
  • Jon Ferraiolo, IBM
  • Bertrand Le Roy, Microsoft


(1) @format

=> format="style" and format="length" accept any value that would be valid
within an HTML doc?
=> Ignore constraint attributes if 'format' is specified?
=> Add format="uri"?
=> Add other format types from Lotus Mashups?

Jon: Kin asks about what happens if you combine @format with constraint attributes, such as 'minimum' and 'maximum'. I propose that if @format is there, then the constraint attributes are ignored. Too many special cases. Let's keep it simple for implementers. What do others think?

Lori: The <title> element could suggest constraints, but not do anything automatically. Ignoring constraints would reduce complexity.

Jon: Any objections?


RESOLUTION: If @format has a value, then ignore constraint attributes.

Jon: Next part of this issue is whether to add @format="uri". I said yes. This is a commonly used construct. But then I discovered that Lotus Mashups has published an extensive list of predefined value formats at the following location: [1]. I think it is best to have a lengthy list of predefined types because that furthers interoperability, which is the OpenAjax mission. Some of the types from Lotus have official specs that define the format. All of the @format fields are optional for tools. They can fallback to the raw JavaScript type as defined by the @datatype attribute.

Lori: Some don't have specs.

Jon: Yes, such as address.

Lori: Even without a spec, this is information that provides a suggestion to the tool about what this value means.

Jon: A standard set of semantically rich types is very valuable in mashup scenarios. It is critical information to allow a mashup tool to link message publishers with message subscribers and to link shared properties.

RESOLUTION: Subsequent phone call to review the list of proposed built-in types one by one

(2) Change sharedAs="propname" to shared="true|false"

(Howard says "Okay.")

Jon: We don't have an alias feature for topics. I'm trying to simplify.

Javier: My only concern is that now people will have to namespace their property names. Better to have an internal property name that's simple but share with a namespaced property

Jon: Which would you prefer?

Javier: shared=true is simpler, but I would lean towards keeping sharedAs. Both have merits.

Jon: Doesn't sound like we feel there is a compelling reason to change, and argument to keep. Any objections to leaving it as is?


RESOLUTION: Leave 'sharedAs' as is.

Jon: I'll make sure Howard is OK with this.

(3) Clarifications on hidden, readonly and designonly attributes

* No runtime enforcement of hidden, readonly and designonly
* hidden="true" - property does not appear in property editor dialogs
* readonly="true" - property appears in property editor dialogs, but cannot
be edited there
* designonly="true" - property is available in "design-time" property
editors, but not run-time property editors. This is meant for configuration
properties where an admin configures a generalized widget, such as setting
the RSS address for a feed widget, whereas perhaps "font-size" might be a
run-time property that an end-user might configure.

Jon: I just wanted to make sure that everyone was on the same page. Does anyone see any problems with the above summary?

(no problems)

(4) <library> and the @target ...

QUESTION #1: Does the @src path for a <library> tag always have to end with
a name of a directory?
Jon: I propose that we add a clarification to the spec that the 'src'
attribute can point to either a directory or a file.

QUESTION #2: Shouldn't the <library> tag allow for the specification of a
@target attribute?
Jon: I propose that we add @target to <library>.

QUESTION #3: Is @target allowed on <require> elements that are children of
a <library> tag??
Jon: I propose that we allow @target on <require> elements that are
children of a <library> tag.

QUESTION #4: If we allow @target on <library>, should we allow @target on
any of its child <require> elements?
Jon: Given my proposals for #1, #2 and #3, then yes.

Jon: I suspect that my answers are what Kin wanted to hear.

Camilia: Your answers were what we wanted. We submitted these questions mostly to clarify.

Jon: Anyone disagree?

Lori: I'm cool with that.

RESOLUTION: @target changes as described above.

(5) Allowable units for 'width' and 'height' on <widget>

* Integer values only, or any CSS length value?

Jon: I think everyone agrees with leaving off absolute unit specifiers, such as en, em and pt. Question about percentages, such as the width should be 50% of the canvas.

Lori: Like HTML tables, where values can be either pixels or percentages.

Jon: Javier, you are implementing this. What do you think?

Javier: Let's keep it simple. I prefer just integers. Haven't seen a use yet for percentages.

Jon: We aren't painting ourselves into a corner. We can add percentages in a subsequent version of the spec.

Lori: I prefer integers only. 80% of content won't use it, but I worry some that percentages will be more popular than we think.

Jon: Any objections to integer only?


RESOLUTION: @width/@height on <widget> must be integers

(6) jsClass and Widget APIs - optional or required?

* What about widgets that only work if the environment supports jsClass and
Widget APIs?
* Perhaps add a new attribute, widgetAPIs="required|optional"?

Jon: As I was proofreading the spec, it struck me that some widgets might use APIs, but IDEs might not support the APIs, and we don't want things to break. How does a tool such as an IDE distinguish between widgets that require API support and widgets that don't?

Lori: Tool has to invoke constructor and onload for this type of widget to work.

Javier: But also what if widget has changed size? Should IDE include logic to manage widget size?

Lori: IDE should only have to be responsible for putting things onto the page out of the XML.

Jon: Question is where we draw the line between standalone widgets and mashable widgets. Maybe 'jsClass' attribute. If you specify that attribute, then you are saying you required Widget API support.

Javier: Yeah. An IDE can look for jsClass, and if in file, then can tell user it cannot support that widget.

Jon: If so, then we don't need my suggestion about a new widgetAPIs attribute because jsClass serves the purpose.

RESOLUTION: if jsClass attribute exists, then the widget requires support for Widget APIs.

(7) getterPattern and setterPattern for widgets?

* Drop getterPattern and setterPattern for widgets?

Jon: As I was proofreading the spec, I saw getterPattern and setterPattern on the <widget> element, and this didn't make sense to me. On the widget side, you don't specify the names of the functions for getters and setters, and instead you manage properties via onChangePropname, getPropertyValue and setPropertyValue. Anyone see how these attributes make sense for widgets?

Lori: I'm trying to picture a requirement. Bertrand was very involved in this. Bertrand, does this apply in widget scenarios or only in API scenarios?

Bertrand: I haven't thought about widget scenarios.

RESOLUTION: Remove getterPattern and setterPattern from widget side until someone finds a scenario for these attributes. Only apply to JS API use of properties.

(8) <enum> for widgets?

* We have <config> and <enum> on the JS APIs side, but only <config> on the
widget side.

Jon: I noticed what looks like an inconsistency. JS APIs support <config> and <enum>, which are both named things that a 'datatype' can refer to. But widget side only supports <config>.

Lori: How would it be used with widgets?

Jon: As a named, reusable set of <options>.

Lori: Seems logical to me. Something we would want to do.

Jon: Javier, you are an implementer.

Javier: I don't know about this one. I didn't code this part of the spec.

Jon: Seems like a small change versus inline <options>.

Lori: My inclination is to add it.

RESOLUTION: Add <enum> to widgets

(9) Specification sections to review

(Jon points out some new sections of spec where color-coded resolutions were converted into spec text and asks if anyone sees any problems)

(10) Nested <properties> elements

Jon: I strongly prefer not nesting <properties> elements. For one, it collides with our existing ability to nest <property> and <properties> elements in order to describe JavaScript object hierarchies.

Lori: I'm for the naming approach rather than the nested properties approach. It does collide with nesting approach we already have. I see you prefer dot syntax versus ::. Any downsides to dot syntax? How about slash?

Javier: I agree with the naming approach.

(everyone assumes Kin proposed :: to prevent potential conflicts where the 'name' attribute might have special characters such as foo/bar or foo:bar or 1.2.)

Jon: Maybe the double-colon approach is reasonable

Lori: I'm OK with it

Jon: Any objections to double colon approach?

RESOLUTION: Add note to spec that talks about the naming convention where :: implies subtabs

(11) Default values for Date type on <property>

Jon: I proposed what it means to have defaultValue="" for all different JavaScript types

Javier: I like the idea of having a complete list of defaults for 'defaultValue' based on JavaScript value types

Jon: Yes. But that makes me wonder. If he have good defaults for all JavaScript types, then why should 'defaultValue' be a required attribute in the schema? In our sample widgets, I'm seeing a lot of defaultValue="".

Javier: Does anyone remember why we decided to make 'defaultValue' required?

Jon: To avoid syntax errors. Force the widget developer to provide a default value that works for the given datatype.

Lori: Also, for factory methods which take an object literal, you would need to know all of the fields in the object literal.

Javier: But if we have a reasonable default for each type, then we don't need to make defaultValue a required attribute

Lori: That sounds right

Lori: In object literal case, there will usually be a default value in the XML

Javier: Already handling. For some, might as well do it for all and make it optional.

Lori: Makes sense.

RESOLUTION: Specify default-defaults for each JavaScript datatype. Make 'defaultValue' optional, not required, in the language schema.

(12) date formats allowed

Jon: I said YYYY/MM/DD, Adam suggested ISO dates, which are in early versions of ECMA5 spec, but not supported yet by browsers.

Bertrand: I was surprised that browsers did not support this.

Adam: Would require a shim today.

Bertrand: Are we talking date or date/time?

Javier: The JavaScript Date type, which means date or date/time.

(out of time. resume discussion on this topic next week)

Personal tools