[OpenAjaxIDE] Minutes 2009-08-18

Howard Weingram weingram at tibco.com
Wed Aug 19 14:15:44 PDT 2009


Minor Correction:

What I said during this discussion:

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

was roughly as follows:

1. There are 2 different features under discussion.

    (a) A standard approach that allows widget to DECLARE the date format
         
    (b) Ability of the framework to TRANSFORM dates from one format to
            another.

The point about requiring vs. not requiring was as follows:

    Item (a) above is a REQUIRED (MUST) element of the spec.

    Item (b) above is an OPTIONAL feature. Some implementators MAY
        elect to support only the one standard format, or few simple
        formats, requiring widgets that don't conform to the
        formats supported by the framework to be wrapped. Other
        implementers MAY choose to support more general transformation.

    Over time, it is hoped that as agreement on a standard format
    crystallizes, (b) will be the exception rather than the rule.
    
Thanks!
hw

On 8/19/09 11:08 AM, "Jon Ferraiolo" <jferrai at us.ibm.com> wrote:

> 
> 
> 
> 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.
> _______________________________________________
> IDE mailing list
> IDE at openajax.org
> http://openajax.org/mailman/listinfo/ide



--
Howard Weingram      650.846.1000
Principal Architect  TIBCO Software Inc.

TIBCO PageBus(TM) delivers ultra-lightweight
publish-subscribe messaging for mash-ups.
Learn more at http://www.pagebus.org



More information about the IDE mailing list