In this particular case, I'm not in love with "alias". The semantics in
this case isn't an alternative to the 'name' attribute, but instead more of
the alternative "sharing name" or "public name" for when a single property
is shared among multiple widgets.
Jon
Rich
Thompson/Watson/I
BM at IBMUS To
Sent by: gadgets at openajax.org
gadgets-bounces at o cc
penajax.org
Subject
Re: [OpenAjaxGadgets] Minutes
04/22/2009 06:44 2009-04-20
AM
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
_______________________________________________
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/2c0d8fc9/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://openajax.org/pipermail/gadgets/attachments/20090422/2c0d8fc9/attachment-0003.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic01518.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://openajax.org/pipermail/gadgets/attachments/20090422/2c0d8fc9/attachment-0004.gif
-------------- 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/20090422/2c0d8fc9/attachment-0005.gif