IDE Minutes 2008 09-23

From MemberWiki

Jump to: navigation, search

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

Contents

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?

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?

-- votes for self-consistency

-- agrees

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

RESOLUTION: Change to camel case

Handling 'default' values for properties

-- Jon forwards Javier's proposal for JSON encoding rules for different types of attributes

-- 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)

Retrieved from "http://www.openajax.org/member/wiki/IDE_Minutes_2008_09-23"
Personal tools