[OpenAjaxIDE] Minutes 2009-08-18

Jon Ferraiolo jferrai at us.ibm.com
Wed Aug 19 11:08:49 PDT 2009




IDE Minutes 2009 08 18



URL: http://www.openajax.org/member/wiki/IDE_Minutes_2009_08_18


                                 
                                 
                                 




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

Minutes

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?


(none)


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/ide/attachments/20090819/c18c6761/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20090819/c18c6761/attachment.gif 


More information about the IDE mailing list