IDE Minutes 2008-05-01

From MemberWiki

Jump to: navigation, search




  • Jon Ferraiolo, IBM
  • Phil Berkland, IBM
  • Stew Nicholas, IBM
  • Lori Hylan-Cho, Adobe


Widget APIs

Lifecycle events

(Stew walks through the recent changes to this section to reflect recent discussions in the Gadgets TF)

  • onload - like page onload, when the whole assembly of widgets has been loaded. no params
  • onunload - when whole assembly goes away
  • onremove - when the given widget is removed from the canvas

Jon: No 'onAdd'? It is common to have this sort of parallelism

Stew: Usually taken care of by onload

Jon: Probably better for widget to be able to distinguish between the two things

(more discussion)

RESOLUTION: Restore onAdd to keep the APIs symmetrical

Stew: Note that the APIs are written up as an Interface, but a widget developer doesn't have to implement this interface or can only implement a subset

  • onModeChange (view vs edit vs help)
  • resize - proposing no parameters such as new width/height. Idea is that you ask your container

Jon: I'm not an expert here, but it looks like it is hard to determine the size of your container. Ajax library authors are asking the browsers for better APIs in the browser for this.

Stew: Yes, each toolkit has its own way of figuring out the size of a container.

Jon: Isn't is different logic for IFRAMEs vs DIVs? Wouldn't the widget author have to include two types of logic for the two common container cases?

Stew: We want to make things easy on the widget writer. So, lets add width/height to the onResize event.

Jon: No redraw event?

Stew: Don't think we need it

Jon: Yeah, browser has screen update logic.

Jon: I wonder if something is missing. (Jon plans to look at Doug Crockford's work around passing data to embedded advertisements)

Property management

(Stew proposes a pattern-based approach for onchange handlers, such as on{propname}Changed().)

(Jon says we should unify the pattern features for getters and setters with the one for onchange, including inheritance feature.)

Stew: OK

RESOLUTION: Unify getter patterns, setter patterns and onchange patterns.

Stew: Is it possible to just specify "helloworld" as the pattern?

Jon: Yes, OK to not have any variables in the pattern.

Stew: Is there a default pattern?

(discussion about how there isn't likely to be a dominant pattern)

RESOLUTION: If a pattern is not specified, defaults to unspecified, which means no callback function is invoked.


(Jon summarizes Marcos's approach that was submitted to W3C)

Jon: Addresses the case where you might have localized non-text assets, such as images

Lori: Adobe avoids this situation

Phil: Yes, but there may be cultural issues that require things other than text to be localized, such as an offensive icon

Jon: What I'm hearing is that we don't have a compelling need at this time to localize any content, but we don't want to paint ourselves into a corner to prevent allows future localization of any content

Phil: Have we resolved the question of XML vs plain text for localization files?

Jon: Not completely. Everyone but Bertrand wanted name=value approach.

Phil: Dojo has a different directory for each language.

Lori: We do replicas like the W3C, but the substitution is done at install time

Phil: Dojo does something like this, also

Jon: How much flexibility do we need to offer? Do we force everyone to use a particular directory structure and naming approach or do we offer flexibility? I expect that we will have to accommodate other directory organization approaches.

Phil: I think we should go with a single approach for the metadata

Jon: OK, let's go with that and see if people tell us we need to be more flexible

RESOLUTION: Initially, we will require a particular directory structure for localization files

Phil: Bertrand may not like this. MS combines into a single file. But localizers usually operate on separate file.

Jon: Yes, maybe MS combines the separate files into a single file.


Jon: Rich has suggested that we might only allow <include> at the highest level

Phil: Probably easier, but I wouldn't have a problem if it were allowed anywhere

Lori: Same

(question about impact on validation)

Jon: Rich's second idea was to use an alternate approach, where you have <properties src=> as an alternative to inline property elements. The referenced file must have <properties> as its root element.

Phil: I prefer <include>

Lori: Me, too. I like the include approach better

Lori: I would prefer is <include> could go anywhere, similar to the model for server-side includes. The result doesn't have to be XML

Jon: This would allow for included values for text nodes

Jon: I'll send email for further discussion

Personal tools