On 12 Jul 2012, at 12:10, Michael Hertel wrote:

> Hello.
> 
> I got a problem and I don´t know, if it´s my fault or a bug of Apache
> Wookie. Is it allowed to use more than one html file for a localisation?
> For example if I place a index.html and a example.html in the root of the
> widget package and use the line "window.location.href='example.html';" in a
> javascript tag inside the index.html. The problem is, if I use
> "window.location.href='example.html';" in a widget in Apache Wookie, I
> can´t access the widget javascript API from the example.html file. I can´t
> find any information about this problem in the W3C widget specification.
> 
> Thank you very much in advance for your answer.

Hi Michael,

The good news is I know what is causing this problem. The bad news is, I'm not 
sure whether we can - or should - fix it.

The W3C spec generally assumes that a Widget has a single page (usually HTML) 
which is either specified in the content src="" attribute of config.xml, or is 
in the "default start files list" which includes "index.html, index.xml, 
index.svg" (etc). It also includes any localised variants of these files 
located in "locale folders" (e.g. "locales/de/index.html").

The assumption is that a Widget starts at a (localised) start page, and then 
the browser does not navigate - that is, you don't change the 
window.location.href. 

So, what you are doing isn't really covered by the spec, which is the reason 
why its not behaving well in Wookie as we've mostly stuck to conforming to the 
spec.

If you look inside any HTML file served by Wookie you'll notice it has a lot of 
injected JavaScript files, including the one that creates the window.widget 
object. These are injected into all start files listed by the widget (see 
above) but not any other files in your .wgt package, such as your 
"example.html".

So, whats the solution? Well, it depends on why you want to show this other 
page, but there are alternatives to navigating to it. For example, you could 
use a lightbox instead to show the content; or use AJAX to replace content in 
index.html. Or open example.html in an iframe (making sure you call 
"window.parent.widget" rather than just "widget".) Do any of these sounds 
possible? If not, tell us the use-case and maybe we can think of another 
solution.

If no workarounds are possible, you'd need to extend the widget parser to 
inject the widget API javascript into other HTML files that aren't start files, 
which would probably need an extension to the spec.

Hope this helps, 

S

Reply via email to