Re: [Widgets] running widgets in a regular web page ???

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.

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 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.)

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
>