[Embedding] running widgets in a regular web page ???

(NB changed subject prefix to "[Embedding]" as per Art's suggestion)

On 26 Nov 2010, at 18:37, Peter Dekkers wrote:

> First of all, thanks to everyone replying and providing useful background to this first time poster. I did go through the provided links of the past threads and the different kind of proposed approaches. I think however I might have not made myself completely clear (or of course I misunderstood some of the replies :). 
> 
> I think it would be great if the SAME code base could run "standalone" and in a web page (that is with the help of a "serverside container" like Wookie or JBaron). Injected scripts can help with some issues, I also use this on the JBaron demo. But certainly this is not going to solve all issues.
> 
> For example to be truly compatible in both environment this would mean that widget code should invoke widget.getProxyUrl/proxify before calling an XMLHttpRequest, because the code base doesn't know on which environment it will be run. And the consequence would be of course that this method would need to be part of the specification.

I think the main question is where we have to solve this. When I raised this previously, there was a general feeling that the cross-origin XHR cases ought to be handled by CORS and XHR2 not by Widgets, which I think is sensible when looking at the longer-term spec roadmap. 

However, we do have an issue of making things work until browsers implement these.

The route we've taken is server-side proxies and to make use of WARP to automatically add policies to the proxy whitelist. We then need a means to proxify requests. 

One approach is an explicit proxify() method. Other possibilities may be to provide a special XHR object such as a modified JQuery. None of these is 100% satisfactory - as you point out, you get the issue of proxify() being non-standard and so widgets need tweaking for other environments.

I think the next thing we might explore is using WARP as a way to identify URL patterns that are dynamically rewritten by the container. So if WARP contains "twetter.com" then we rewrite any URLs in the Widget's JS code containing "twetter.com" with a proxy URL.

Again, not 100% guaranteed either. But maybe better than proxify() as the Widget code will be the same for web and non-web containers, we may just have to tweak them a little for web containers in some cases.

> And my interest/question was, is this planned/foreseen? Will it be possible at the end to run the same "specification compliant widget" both "standalone" as also part of a web page (again with using something like using Wookie or JBaron)??? In the second scenario of course it won't necessary be the end-user who installed the application.It would be more likely the site owner who included the application on one of his pages.

I think it certainly should be - this is how a lot of our commercial partners want to use them, for example: have a single Widget developed and tested that can be run in their portal/intranet/extranet via Wookie AND be downloaded to run on a smartphone.

> (I guess an alternative would be to make these additional methods part of a feature and mention this in the config.xml. But then regular widgets won't run within web pages.)

In some ways this is more in the spirit of the spec than what we are doing now, but it also does defeat the purpose of "one widget any platform" as you say. 

> And again, thanks for all the feedback and ideas so far. 
> 
> 
> regards,
> 
> Peter
>  
> 
> On Fri, Nov 26, 2010 at 6:19 PM, Marcos Caceres <marcosc@opera.com> wrote:
> On Fri, Nov 26, 2010 at 1:10 PM, Nathan <nathan@webr3.org> wrote:
> > Peter Dekkers wrote:
> >>
> >> I've been developing a platform for running multiple types of widgets in
> >> regular web pages and of course support for the W3C widgets should not be
> >> missing. A very nice specification. I especially like the fact that the
> >> "deployment unit" contains all the files and the spec itself tries to be
> >> as
> >> clear and precise as possible.
> >>
> >> However the specification seems to be geared towards "standalone desktop
> >> applications", and not so much running the widgets as part of a regular
> >> web
> >> page. When I investigated a little more, there doesn't seem however too
> >> much
> >> stopping the widget running in an ordinary web page. Two of the main
> >> functions missing that I could identify so far are:
> >>
> >> - A widget.onReady() function that gives the page the change to prepare
> >> everything before the widget dependent code is executed.
> >> - Some way to proxy XMLHttpRequest in order to avoid not same origin
> >> security validations. A simple way would be a widget function that simply
> >> rewrites the URL to a proxied URL.
> >>
> >> Personally I think it would be great to have the W3C widgets run both
> >> inside
> >> a normal webpage and as a standalone application. However is this also
> >> something that might be considered by the people in charge of the
> >> specifications, or is this something that will never be in scope? Any
> >> enlightenment would be great.
> >>
> >> P.S For those interested, on http://www.jbaron.com:9090/w3c there are some
> >> Opera widgets running in a web page as a small proof of concept (certainly
> >> not a complete implementation). The same site also has some pages with
> >> other
> >> types of widgets.
> >
> > :) and so it begins, +1 from me Peter, have been wanting Widgets in the main
> > browser context for a long time - seems like an already standardized no
> > brainer to me.
> >
> > You're not the first to ask, and 'm sure you won't be the last.
> >
> > Best & ty for raising this,
> 
> 
> Have you guys checked out Opera extensions (built on W3C Widgets)? It
> gives you an alternative way to think about the problem:
> 
> 1. The widget can continue to run happily in a self contained environment.
> 2. Hooks are provided that allow communication with a web document
> (via injected scripts).
> 
> But sure, embedding zip packages into web pages would also be
> interesting and project's like Apache Wookie have done it
> successfully. Natively supporting such a thing, however, has had
> limited interest.
> 
> --
> Marcos Caceres
> Opera Software ASA, http://www.opera.com/
> http://datadriven.com.au
>