Re: Widgets 1.0

> Since the specification only specifies the move and resize methods of
> the window object, what you are saying is that if embedded in a
> webpage we would just have to accept that these widgets are not
> allowed to move or resize themselves?  This seems a bit odd.  If the
> widget rendering system (ie, the parent webpage) could be alerted to
> the widget's wanting to be moved/resized, some systems would do it for
> them, some would not, but it would be nice to have the option.  I
> understand the logic here, but it does limit implementation a bit
> (which would likely end up being supplemented by an 'extended' but
> non-standard Javascript library).

I'll look into this. But I still don't think its much of a problem....
Flash has a function called "fscommand" which allows you to talk to
JavaScript in the browser. So, in theory, a flash movie can do this:

inside flash:
fscommand("growMe", ({width:100,height:100}));

inside HTML script:
function growMe(dimension){
  $("flashmovie").style.width += dimension.width;
  $("flashmovie").style.height += dimension.height;
}

Worst case, we can define something similar to 'fscommand' for
widgets. However, I don't feel strongly about this ATM.

> >The bigger problem, if you're looking to embed these widgets in web pages
> >is the security model of widgets, that allow for cross-domain
> >XMLHttpRequest.
>
> This is indeed a problem.  It can, again, be overcome if widget
> designers wishing their widget to work on and offline were to use some
> other method (such as an optional proxy URL, ala Netvibes), but it
> would be nice if this were somehow supported in the actual
> specification.  Perhaps some sort of note could be made that there
> SHOULD (if rendering in a webpage) be a variable in the JavaScript
> (defined by the rendering system, ie, parent page) that contains a URL
> to a proxy script (ie, http://example.com/proxy/?url=) and that if
> this is present the widget code SHOULD access using this proxy.  If
> using a desktop rendering system (ala Google Desktop) there SHOULD NOT
> be such a variable.  If there is no such variable the widget code
> SHOULD access resources directly.
>

Sorry, this solution sounds a bit hackish to me. There are better ways
to do off-line persistent storage. I also don't see how it addresses
the XMLHttpRequest security issues Arve mentioned.

Arve, I guess in regards to XMLHttpRequest security issue, the browser
security model still applies.

-- 
Marcos Caceres
http://datadriven.com.au

Received on Saturday, 24 February 2007 10:25:16 UTC