2012/7/12 Scott Wilson <[email protected]> > On 12 Jul 2012, at 14:54, Michael Hertel wrote: > > > 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". > > Thanks for testing that Michael - I've replicated it myself and you are > quite correct. > > I did some investigation and discovered the source of the problem is in > the list of default supported locales set in widgetserver.properties, which > doesn't include "de": > > ## language settings > ## NB "en-gb-yorks" is for testing localization > widget.locales=en, nl, fr, en-gb-yorks > widget.default.locale=en > > This list is used to determine which start files are processed in the > widget package; the workaround is to add your locales to > widgetserver.properties, e.g. > > widget.locales=en, nl, fr, de > > This should then fix the problem. > > However I think there is also a good case for in future removing this > list and processing all localised start files. In the meantime it should > certainly be better documented - thank you for identifying this problem! > > An other possibility is to replace the list with an algorithm, which checks if the name of a directory in the locales directory is a valid combination of language and region from the IANA language subtag registry ( http://www.w3.org/TR/widgets/#folder-based-localization).
> > > >> 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! > > > > > 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 > >> > >> > >
