Just closing off this thread as I am now implementing this feature using widget.openURL()
There is no need for me to override the default wookie behaviour as my specific use case is not running the widget from Wookie but in a custom host application. However, since I'm using the templates from here I wanted to make sure my implementation was consistent with Wookie. Should a widget be deployed using Wookie the existing window.open(url) implementation will be fine. Ross On 7 December 2012 11:47, Scott Wilson <[email protected]>wrote: > > On 7 Dec 2012, at 11:04, Ross Gardler wrote: > > > On 6 December 2012 17:27, Scott Wilson <[email protected] > >wrote: > > > >> On 6 Dec 2012, at 14:05, Ross Gardler wrote: > >> > >>> On 6 December 2012 13:34, Franklin, Matthew B. <[email protected]> > >> wrote: > >>> > >>>>> -----Original Message----- > >>>>> From: Ross Gardler [mailto:[email protected]] > >>>>> Sent: Thursday, December 06, 2012 5:54 AM > >>>>> To: dev > >>>>> Subject: Host Navigation API > >>>>> > >>>>> Does it make sense to implement a feature that provides an API to > >> allow a > >>>>> widget to instruct a host platform to take some navigation action? > Does > >>>>> such an API already exist? > >>>> > >>>> I don't know about in W3C widgets; but this pattern is very common in > >>>> OpenSocial Gadgets. OpenSoical has a whole RPC layer that it uses to > >>>> marshal requests between the widget and its container. In my desire > to > >> see > >>>> OpenSocial gadget functionality align more with W3C, I could > definitely > >>>> envision the case where you would want to start to include this > >> capability > >>>> in W3C widgets. > >>>> > >>> > >>> I should have thought to look at OpenSocial. > >> > >> If we can reuse the OpenSocial APIs - or at least have close functional > >> alignment - that would be useful. > >> > >> > > I've investigated the OpenSocial APIs. My intiial thoughts are documented > > at [1] > > > > Here's a summary (I'd appreciate a full review of the proposal at [1] if > > anyone has the time) > > > > The Action Contributions API can be used and is ideal for the general > use > > case described above. It is optimised for adding actions that a user can > > opt to take in the container (e.g. adding a menu item to the UI so users > > can take an action there). > > > > However, for the specific use case I described (opening a URL in the > > container, without further user intervention) there appears to be a > better > > solution a simpler solution in the (incubating) gadgets.views.openUrl > > method. > > > That used to be in the W3C Widgets Interface API spec, but was removed as > no-one could come up with a use case. Looks like you found one :) > > We've kept it in the wookie-ext feature as widget.openURL(). However all > it does there is call: > > window.open(url); > > ... whereas what you need is for the implementation to notify the parent > of the intent of the widget to open a URL and let it handle things. > > So one approach is to override the implementation of widget.openURL to > post a message to the parent container - the source is in > /features/wookie-ext/wookie.js > > S > > > > > Ross > > > > [1] > https://github.com/OpenDirective/florence_win8/wiki/Host-Navigation-API > > -- Ross Gardler (@rgardler) Programme Leader (Open Development) OpenDirective http://opendirective.com
