From MemberWiki

Contents 1 Attendees 2 Minutes 2.1 Localization 2.2 XHR APIs 2.3 Utility APIs 2.4 Events

Attendees

• Jon Ferraiolo, IBM
• Eduardo Abe, IBM/ILOG
• Stew Nickolas, IBM
• Javier Pedemonte, IBM
• Adam Peller, IBM
• Rich Thompson, IBM
• Howard Weingram, TIBCO

Minutes

(Reviewing /member/wiki/OpenAjax_Mashable_Widgets)

Localization

Stew: We're starting on Localization section

Stew: Objections to model? Method is placed onto the OpenAjax object

Jon: All localization has been done by the time the client sees the pages or call the API, for example, you cannot say "give me the french version"

Stew: Make senses

Jon: Rich you ok

Rich: no objects

XHR APIs

Jon: These APIs are made available on the OpenAjax object on the widget instances

Jon: We should suggest a best practice of invoking getProxyUrl before invoking the url, this give the runtime a chance to place the appropriate proxy onto the URL, can be a null proxy

Stew: What are the signature of callbacks?

Jon: The callback only if sucess happens

Jon: Should look that up.., don't see anything about the call back, research on failure

Stew: We need to create function signatures

Jon: Lets hold off on XHR right now and research, for example we need to know for sure if you make a request and it fails you want to know why

Jon: Propoasl Accepted with open research item on XHR failure

Utility APIs

Stew: Utility APIs as described, any objections?

PROPOASL: Adopted, no objections

Howard: Should we have getByID instead of byId on OpenAjax object? I don't mind either way, the thought is to be consistent

Howard: Also we should define whole interface in JSDoc so its easier to read

Howard: OpenAjax metadata format? do we want a tool to convert to JS doc?

Jon: We should do what we did in Hub for the interface

Events

Stew: We simplified to load and unload, no longer need insert event

Rich: Agree, we found that widgets can determine if its the first time or an insert so we don't need to require the container to implement the lifecycle event

Howard: we can always add later

Stew: For property change event when is the event triggered? before or after the actual property had been changed?

Howard: The event should contain the old and new values in payload

Howard: onChange occure after the value is set

Adam: agree, unless you can reject the property change

Howard: or we could add the ability to check before changing

Jon: The Container is charge of properties

Howard: What happens when you have both the general purpose onChange and a specific property listener? (does order matter when firing the events?)

Howard: Is it arbitrary order of onChange and changePropName

Stew: I propose "Specific to generic" (that is changePropName then onChange)

Jon: "Adam you have to program, how would you order this?"

Adam: (ED: Lost connection to conversation, having phone problems)

Howard: Lets discuss via email

Jon: We've already talked about before

Stew: I propose specific first, generic second

Stew: ... with the same signature OK

Howard: fine

Stew: Moving on to mode change events

Jon: Mode change, we need to include the old mode in the payload Howard: yep,

Stew: Moving on to resize

Jon: For the resize event should we include Old width and new height?

Howard: Should we include subjects in the payload oldSize, newSize that simply have width and height?

Jon: Let stick with the four params, any objections?

NONE, Proposal Accepted

Stew: Moving on the refresh

Jon: We have not discussed this before

Jon: How does a widget become "dirty" and therefore need to refresh?

Rich: Server side components the are triggered from a single event on the client may "dirty" several widgets in a single interactions, therefore the client container may need to redraw several widgets at once

Howard: Can you provide and example?

Rich: In a portal environment, the containers (server and client) may coordinate to create this behavior

Howard: So the server knows that portlet A touchs portlet B

Rich: The client side container sends a single event

Stew: So, no payload then?

Howard, Rich Agree: no payload

Proposal Accepted

Stew: Moving onto last item Extensibility

Extensibility? For example, implementations should use "_" as the first character of any extensions? (This is what we did with the Hub)

Jon: We are proposing container add extensions to the widget that begin with the underscore character "_"

Howard: How about a private or package private mechanism

Jon: if someone wanted to add a function they should use subject, container should use subobjects

Howard: So, we should use the same mechanism as the Hub , _imlementation and private stuff

Jon: Any thing else should be sub object then

Jon: Rich?

Rich: IBM does set of extensions warpped in a IBM namespace object, still has to get reference, this feature should define how to avoid conflicts with future versions

Howard: OpenAjax object, if you want IBM specified function, stick it in as a sub object

Rich: Don't put extension of openajax object but on in another object

Rich: NOT name anything with an _ character

Howard: I'm worried about that approach

Jon: _ for implementation and private things that are having to do with extensions make part of object

Howard: create a how client, attached it to client, want a standaradizatn how that should work, passing params? logging or debugging? how is this done?

Howard: in the code, ok

Jon: So the proposal is:

PROPOSAL: Implementations should use "_" for implementation-specific private objects and data. Extensions should be namespaced onto a JavaScript object whose name is unlikely to conflict with other names.