On 12 Jul 2012, at 18:43, Michael Hertel wrote: > 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).
Yes - iterating over the immediate sub-directories of /locales would be the right starting point. One problem with the IANA registry is that its quite a large file, and there isn't (currently) an API to do interactive checking (though some people have made their own). Alternatively we can verify that the directory name is a valid language tag in terms of its syntax without referring to the IANA registry - there is already a method in Wookie for doing this (LocalizationUtils.isValidLanguageTag(string)) > > >>> >>>> 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 >>>> >>>> >> >>
