Hello, I just wanted to mention at this point that from the perspective of a developer, who knows the specs but not Wookie, a multiple-page widget seems indeed to be a valid use case. Actually having this perspective, I have implemented a widget-exporter some time ago, that does exactly that: export a collaboratively created text book into the widget format so that a student is able to read it offline. This was basically a zipped bunch of html pages with a few images. However, it seemed quite useful.
As this textbooks did not make use of any APIs, they also worked well with Wookie. To make it work with the "good old" Opera version (that supported widgets as standalone apps), I had to include an awkward, additional iframe wrapper inside the widget though. I am not sure, if I needed the wrapper also for the Obigo runtime, but I remember that I also were able to read the books an my Android phone. I think, as a widget developer I would expect to have the Widget API available within every html page of the widget, which means "inject in every html file", but I might be wrong. So to sum up: feature Best, Michael PS: I also had a short chat with Marcos about that and also had the feeling that considered it a valid case. On Tue, Feb 19, 2013 at 12:21 PM, Scott Wilson < [email protected]> wrote: > On 18 Feb 2013, at 23:19, Ross Gardler wrote: > > > If I separate my widget into two HTML pages, e.g. index.html and > > settings.html the widget-impl.js file is not injected (along with other > > required scripts) in the second page (i.e. the one that is not listed in > > config.xml). > > > > Feature or bug? > > A bit of both. > > There is nothing in the W3C spec saying widgets are single page, its more > of an assumption based on typical practice that "widgets don't navigate", > so we've stuck to the simple case of just processing the start page and > leaving the rest of the .wgt package alone. > > I had a conversation with Marcos a while ago about this and we agreed that > conforming widgets should be able to navigate (i.e. have multiple pages), > its just not a very common development pattern, which is the only reason > its not implemented in Wookie (or Opera either). > > If we did want to support this, we need some logic for how it would work. > Would injecting all files be attempted? Only .html/.htm/.xht? In all > subdirectories or root only? > > (One tricky one would be .xml files, which could be either XHTML pages or > XML data; we could try to "sniff" them by adding another check to > org.apache.wookie.w3c.util.ContentTypeUtils) > > In any case the place to implement this would be in > org.apache.wookie.w3c.W3CWidgetFactory.processWidgetPackage() > > S > > > > > Ross > > > > -- > > Ross Gardler (@rgardler) > > Programme Leader (Open Development) > > OpenDirective http://opendirective.com > >
