[OpenAjaxGadgets] Minutes 2009-04-20
Rich Thompson
richt2 at us.ibm.com
Mon Apr 27 05:55:23 PDT 2009
I would disagree that the widget developer is limiting the application
developer who is putting a page together. Rather this gives a means of
providing semantic information that the associated properties CAN be
linked (i.e. there is a semantic match). Whether or not other properties,
potentially from unknown widgets, are also a semantic match (and thereby
candidates for sharing) is not specified.
That said, "sharedAs" does sound like a reasonable name ...
Rich
From:
Jon Ferraiolo/Menlo Park/IBM
To:
Howard Weingram <weingram at tibco.com>
Cc:
gadgets at openajax.org, Rich Thompson/Watson/IBM at IBMUS
Date:
04/22/2009 02:47 PM
Subject:
Re: [OpenAjaxGadgets] Minutes 2009-04-20
At the phone call, we talked about "sharedName". Among all of the options
listed so far, I like "sharedAs" the best.
Jon
Howard Weingram <weingram at tibco.com>
04/22/2009 10:31 AM
To
Jon Ferraiolo/Menlo Park/IBM at IBMUS, Rich Thompson/Watson/IBM at IBMUS
cc
<gadgets at openajax.org>
Subject
Re: [OpenAjaxGadgets] Minutes 2009-04-20
I agree with Jon.
The name we're talking about uniquely names an association between
properties exposed by different widgets (without requiring specifying
implementation details or hub topics). The widget developer is giving an
instruction that this property should ONLY be linked with widget
properties
that share this association.
That's not at all the same thing as an alias.
sharedProp
sharingName
sharedAs
linkName
are some possibilities.
Regards,
Howard
On 4/22/09 8:36 AM, "Jon Ferraiolo" <jferrai at us.ibm.com> wrote:
>
> 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
>
>
>
> _______________________________________________
> gadgets mailing list
> gadgets at openajax.org
> http://openajax.org/mailman/listinfo/gadgets
--
Howard Weingram 650.846.1000
Principal Architect TIBCO Software Inc.
TIBCO PageBus(TM) delivers ultra-lightweight
publish-subscribe messaging for mash-ups.
Learn more at http://www.pagebus.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/gadgets/attachments/20090427/d2b4d0ee/attachment-0001.html
More information about the gadgets
mailing list