Minutes

Greg: Jim Driscoll and I will work on a proposal based on what he have learned with jMaki

Kevin: At F2F, IBM gave a runtime gadget proposal and we are starting a Gadget TF, which will look at things, make recommendations to Steering Committee. Lots of possibilities for outcomes with task forces, such as starting a new WG or adding work to existing WG. Coming from QEDwiki team, which has similar mashup requirements to other products such as MS Popfly. These "gadgets" are at a different level than our "controls". With our controls, it's more abstract such as a pie chart control or a control that can talk to a server. Gadgets are preconfigured to be specific, such as being tied to a particular server with particular customizations for presentation. Thus, gadgets are ready-made components whereas controls are building blocks. But both have APIs and constructors, plus runtime events. The IBM team showcased various gadgets integrating with QEDwiki using the OpenAjax Hub for pub/sub. This new TF is not yet started. Not even a request for participation yet.

Jon: Will happen next week, after the election is over.

Kevin: What about minutes for F2F?

Jon: Will be posted by end of this week.

Kevin: Thanks to everyone for posting proposals. Greg will be posting jMaki-based proposals in next couple of weeks. Let's go through each proposal. People probably haven't looked at all proposals in depth. Let's walk through them. Lori, let's start with you first.

Lori: We need a way to describe widgets. Need arguments for the constructors, what HTML to drop by default, that sort of thing. Using reg expressions as part of constructor logic.

Greg: I see that Nitobi has a nice extension to Dreamweaver.

Lori: That's different. The Spry widgets and some partners implement our extension APIs, which represents manual wiring for widgets. We are looking for a standard file to create extension files automatically. Similar to how Dreamweaver server components leverage @@ to show variable pieces.

Greg: In jMaki, constructors have one value, a property bag, and then we define some standards for properties within the bag.

Lori: We have something similar with our options arguments to our constructor.

Ingo: How important is it to describe JS APIs, not just widgets?

Jon: We want to do both. In fact, recently, more focus on JS APIs.

Lori: We would ignore the JS APIs and only extract out information on the widgets.

Jon: Hopefully our file will support that.

Kevin: We need to address all requirements and as Bertrand says allow for extensibility. Lori, any support to access methods within toolkits? Maybe not since DW doesn't use this.

Lori: Newer version of our file format has separated out author information from the widget because we felt there might be multiple developers who contribute to the widget at different times.

Jon: Under <arguments>, what are id & selector?

(Lori explains, but minute taker didn't get it down)

Greg: We externalize the template. We have config files and then different directory for the snippets. This allows separate versions for different server technologies. But what Lori has is very similar to jMaki.

Jon: What about data typing? Just standard JS types or do you go beyond that?

Lori: Data typing isn't done yet.

Greg: Can any options be arrays?

Kevin: Last option in the sample shows a list.

Jon: Looks like an enum, which is different than an array.

Greg: Our system will have different values for what is displayed versus underlying value.

Jon: Like SELECT element. Required for internationalization.

Jon: Regarding data typing, we will have to decide whether to go formal or not. My instincts are that we will have to go formal.

Ingo: Difficult question about whether to use JS types or extended types.

Jon: Need to consider XML Schema Datatypes. It's one of those XML technologies that we can leverage. Remember, the reason we went with XML was because we could leverage XML things.

Lori: What we are seeing in this example is for Spry, but we need to open it up for other toolkits.

Ingo: Sometimes in JS you allow multiple types for a value. Does this happen with Spry?

Lori: One on the Spry widgets takes an array. Maybe it also takes a string.

Kevin: Example is a CSS width, which has several options.

Kevin: Reg expressions might be useful

Jon: What is subtype? For constrained-value inputs?

Lori: Yes. Also suggestions for ... (units?)

Jon: How about separating the HTML snippet like was done with jMaki. Then no need for CDATA

Lori: Maybe allow either link or inline

Kevin: Other advantage of jMaki approach is allows many templates. Tibco has separate file for multiple prototypes building from same base class.

Jon: Yes. Also internationalization and desktop vs mobile.

Lori: Might want to offer developers a spot for a custom design-time UI for property editing.

Jon: Yes. Standard property editor that probably just lists the properties in top-down fashion, but people could plug in their own gadget to edit the properties.

Ingo: We could write a standard inspector.

Kevin: Could use Hub as a standard non-visual widget.

Jon: Are we talking about an open source reference property dialog or open source reference widgets?

Ingo: eg. take a standard dojo widget as a reference point

Greg: I use dojo clock and a map. Covers a number of cases

Lori: Should use widgets from multiple toolkits

Greg: Almost all widgets have the same basic things, no matter which toolkits. Spry has an unusual approach, as does Prototype.

Ingo: I also like using the Hub. Neutral.

Greg: Maybe use the InteropFest widget? I had some trouble integrating it into jMaki, and decided against it because of nature of InteropFest