[OpenAjaxGadgets] Minutes 2009-04-20

Rich Thompson richt2 at us.ibm.com
Wed Apr 22 06:44:44 PDT 2009


On Issue #3, a name used by other specs is 'alias'. The key is semantic 
match even if the name differs.

Rich 



From:
Jon Ferraiolo/Menlo Park/IBM at IBMUS
To:
gadgets at openajax.org
Date:
04/21/2009 06:44 PM
Subject:
[OpenAjaxGadgets] Minutes 2009-04-20



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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/gadgets/attachments/20090422/516865fd/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/gadgets/attachments/20090422/516865fd/attachment-0001.gif 


More information about the gadgets mailing list