IDE Minutes 2009 08 18

From MemberWiki

Jump to: navigation, search




  • Jon Ferraiolo, IBM
  • Lori Hylan-Cho
  • Adam Peller, IBM
  • Javier Pedemonte, IBM
  • Scott Richards, Adobe
  • Kin Blas, Adobe
  • Howard Weingram, TIBCO


Widget APIs chapter

Lori: Got about 2/3 through

Jon: I agree with changing "sub-object" to "object", but what about the bullets that talk about attaching an OpenAjax and OpenAjax.hub sub-object. They are still in the text.

Lori: Yes, leave that.

Howard: Yes

(someone points out that example isn't done)

Jon: I'll fix that

Lori: Why <Widget> instead of Widget

Jon: We talked about this documentation approach previously. The reason for <Widget> instead of Widget is that we don't have a formal interface or class named Widget. If there is a better approach, please speak up.

Howard: Need to add explanation

Lori: I'll do it

Lori: Should change "all other APIs" to "all other methods".

Howard: Make sure that we use either "function" or "method" consistently

(ABCorg extensibility on objects)

Howard: Needs its own section with links to that section

Jon: I'll do it.

(moving to the onRefresh method)

Howard: I'll fix the wording. Idea is that background communications might cause the need to refresh.

Howard: MUST invoke on onRefresh need to be SHOULD invoke. Others OK to say MUST invoke

Howard: I'll review the rest of the chapter

Lori: requestMode vs getMode - sounds the same

Howard: request might not be granted

Lori: I knew that

Howard: I like request

Lori: How about requestModeChange?

Jon: Any objections?


RESOLUTION: change requestMode to requestModeChange

Howard: Should be requestSizeChange also. Instead of adjustDimensions

RESOLUTION: change adjustDimensions to requestSizeChange

Lori: That's as far as I got with that chapter

'copy' and 'target'

Scott: Last week, we proposed getting rid of 'copy'. I thought of a scenario. Our workflow is to refer to a whole toolkit but use only part. In that scenario, we don't want to copy all of everything associated with jquery for example, just what we need. I think we should keep it. But you might want to surface this in a tool as an end-user choice.

Lori: But do you really need the copy attr?

Jon: I'm with Scott

Howard: (also agrees)

RESOLUTION: Restore 'copy' on library

Kin: On require, what if absolute 'src' and you want to deploy locally.

Lori: Decision to never copy when using a CDN.

Kin: That's our implementation today, but what about the future?

Howard: Needed for version 1.0?

Kin: Not imperative for this version.

RESOLUTION: No 'copy' on require for this version

(someone): Need examples in spec

Lori: Could have blogs that show examples

Howard: Better in spec. White paper is also an option.

Kin: Source and target. Make clear that OAM is the base for source file. In DW, we need to preserve a directory structure and replace ../.. with the real directories. What happens if no target?

Scott: Haven't been using the 'target' attribute

Kin: I need to provide examples to show our scenarios

Howard: We need a clear model before sticking in spec

Jon: I agree

Jon: DW not using target?

Kin: Yes, newer widgets are using it. 'target' is important. Need a directory that belongs to a particular widget. Will become clearer when I send an example.

Howard: Need to have a well-defined abstract model

Lori: Processing might be different for different tools

formatting dates

Kin: What I'm looking for is what value is acceptable as a value that is passed into JS. YUI expects western format string. EXT expects ISO date format.

Lori: How the widget receives the data

Kin: How about a general formatting function like what PHP has?

Adam: ECMAScript decided to not do it

Lori: Without this each library would need to change to ISO format

Scott: jQuery supports a number of date formats, including ISO8601

Adam: We could try to accommodate the few that don't support standard date syntax

Lori: If we don't, the widget will receive the wrong data

Howard: Have a declarative approach to say what format is needed is what is important. Requiring a transformation into the format is not required

Lori: We have format=date

Howard: First thing is detecting the format

Lori: Could extend format=date to also allow format=date(...)

Jon: I like the declarative approach better than the procedural approach

TENTATIVE RESOLUTION: Add PHP format strings to format="date(...)"

Kin: Need to look it up

Howard: Put up on email and see what reactions we get.

Personal tools