You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wookie.apache.org by Michael Hertel <mi...@googlemail.com> on 2012/07/12 13:10:41 UTC
Problem with multiple html files
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.
Re: Problem with multiple html files
Posted by Scott Wilson <sc...@gmail.com>.
On 12 Jul 2012, at 18:43, Michael Hertel wrote:
> 2012/7/12 Scott Wilson <sc...@gmail.com>
>
>> On 12 Jul 2012, at 14:54, Michael Hertel wrote:
>>
>>> 2012/7/12 Scott Wilson <sc...@gmail.com>
>>>
>>>> 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 <sc...@gmail.com>
>>>>>
>>>>>> 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
>>>>
>>>>
>>
>>
Re: Problem with multiple html files
Posted by Michael Hertel <mi...@googlemail.com>.
2012/7/12 Scott Wilson <sc...@gmail.com>
> On 12 Jul 2012, at 14:54, Michael Hertel wrote:
>
> > 2012/7/12 Scott Wilson <sc...@gmail.com>
> >
> >> 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 <sc...@gmail.com>
> >>>
> >>>> 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
> >>
> >>
>
>
Re: Problem with multiple html files
Posted by Scott Wilson <sc...@gmail.com>.
On 12 Jul 2012, at 14:54, Michael Hertel wrote:
> 2012/7/12 Scott Wilson <sc...@gmail.com>
>
>> 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!
>
>> 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 <sc...@gmail.com>
>>>
>>>> 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
>>
>>
Re: Problem with multiple html files
Posted by Michael Hertel <mi...@googlemail.com>.
2012/7/12 Scott Wilson <sc...@gmail.com>
> 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 <sc...@gmail.com>
> >
> >> 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
>
>
Re: Problem with multiple html files
Posted by Scott Wilson <sc...@gmail.com>.
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?
> 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
>
> 2012/7/12 Scott Wilson <sc...@gmail.com>
>
>> 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
Re: Problem with multiple html files
Posted by Michael Hertel <mi...@googlemail.com>.
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.
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.
2012/7/12 Scott Wilson <sc...@gmail.com>
> 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
Re: Problem with multiple html files
Posted by Scott Wilson <sc...@gmail.com>.
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