You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@deltaspike.apache.org by Christian Beikov <ch...@gmail.com> on 2019/10/09 18:49:08 UTC
JSF-module window handling with frames
Hey,
I'm currently having trouble with the CLIENTWINDOW strategy when using
frames. In my current case the problem is due to the usage of the
Primefaces Dialog-Framework which makes use of iframes for the dialogs.
The frame has a special contentWindow which is inspected by the DS code
for a window id but it can't find it, because it's on the parent window.
Using window scoped beans is impossible in the iframe as it gets a new
window id which makes previous state inaccessible.
Would you consider this a bug or is this intended? Can I somehow append
a dsrid or dswid to the URL to get the same window id in the iframe?
Using the top window for the window id storage by default would make it
impossible to change that aspect selectively and requires changes in the
JS file which will probably take some time to bake, so I would prefer
the append approach if possible. I can't think of a case where one would
want to treat an iframe like a different window but to stay flexible I
understand if you want to stick to the current logic, still, do you have
a use case like that?
Regards,
Christian
Re: JSF-module window handling with frames
Posted by Christian Beikov <ch...@gmail.com>.
Hey, I just created the PR with fixes:
https://github.com/apache/deltaspike/pull/98
Would be great if you could give me feedback.
Am 10.10.2019 um 10:10 schrieb Thomas Andraschko:
> I dont think there is an way to archive that.
> Maybe you can dynamically switch your inner frame views ClientWindowMode to
> lazy and pass the dswid.
>
> Am Mi., 9. Okt. 2019 um 22:41 Uhr schrieb Christian Beikov <
> christian.beikov@gmail.com>:
>
>> Hey,
>>
>> I'm fine with working on a PR but I wanted to first ask if there might
>> be an undocumented way to do what I intend(reuse the same window scope
>> for the frame).
>>
>> If there is no undocumented way currently, I want to understand if
>> people agree that this should be supported and then discuss how to
>> implement it. I wanted to hear from the main maintainer, which seems to
>> be you Thomas, if there is a preference before starting to work on
>> something that might be worthless.
>>
>> Am 09.10.2019 um 22:22 schrieb Thomas Andraschko:
>>> Hi,
>>>
>>> i think it's intended and was never a requirement.
>>> Feel free anaylze it more and work on a PR.
>>> The JS itself is quite good documented + contains many logging + the
>>> mechanism itself is quite good documented in the DS docu.
>>>
>>> <
>> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
>>> Virenfrei.
>>> www.avast.com
>>> <
>> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>
>>> Am Mi., 9. Okt. 2019 um 20:49 Uhr schrieb Christian Beikov <
>>> christian.beikov@gmail.com>:
>>>
>>>> Hey,
>>>>
>>>> I'm currently having trouble with the CLIENTWINDOW strategy when using
>>>> frames. In my current case the problem is due to the usage of the
>>>> Primefaces Dialog-Framework which makes use of iframes for the dialogs.
>>>> The frame has a special contentWindow which is inspected by the DS code
>>>> for a window id but it can't find it, because it's on the parent window.
>>>>
>>>> Using window scoped beans is impossible in the iframe as it gets a new
>>>> window id which makes previous state inaccessible.
>>>>
>>>> Would you consider this a bug or is this intended? Can I somehow append
>>>> a dsrid or dswid to the URL to get the same window id in the iframe?
>>>> Using the top window for the window id storage by default would make it
>>>> impossible to change that aspect selectively and requires changes in the
>>>> JS file which will probably take some time to bake, so I would prefer
>>>> the append approach if possible. I can't think of a case where one would
>>>> want to treat an iframe like a different window but to stay flexible I
>>>> understand if you want to stick to the current logic, still, do you have
>>>> a use case like that?
>>>>
>>>> Regards,
>>>>
>>>> Christian
>>>>
>>>>
Re: JSF-module window handling with frames
Posted by Thomas Andraschko <an...@gmail.com>.
I dont think there is an way to archive that.
Maybe you can dynamically switch your inner frame views ClientWindowMode to
lazy and pass the dswid.
Am Mi., 9. Okt. 2019 um 22:41 Uhr schrieb Christian Beikov <
christian.beikov@gmail.com>:
> Hey,
>
> I'm fine with working on a PR but I wanted to first ask if there might
> be an undocumented way to do what I intend(reuse the same window scope
> for the frame).
>
> If there is no undocumented way currently, I want to understand if
> people agree that this should be supported and then discuss how to
> implement it. I wanted to hear from the main maintainer, which seems to
> be you Thomas, if there is a preference before starting to work on
> something that might be worthless.
>
> Am 09.10.2019 um 22:22 schrieb Thomas Andraschko:
> > Hi,
> >
> > i think it's intended and was never a requirement.
> > Feel free anaylze it more and work on a PR.
> > The JS itself is quite good documented + contains many logging + the
> > mechanism itself is quite good documented in the DS docu.
> >
> > <
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >
> > Virenfrei.
> > www.avast.com
> > <
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >
> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> >
> > Am Mi., 9. Okt. 2019 um 20:49 Uhr schrieb Christian Beikov <
> > christian.beikov@gmail.com>:
> >
> >> Hey,
> >>
> >> I'm currently having trouble with the CLIENTWINDOW strategy when using
> >> frames. In my current case the problem is due to the usage of the
> >> Primefaces Dialog-Framework which makes use of iframes for the dialogs.
> >> The frame has a special contentWindow which is inspected by the DS code
> >> for a window id but it can't find it, because it's on the parent window.
> >>
> >> Using window scoped beans is impossible in the iframe as it gets a new
> >> window id which makes previous state inaccessible.
> >>
> >> Would you consider this a bug or is this intended? Can I somehow append
> >> a dsrid or dswid to the URL to get the same window id in the iframe?
> >> Using the top window for the window id storage by default would make it
> >> impossible to change that aspect selectively and requires changes in the
> >> JS file which will probably take some time to bake, so I would prefer
> >> the append approach if possible. I can't think of a case where one would
> >> want to treat an iframe like a different window but to stay flexible I
> >> understand if you want to stick to the current logic, still, do you have
> >> a use case like that?
> >>
> >> Regards,
> >>
> >> Christian
> >>
> >>
>
Re: JSF-module window handling with frames
Posted by Christian Beikov <ch...@gmail.com>.
Hey,
I'm fine with working on a PR but I wanted to first ask if there might
be an undocumented way to do what I intend(reuse the same window scope
for the frame).
If there is no undocumented way currently, I want to understand if
people agree that this should be supported and then discuss how to
implement it. I wanted to hear from the main maintainer, which seems to
be you Thomas, if there is a preference before starting to work on
something that might be worthless.
Am 09.10.2019 um 22:22 schrieb Thomas Andraschko:
> Hi,
>
> i think it's intended and was never a requirement.
> Feel free anaylze it more and work on a PR.
> The JS itself is quite good documented + contains many logging + the
> mechanism itself is quite good documented in the DS docu.
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> Virenfrei.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> Am Mi., 9. Okt. 2019 um 20:49 Uhr schrieb Christian Beikov <
> christian.beikov@gmail.com>:
>
>> Hey,
>>
>> I'm currently having trouble with the CLIENTWINDOW strategy when using
>> frames. In my current case the problem is due to the usage of the
>> Primefaces Dialog-Framework which makes use of iframes for the dialogs.
>> The frame has a special contentWindow which is inspected by the DS code
>> for a window id but it can't find it, because it's on the parent window.
>>
>> Using window scoped beans is impossible in the iframe as it gets a new
>> window id which makes previous state inaccessible.
>>
>> Would you consider this a bug or is this intended? Can I somehow append
>> a dsrid or dswid to the URL to get the same window id in the iframe?
>> Using the top window for the window id storage by default would make it
>> impossible to change that aspect selectively and requires changes in the
>> JS file which will probably take some time to bake, so I would prefer
>> the append approach if possible. I can't think of a case where one would
>> want to treat an iframe like a different window but to stay flexible I
>> understand if you want to stick to the current logic, still, do you have
>> a use case like that?
>>
>> Regards,
>>
>> Christian
>>
>>
Re: JSF-module window handling with frames
Posted by Thomas Andraschko <an...@gmail.com>.
Hi,
i think it's intended and was never a requirement.
Feel free anaylze it more and work on a PR.
The JS itself is quite good documented + contains many logging + the
mechanism itself is quite good documented in the DS docu.
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virenfrei.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
Am Mi., 9. Okt. 2019 um 20:49 Uhr schrieb Christian Beikov <
christian.beikov@gmail.com>:
> Hey,
>
> I'm currently having trouble with the CLIENTWINDOW strategy when using
> frames. In my current case the problem is due to the usage of the
> Primefaces Dialog-Framework which makes use of iframes for the dialogs.
> The frame has a special contentWindow which is inspected by the DS code
> for a window id but it can't find it, because it's on the parent window.
>
> Using window scoped beans is impossible in the iframe as it gets a new
> window id which makes previous state inaccessible.
>
> Would you consider this a bug or is this intended? Can I somehow append
> a dsrid or dswid to the URL to get the same window id in the iframe?
> Using the top window for the window id storage by default would make it
> impossible to change that aspect selectively and requires changes in the
> JS file which will probably take some time to bake, so I would prefer
> the append approach if possible. I can't think of a case where one would
> want to treat an iframe like a different window but to stay flexible I
> understand if you want to stick to the current logic, still, do you have
> a use case like that?
>
> Regards,
>
> Christian
>
>