IDE Minutes 2009 08 18
- 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.
(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
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.