[OpenAjaxIDE] Minutes today's IDE phone call 2007-10-04
jferrai at us.ibm.com
Thu Oct 4 11:12:26 PDT 2007
IDE Minutes 2007-10-04
Attendees this week
Lori Hylan-Cho <lorihc(at)adobe.com>
Ingo Muschenetz <ingo(at)aptana.com>
Kevin Hakman <khakman(at)tibco.com>
Ted Thibodeau <tthibodeau(at)openlinksw.com>
Greg Murray <greg.murray(at)sun.com>
Jon Ferraiolo <jferrai(at)us.ibm.com>
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
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
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
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
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
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
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
Kevin: Next week let's go through Aptana
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the IDE