[
https://issues.apache.org/jira/browse/WOOKIE-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernhard Hoisl updated WOOKIE-133:
----------------------------------
Attachment: shareddata-test2.wgt
shareddata-test.wgt
Hi,
we have to differentiate a little bit. Ross, your former posts indicate that
you *have* to use the template I provide at SourceForge in order to use the
patch and therefore IWC functionality. This is not the case. The widget
template only provides more sophisticated routines for handling IWC data, but
it doesn't matter if you use my patch. Without my patch the template and its
IWC functions still work, but you are not able to, for example, send data from
one widget to a complete different one (e.g. in one user space).
OK, so for testing my patch you can simply use the routines Wookie provides
out-of-the-box, as setSharedDataForKey() etc. I do use them in my template
anyways, but have built some routines around them to ease my (our) life with
handling shared data.
Therefore, when it some to testing: I have created two instances for simple
testing of Wookie's shared data behaviour. I have build them using Wookie's ant
routines including the new style skeleton.
With the widget you can just set new shared data by using an input text field.
Set data is then displayed in the footer of the widget.
If you deploy them on a Wookie instance and have them running side-by-side (I
am doing this by using Elgg) you can test the behaviour of setting shared data
and retrieving updates. I recommend using four widgets side-by-side, twice the
shareddata-test and twice the shareddata-test2.
Scenario 1: Unmodified IWC
If you set a new variable using shareddata-test, the second instance gets
updated, as well, but not the two instances of shareddata-test2. The same
behavior applies for both widget instances of shareddata-test2.
Scenario 2: Patched IWC (with default configuration, that is all widgets of one
user get notified)
If you now set a variable using shareddata-test2, not only the second instance
of shareddata-test2 gets updated, but also both instances of shareddata-test
(vice versa). You can check which widget has set the data as I store the
widget-ID along with the message you typed in.
Hope anybody can test the patch.
Regarding testing the template: I will try to build the same widgets as I
provide here only by using the LTfLL template with, e.g. JSON shared data
format.
-Bernhard
> Implement inter-widget messaging
> --------------------------------
>
> Key: WOOKIE-133
> URL: https://issues.apache.org/jira/browse/WOOKIE-133
> Project: Wookie
> Issue Type: New Feature
> Components: Server, Wookie REST API
> Reporter: Scott Wilson
> Priority: Minor
> Fix For: 0.9.1
>
> Attachments: coupling-widgets-patch.txt, shareddata-test.wgt,
> shareddata-test2.wgt
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> One of the more persistent new feature requests we've had for Wookie has been
> to extend the mechanisms for inter-widget communication (IWC). As it
> currently stands, Wookie supports two mechanisms for IWC:
> 1. Wave Shared States
> Wookie enables "sibling" widgets to share their state. This is exposed to
> widgets using the Google Wave Gadget API, which enables widgets to submit
> state update deltas, and to register a callback to notify them when their
> state has been updated by another widget instance. We define siblings using
> the algorithm in org.apache.wookie.util.SiblingPageNormalizer; essentially
> this is that the widget instance must be for the same widget, with the same
> shared data key, and the same API key.
> 2. HTML5 Drag and Drop
> While not actually part of Wookie itself, Widgets can be developed using
> HTML5 drag and drop capability, enabling user-directed IWC.
> Some use-cases for IWC have been collected on the Talk About Widgets mailing
> list.
> The most common use-cases for extending IWC proposed for Wookie I've seen
> involve "Dashboard"-style messaging. In this model, widgets appearing in the
> same space for the user get to share events. For example, all the widgets in
> a single user's dashboard can send data to each other. This might follow a
> single shared state model, but is more likely to follow a "channel" metaphor,
> with named "channels" or "queues" between widgets. There are several ways
> this could be implemented, for example:
> A. User-specified channels
> In this model, the user specifies exactly which messages are sent between
> widgets. For example, the EzWeb project defines a "wiring" interface with
> "slots" and "events" connected with user-created "channels". For example, the
> user create a channel from a widget with a "weather" event to a widget with a
> "weather" slot.
> B. Widget-specified channels
> In this model, widgets are automatically able to receive any events on any
> channel that they choose to listen to. Users do not need to create channels
> to enable IWC.
> These two mechanisms are not necessarily exclusive, and could be supported
> within the same Feature extension. For example, the JavaScript API may look
> like this:
> iwc.sendEvent(String event_name, Object event_value)
> iwc.registerCallback(String slot_name, Function callback)
> I would prefer having this IWC extension use its own functions in its own
> object rather than overload the Wave and Widget objects, to avoid any
> possible confusion.
> In case "A", callbacks are only triggered where there are explicit channels
> linking the sending event and the receiving slot; in case "B", events are
> propagated to all registered callbacks that the event_name matches.
> For example, in pseudocode, the implementation could look something like:
> sendEvent(event_name, value, idkey){
> instance = find widget instance (idkey)
> if use_channels:
> event = find event(instance.getWidget, event_name)
> find channels (eventinstance = instance & event =
> event_name)
> for channel in channels:
> slot = channel.slot
> send notification to slot (target, slot, value)
>
> Notifier.notifySingleInstance(target,"iwc.__callback({slot},{value})")
> else:
>
> Notifier.notifySiblingsByUser(instance,"iwc.__callback({event_name},{value})")
> }
> Note that in case "A", the widget author just registers callbacks for its
> slots without having to be concerned with what the sending widget calls them,
> so if a user can wire a "weather" event to a "temperature" slot, the sending
> widget calls:
> sendEvent("weather","30C");
> and the receiver can call:
> registerCallback("temperature",my_function);
> ... and the channel wires things up despite the names not matching. In case
> B, the receiving widget would have to know the name of the event, and
> register a callback.
> In case A, widgets need to declare their "events" and "slots" as extensions
> in config.xml so they can be wired up in channels by a user, and there needs
> to be some sort of UI where users get to do some wiring. Wookie could expose
> an API for creating/removing/editing channels that could be implemented by
> containers rather than provide this UI itself.
> (Interestingly, case A would in theory support situations where widgets send
> notifications to widgets in different containers; though I think this would
> only really work if we went did the OpenID implementation so could have some
> assurance that the source and target widget instances belonged to the same
> user).
> [1] http://groups.google.com/group/talk-about-widgets/web/use-cases-for-iwc
> [2] http://forge.morfeo-project.org/wiki/index.php/Gadget_development_guide
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
