IDE Minutes 2009 06-23

From MemberWiki

Jump to: navigation, search




  • Lori Hylan-Cho
  • Scott Richards, Adobe
  • Javier Pedemonte, IBM
  • Adam Peller, IBM
  • Jon Ferraiolo, IBM
  • Bertrand Le Roy, Microsoft


(1) Allowed values for 'defaultValue' when datatype="Date"

Jon: Adam has proposed ISO date format. It's what ECMA5 is doing, but you have to include your own date format parser until browsers support it natively

Javier: I don't like the idea of having to include a parser. My vote is to say that you need to support the formats that browsers accept today, and point out that YYYY/MM/DD works. But what about time?

Bertrand: How do you distinguish between UTC time vs local time? Have to know what sort of date you are dealing with.

Adam: Some new browsers do support ISO. Maybe the newest FF and Safari, maybe even IE8. It's part of the ECMA5 spec. There should be code available that people can steal.

Javier: Bertrand points out correctly that you can't distinguish today between different date values.

Adam: Problem might be worse. There is no spec on date values. Some browsers might interpret the value differently depending on current environment. Also, it is usually good to avoid US-centric syntax, such as YYYY/MM/DD.

Javier: Yeah.

Adam: With ISO, you can use GMT or particular time zone. Whatever you want.

Javier: I guess we'll have to go with the ISO format

Jon: Anyone see problems with the ISO date approach?

Adam: Bertrand, does IE8 support it?

Bertrand: I'll have to ask around.

Jon: Any objections to ISO date syntax?


RESOLUTION: defaultValue for dataType='Date' uses ISO syntax. (Need URL of spec to reference)

Bertrand: Doug Crockford has implemented ISO date parsing as an example, so there is code for people to grab. "Open source" license.

(2) @format Attribute - Lotus Mashups built-in types

(Jon steps through the second email below and explains his reasonings)

Jon: For 'html', we will want to include a warning about XSS dangers

Adam: Do we really need currency with a country code? Versus just documenting a convention.

Jon: Or telling people to use two properties.

Jon: My thinking here is that simple things that provide industry interoperability benefit get a thumbs up, but at this late date, anything with complexity gets a thumbs down. The currency stuff will require a little spec of its own to explain, so I say skip it. If Lotus or anyone else needs it, they can do it as an extension.

Adam: Maybe document some best practices or guidelines for currencies outside of the spec?

Jon: We have faced similar issues before and the approach of having a wiki page outside of the spec has been an approach we have used before

Jon: What about table/csv, atom or xml? I said yes, but I'm ambivalent.

Scott: What would you do with these types?

Jon: The only thing I could think is error checking to make sure it's proper CSV or XML.

Jon/Scott: Let's drop those.

Jon: Any disagreement on including email, person, address, etc.? No formal spec for these, but indicates semantics, and there is a fallback of plain old String.

(no disagreement)

Jon: Html?

Scott: Could be really useful

Jon: Yes, but also dangerous

RESOLUTION: Add new @format values from Lotus page per Jon's recommendations, except no table, atom or xml.

(3) How best to document the djConfig.afterOnLoad/dojo.onLoad trick

My best guess about how to document this trick is that we maintain a wiki
page separate from the formal spec, something like OpenAjax Widget
Developer Notes

Jon: There is a special trick for Dojo widgets that I think makes sense to document, but not in the spec. Instead, as separate wiki page. I propose OpenAjax Widget Developer Notes. Spec has link to this page.

Javier: Sounds fine

(no objections)

RESOLUTION: New wiki page OpenAjax Widget Developer Notes, including notes on Dojo afterOnload trick, and is referenced from the spec.

(4) Allow double-colon syntax (foo::bar) for widget categories?

I propose that we adopt the same double-colon syntax for the 'name'
attribute on the <category> element so that tools will be able to establish
hierarchical groups of widgets within widget palettes.

Jon: Seems even more useful for widget categories than properties

Scott: Sounds good to me.

Jon: Any objections?


RESOLUTION: Double colon syntax (::) also for 'name' on <category>

(5) Some Widget API issues

Jon: I wanted to highlight these issues in a phone call to make sure no one sees any problems.

(a) Extensibility

...implementation-specific parameters SHOULD be placed on a sub-object
(e.g., params.ABCOrg.*)

Jon: Same technique as we used with Hub2.0. Any comments or objections?


(b) Exceptions

* Widget callback functions (onLoad, onChange, etc.) SHOULD NOT throw exceptions
* All APIs on the <Widget>.OpenAjax object might throw
OpenAjax.widget.Error.Inactive, which might happen if the widget has been unloaded
* All setters APIs (e.g., setPropertyValue)  on <Widget>.OpenAjax might
throw OpenAjax.widget.Error.BadParameters
* The getMsg() function might throw OpenAjax.widget.Error.NotFound

Jon: Howard had sketched out tentative exceptions on some elements, but I gave it some thought and I think I have a simple, straightforward approach. (See above) One small variation versus Howard is that I thought 'Inactive' was better than 'Disconnected' in case the widget has been unloaded.

Javier: Seems fine to me.

(c) Typo fix

sizeChanged()/modeChanged()/refresh() =>

Jon: Looks like a plain and simple typo, but I wanted to highlight it because I did change the actual APIs that are listed in the chapter, and wanted to make sure no one sees any problems.

Scott: I don't see a problem.

Lori's feedback on spec

Lori: For widget width/height, should say integer.

Jon: OK

Lori: Child content section says MUST for CDATA, but not discussed earlier.

Jon: Want to try to fix the spec?

Lori: I'll try

Lori: Also, you asked people to review 'src' attribute wording on <content> element. It looks fine to me.

Jon: Let's leave the red-colored note. I'll add another note saying you thought it was OK.

Next week

Jon: I'm going over the Properties chapter. There will be one or two issues from that.

Jon: I hope to finish a full reading of the remaining chapters by next week. I should be able to do that. We are getting to the end. Big things left are having others read the spec and creating test cases.

Personal tools