Gadgets Minutes 2009-04-20

From MemberWiki

Jump to: navigation, search

URL: http://www.openajax.org/member/wiki/Gadgets_Minutes_2009-04-20

Contents

Attendees

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

Original Agenda

Minutes

Issue 1: Rename 'default' to 'defaultvalue'?

Jon: Kin accepted this meeting, so let's wait for him to arrive before talking about this

Issue 2: Request a widget mode

Jon: getMode() resolved in email?

RESOLUTION: Add getMode() API

Jon: What about requestMode()?

Stew: We already have requestDimensions. Up to the container. If honored, you get a modeChanged event.

Howard: Yes, that's good.

RESOLUTION: Add requestMode() API

Jon: Howard already put getMode() and requestMode() into the open source and into the spec

Howard: Why a 3rd step, constructor, onLoad, and then modeChanged?

Jon: Constructor isn't really a step. Simple creation of a JavaScript object.

Jon: What about Rich's note about queued events?

Howard: There could be lots of stuff that happens on bootstrap. I don't want to do queued events. Not with Hub 2.0, which doesn't have such a feature. Could have a lot of complexities. Question: when is a widget ready for rendering? I think forcing an onModeChanged event is a hack. No mode change is going on. Just a trick for a pseudo standardized render step. Widget not yet ready should put up an hourglass if not ready to render. Widget itself may need to make requests before it is ready to render everything.

Stew: Rich, are you on? No. I'll try to represent Rich. Popcorn model. Initial render. You get data and rendering will morph. It sounds like you can queue events before you get data from the server. But I am nervous about all of the moving parts. At load time, getMode() should work. Agree that modeChanged should only happen when a mode changes. In portals, want to batch events before talking to servers.

Howard: I would say that is implementation-specific. Not something to put into the widget spec.

Jon: Maybe a future version of the widget spec could batch APIs

Howard: Not really related to load or modechange

Jon: I agree.

Howard: In the onload call, you can call getMode()

Jon: Sort of hidden. How about passing a param object to the onLoad handler, where we define one parameter right now, which is the initial mode?

Howard: If code supports multiple modes, you need to check anyway. Just as easy to check with getMode() as with param.initialMode

Stew: I was thinking like Howard, but good point that it is hidden

RESOLUTION: No params.mode.

RESOLUTION: Add informative note to spec that if your widget supports multiple modes, you should call getMode() to determine the initial mode

RESOLUTION: If you call getMode() within an onModeChanged callback, you get the new node.

Jon: What about the 'renderBy' property

Howard: Add complexity

Stew: My experience, property editors mostly done by container's UI, but sometimes widgets will have a custom edit mode

Howard: Why not just always honor the widget's edit mode?

Stew: Might be security issues

Jon: Yes, with frame isolation in different domains, but this is more of an implementation complexity issue due to security rather than a security issue. Another question is the UI designer. He might design the mashup app's UI to put property editor dialogs on the right side of the window always and might feel that UI consistency is more important than adding support for the custom editor UI provided by the widget which will show within the widget, which is different than other widgets, so for UI consistency, the edit mode might not be honored.

Stew: Then there is the IDE perspective, where a runtime environment isn't available. In most IDE scenarios, the tool would have to put up its own property editor and ignore the custom edit content.

Jon: Yes

Howard: OK, I'll cave. OK to leave renderedBy.

RESOLUTION: Approve renderedBy property on onModeChanged payload

Issue 3: Remove 'topic' attribute from <property> element

Jon: What we moved to in email discussion is that we might want to offer an exchange name that might be different than the 'name' attribute, which is used locally within the widget

Howard: Yes, but not sure of the best attribute name

Jon: externalName or sharedName?

Howard: Let's put those down for now

Stew: sharedName or shareName?

RESOLUTION: Change 'topic' attribute to 'sharedName' attribute. See if people can think of a better attribute name than 'sharedName'.

Issue 4: Property onChange notification events

Jon: Should widgets see their own changes?

Howard: If not, then system has to put special logic into the HubClient side

Rich: If echoes back, causes complexities to developers

(unminuted long discussion.)

Jon proposes that setPropertyValue() semantics are really requestSetPropertyValue() since container can deny the request, such as due to security policy

Agreement that setPropertyValue() can be an async action, depending on whether widgets are isolated into Iframes and whether server requests might happen during processing

RESOLUTION: Spec needs to say that setPropertyValue() can be async and may be denied

RESOLUTION: Up to widget developers to prevent infinite loop, such as attempt to force a property to a certain value via setPropertyValue() within onchange callback

RESOLUTION: Add 'self' boolean property to onChange payload to indicate whether property change came from same widget

RESOLUTION: onChange is called always, even if setPropertyValue() came from same widget

Retrieved from "http://www.openajax.org/member/wiki/Gadgets_Minutes_2009-04-20"
Personal tools