[OpenAjaxGadgets] Minutes 2009-04-20

Tue Apr 21 15:09:04 PDT 2009

Gadgets Minutes 2009-04-20

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

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

Original Agenda
      Issue 1: Rename 'default' to 'defaultvalue'?
            Howard:
            http://openajax.org/pipermail/gadgets/2009-April/000205.html
            Jon:
            http://openajax.org/pipermail/gadgets/2009-April/000207.html
      Issue 2: Request a widget mode
            Howard asks about having a getMode() API
            Question is how does a widget know what mode it is in when
            first rendered. Should onModeChanged event be sent right after
            onLoad?
            What is order of events: widget loaded and ready to be
            initialized (onLoad?), queued events, widget ready for
            rendering (onModeChanged?)
            What about 'renderedBy'?
            New API requestMode()?
            On first onModeChanged, what is value for oldMode?
            Howard:
            http://openajax.org/pipermail/gadgets/2009-April/000190.html
            Howard:
            http://openajax.org/pipermail/gadgets/2009-April/000193.html
            Jon:
            http://openajax.org/pipermail/gadgets/2009-April/000199.html
            Howard:
            http://openajax.org/pipermail/gadgets/2009-April/000200.html
            Rich:
            http://openajax.org/pipermail/gadgets/2009-April/000208.html
            Howard:
            http://openajax.org/pipermail/gadgets/2009-April/000210.html
            Jon:
            http://openajax.org/pipermail/gadgets/2009-April/000211.html
            Howard:
            http://openajax.org/pipermail/gadgets/2009-April/000215.html
            Rich:
            http://openajax.org/pipermail/gadgets/2009-April/000218.html
            Jon:
            http://openajax.org/pipermail/gadgets/2009-April/000219.html
            Rich:
            http://openajax.org/pipermail/gadgets/2009-April/000220.html
            Howard:
            http://openajax.org/pipermail/gadgets/2009-April/000222.html
      Issue 3: Remove 'topic' attribute from <property> element
            Howard:
            http://openajax.org/pipermail/gadgets/2009-April/000206.html
            Jon:
            http://openajax.org/pipermail/gadgets/2009-April/000212.html
            Howard:
            http://openajax.org/pipermail/gadgets/2009-April/000216.html
            Rich:
            http://openajax.org/pipermail/gadgets/2009-April/000221.html
            Howard:
            http://openajax.org/pipermail/gadgets/2009-April/000217.html
      Issue 4: Property onChange notification events
            Widget see its own property changes? Proposal: no
            Dependencies between Widget and Hub specs? Proposal: property
            system not dependent on Hub, but event system requires support
            for Hub APIs. "The hub sub-object MUST implement the HubClient
            interface and semantics defined in the OpenAjax 2.0
            specification."
            Namespacing events? Proposal is refer to Hub spec best
            practices
            Howard:
            http://openajax.org/pipermail/gadgets/2009-April/000165.html
            Rich:
            http://openajax.org/pipermail/gadgets/2009-April/000166.html
            Jon:
            http://openajax.org/pipermail/gadgets/2009-April/000169.html
            Howard:
            http://openajax.org/pipermail/gadgets/2009-April/000170.html
            Javier:
            http://openajax.org/pipermail/gadgets/2009-April/000167.html
            Jon:
            http://openajax.org/pipermail/gadgets/2009-April/000168.html
            Rich:
            http://openajax.org/pipermail/gadgets/2009-April/000171.html
            Jon:
            http://openajax.org/pipermail/gadgets/2009-April/000172.html
            Howard:
            http://openajax.org/pipermail/gadgets/2009-April/000174.html
            Javier:
            http://openajax.org/pipermail/gadgets/2009-April/000179.html
            Rich:
            http://openajax.org/pipermail/gadgets/2009-April/000173.html
            Jon:
            http://openajax.org/pipermail/gadgets/2009-April/000181.html
            Howard:
            http://openajax.org/pipermail/gadgets/2009-April/000182.html
            Jon:
            http://openajax.org/pipermail/gadgets/2009-April/000183.html
      Issue 5: questions about "topic" sub-elements
            Need to clean up schema and spec relative to PARAMETER,
            RETURNTYPE and PROPERTY children of TOPIC
            RESOLVED IN EMAIL?
            Howard:
            http://openajax.org/pipermail/gadgets/2009-April/000175.html
            Jon:
            http://openajax.org/pipermail/gadgets/2009-April/000186.html
            Howard:
            http://openajax.org/pipermail/gadgets/2009-April/000187.html
      Issue 6: type checking inbound messages & data being stored
            RESOLVED IN EMAIL?
            Responsibility of widget to verify correctness of incoming
            messages
            Howard:
            http://openajax.org/pipermail/gadgets/2009-April/000176.html
            Rich:
            http://openajax.org/pipermail/gadgets/2009-April/000177.html
            Jon:
            http://openajax.org/pipermail/gadgets/2009-April/000178.html
            Howard:
            http://openajax.org/pipermail/gadgets/2009-April/000185.html
      Issue 7: widget onUnload vs onShutdown
            unload and shutdown the same thing?
            Howard:
            http://openajax.org/pipermail/gadgets/2009-April/000191.html
            Jon:
            http://openajax.org/pipermail/gadgets/2009-April/000197.html
      Issue 8: sizeChanged event questions
            RESOLVED IN EMAIL? (inner boundaries)
            Howard:
            http://openajax.org/pipermail/gadgets/2009-April/000192.html
            Jon:
            http://openajax.org/pipermail/gadgets/2009-April/000198.html
      Issue 9: Does JAVASCRIPT need a mode attribute?
            Howard:
            http://openajax.org/pipermail/gadgets/2009-April/000194.html
            Jon:
            http://openajax.org/pipermail/gadgets/2009-April/000203.html

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/gadgets/attachments/20090421/c93294b4/attachment-0001.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/gadgets/attachments/20090421/c93294b4/attachment-0001.gif 