2012/7/12 Scott Wilson <[email protected]> > On 12 Jul 2012, at 13:40, Michael Hertel wrote: > > > My first solution used innerHTML, but that wasn´t nice in my opinion. So > i > > tried it with window.location.href. I think I should go back to the first > > solution or use an iframe. > > But the problem with the javascript API also occurs if I localise the > > index.html (default start file). If this file (for example: > > locales/en/index.html) contains some javascript, such as > > "widget.proxify(url)", the user agent can´t access the widget object. > > I just tried to replicate this with a widget containing the following: > > /locales/en/index.html > config.xml > > and in locales/en/index.html I put "alert(window.widget)" > > When I view it in the demo page, I get "Object object"; inspecting with > Jash I can also access "widget.proxify" so this seems as expected. > > So I wonder if there is another problem here? > > My widget package contains the following files: /locales/de/index.html index.html config.xml Both "index.html" files have the same content: "alert(window.widget);" For the unlocalised file the user agent says "object", but for the localised it says "undefined".
> Another problem I found occurs by using an iframe with a remote url inside > > the widget. In that case the user agent always denies the access to > > the property > > 'dispatchEvent' (wookie-wrapper.js, line 229), if the " > > widget.preferences.setItem" function is called. The iframe itself doesn´t > > modify anything of the widget. > > That sounds like a cross-origin request issue that should be handled > better by wookie-wrapper.js; can you create a new issue in the tracker for > it? > > https://issues.apache.org/jira/browse/WOOKIE Added the issue. Thanks for your help. > > > > > > 2012/7/12 Scott Wilson <[email protected]> > > > >> 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 > >
