[OpenAjaxIDE] Minutes 2008-09-23

Tue Sep 23 14:52:14 PDT 2008

(I have already updated the spec -- and the Change Log page in the spec --
and the language schema to reflect the decisions from today's phone call)

BTW - Who was the 6th person on the call today?

Jon

URL: http://www.openajax.org/member/wiki/IDE_Minutes_2008_09-23

Attendees
      Lori Hylan-Cho, Aptana
      Phil Berkland, IBM
      Javier Pedemonte, IBM
      Bertrand Le Roy, Microsoft
      Jon Ferraiolo, IBM

Minutes

Passing properties directly to the widget constructor

Lori: I would like to resume old discussion about having an options
argument passed into the widget constructor. Jaxer uses this a lot. It's
how Spry works and it's a common pattern.

Javier: Would we standardize on the options as the first parameter to the
constructor?

Lori: Some widgets already have a constructor. Would be good to use what
already exists.

Jon: What are you thinking?

Lori: Add a new attribute to 'property' element to say that this is a
property that can be passed into constructor. But only pass in properties
where the value doesn't match its default value.

Jon: Some widgets will have the options as the first arg, some the second,
some the third, some won't have it at all, and some will make it into a
subobject to an existing arg. So we would also need a declarative way to
specifying which argument holds the options.

Lori: Yes

Jon: Right now, my feeling is that we have sufficient functionality so long
as the widget author provides a wrapper class. What you are asking for is a
new convenience mechanism to either eliminate the need for a wrapper class
in JavaScript or to minimize the work to provide the widget class in
JavaScript.

Javier: Hard to cover all cases declaratively.

Jon: We wouldn't have to cover all cases. If we do this, we could just
cover the popular cases with a declarative approach. Anything that doesn't
align with the popular cases would require a JavaScript wrapper class,
which we have now.

Lori: Maybe we should bring back the concept of a constructor. As I
remember from Adobe, they don't have a wrapper class.

Lori: Scott was OK with the property string substitution feature that we
have now, where the widget content would have something like this at the
top: {prop1:@@escapequotes(prop1)@@,prop2:@@prop2@@}. But that doesn't
address the case where you want to minimize logic when the values are
different than the defaults.

ACTION: Lori to start email discussion on this topic

OLDER TOPIC: Some hacky code to illustrate how an IDE can support mashable
widgets

Jon: Kin isn't here, so let's wait on this one

Tutorials or primers?
      Scott: http://openajax.org/pipermail/ide/2008q3/000770.html

Jon: Just an FYI that Scott sent in a document. I haven't made any progress
on the primer. Anyone have anything to say about this?

(no comments)

getSupportedViews() and requestNavigateTo()

Jon: We agreed to simplify these APIs last week, but I was given the action
to look into what Gadgets is doing. It turns out that Gadgets is doing
something like the way the spec is now, not the simpler approach that we
talked about last week. Therefore, we need to ask ourselves what's the best
thing to do. But Stew isn't on the call. I suggest that we push this off
into email.

(no objections)

Why isn't <useragent> camel-cased?
      Bertrand: http://openajax.org/pipermail/ide/2008q3/000771.html
      Jon: http://openajax.org/pipermail/ide/2008q3/000772.html
      Bertrand: http://openajax.org/pipermail/ide/2008q3/000773.html

-- votes for self-consistency
      Rich: http://openajax.org/pipermail/ide/2008q3/000774.html

-- agrees
      Lori: http://openajax.org/pipermail/ide/2008q3/000775.html

-- No skin off Aptana's nose if it changes

RESOLUTION: Change to camel case

Handling 'default' values for properties
      Jon: http://openajax.org/pipermail/ide/2008q3/000777.html

-- Jon forwards Javier's proposal for JSON encoding rules for different
types of attributes
      Jon: http://openajax.org/pipermail/ide/2008q3/000778.html

-- Jon says Javier's proposals are reasonable

(no objections to Javier's general approach)

Jon/Javier: rules would be something like "string value of the 'default'
attribute must be parseable by the constructor for the given datatype"

ACTION: Jon to propose exact words and analyze the various datatypes to
make sure the spec is clear about all cases

Change log

Phil: One of the Eclipse developers has requested a history that shows the
changes to the spec

Jon: I did that faithfully for the Hub 1.0 spec, but haven't done anything
with this spec yet. I'll start listing changes to the Change Log appendix

Phil: Just need to list the attributes and elements that have changed.
People can look at the history tabs to get the details.

Next phone call

Jon: Agenda is getting slimmer each week and next week is Ajax Experience,
where my session happens in the hour before this phone call. How about if
we skip next week and have our next phone call in 2 weeks?

(no objections)

RESOLUTION: Next phone call in 2 weeks (Oct 7)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/ide/attachments/20080923/1f73de54/attachment-0001.html 