You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Leonardo Uribe <lu...@gmail.com> on 2011/10/11 23:23:22 UTC
Hi
Trying to fix MYFACES-3106, I notice that when an ajax request is
triggered using <f:ajax render="@all"> for example, the javascript
part that process the response does not check if new <link> tags has
been added to <head> section, so if you have something dynamically in
this part using combinations of <c:if> or <ui:include src="#{...}">
and for example composite components using <h:outputStylesheet>, only
the scripts are loaded but not the stylesheets.
But looking on the internet I have found possible was to load .css
files dynamically. For example see:
http://stackoverflow.com/questions/574944/how-to-load-up-css-files-using-javascript
There are other sites with some scripts that do the trick, adding a
<link> node under <head>.
My question is: it is possible to do something in this part to keep
track of stylesheets loaded on <head> section and just load the ones
required in a ajax request? If that so, I think we can do some
modifications in myfaces code to check if a stylesheet was added and
include a <update id="javax.faces.ViewHead"> section automatically.
regards,
Leonardo Uribe
tomahawk dynamic tabbedPane
Posted by Adam Furmanczuk <af...@knowtrek.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
the tabbedPane in tomahawk is a bit rusty now. I noticed no real
progress recently. In mail archives people complained about tabbedPane
issues years before. And using c:forEach is no good workarround.
I wonder why all tabbedpanes have the inherent inabillity to support
ui:repeat?
I read this post on how to make a "tabbed pane" [1].
May brilliant idea is: you define in tabbedPane a sepecial tag handler
on what items to group by. say:
<t:tabbedPane groupBy="h:panelGroup">
<ui:repeat value="#{list} var="item">
<h:panelGroup>
<h:outputText value="#{item.name}"/>
</h:panelGroup>
</:uirpeat>
</:tabbedPane>
Now tabbedPane notices: Oh, I have sone h:panelGroups inside next to
each other and i should groupBy panelGroups: ok i make the tabs.. ??
tabbePane knows panelTab can't it be thought to know ui:repeats as well?
Is it difficult to rewrite the tabbedpane to enable ui:repeat?
What would be the steps to make it work?
I tested many alternatives: primefaces:tabView, openfaces:tabset..
Most promising is openfaces:tabbedpane, but cannot make it work properly
somehow..
Thanks for feedback.
Greets,
Adam
[1] =
http://stackoverflow.com/questions/3491969/how-do-i-get-a-tabbed-pane-component-in-jsf-2-0-sun-mojarra
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6Wi0wACgkQefEEI87R1DfFBwCfdqlD9W5vmHsDg6/s5aBgh49b
1A8AnRHYQNe2xTVaAax1/Qgwsxnng6Ok
=g02n
-----END PGP SIGNATURE-----
Ok I just committed my code, give it a proper testing and then I guess
you can close the issue.
Werner
Am 10/13/11 10:02 AM, schrieb Werner Punz:
> Yes... i will do additional testing with xhtml strict and if they work
> out I will merge the changes in.
> I am glad that I finally could resolve that issue.
> I will also investigate whether we can do the same for title and meta
> tags, which might be vital to get up to a full head replacement simulation.
>
> Werner
>
>
> Am 10/13/11 1:51 AM, schrieb Leonardo Uribe:
>> Hi
>>
>> The example and the code looks great!.
>>
>> In conclusion I think we can agree on:
>>
>> - Include css fix with no param (or in other words enabled always).
>> - Include onload handlers proposed behavior optionally with a config
>> switch, because it is reasonable to do a combined effort in this case.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>> 2011/10/12 Werner Punz<we...@gmail.com>:
>>> Am 10/12/11 6:19 PM, schrieb Leonardo Uribe:
>>>>
>>>> Hi
>>>>
>>>>> ok guys I think I have found a suitable solution to the issue.
>>>>> You can see my work and the integration test on the jsf.js testuite
>>>>> under
>>>>> http://code.google.com/a/apache-extras.org/p/myfaces-core-examples/
>>>>>
>>>>
>>>> I tried to download it but I can't see anything. Clicking on Source /
>>>> Browse there is nothing there.
>>>>
>>> Hi Leo, wrong Link:
>>> http://code.google.com/a/apache-extras.org/p/myfaces-js-integrationtests/
>>>
>>>
>>> thats the correct one.
>>>
>>> Werner
>>>
>>>
>>>
>>
>
>
>
Yes... i will do additional testing with xhtml strict and if they work
out I will merge the changes in.
I am glad that I finally could resolve that issue.
I will also investigate whether we can do the same for title and meta
tags, which might be vital to get up to a full head replacement simulation.
Werner
Am 10/13/11 1:51 AM, schrieb Leonardo Uribe:
> Hi
>
> The example and the code looks great!.
>
> In conclusion I think we can agree on:
>
> - Include css fix with no param (or in other words enabled always).
> - Include onload handlers proposed behavior optionally with a config
> switch, because it is reasonable to do a combined effort in this case.
>
> regards,
>
> Leonardo Uribe
>
> 2011/10/12 Werner Punz<we...@gmail.com>:
>> Am 10/12/11 6:19 PM, schrieb Leonardo Uribe:
>>>
>>> Hi
>>>
>>>> ok guys I think I have found a suitable solution to the issue.
>>>> You can see my work and the integration test on the jsf.js testuite under
>>>> http://code.google.com/a/apache-extras.org/p/myfaces-core-examples/
>>>>
>>>
>>> I tried to download it but I can't see anything. Clicking on Source /
>>> Browse there is nothing there.
>>>
>> Hi Leo, wrong Link:
>> http://code.google.com/a/apache-extras.org/p/myfaces-js-integrationtests/
>>
>> thats the correct one.
>>
>> Werner
>>
>>
>>
>
Hi
The example and the code looks great!.
In conclusion I think we can agree on:
- Include css fix with no param (or in other words enabled always).
- Include onload handlers proposed behavior optionally with a config
switch, because it is reasonable to do a combined effort in this case.
regards,
Leonardo Uribe
2011/10/12 Werner Punz <we...@gmail.com>:
> Am 10/12/11 6:19 PM, schrieb Leonardo Uribe:
>>
>> Hi
>>
>>> ok guys I think I have found a suitable solution to the issue.
>>> You can see my work and the integration test on the jsf.js testuite under
>>> http://code.google.com/a/apache-extras.org/p/myfaces-core-examples/
>>>
>>
>> I tried to download it but I can't see anything. Clicking on Source /
>> Browse there is nothing there.
>>
> Hi Leo, wrong Link:
> http://code.google.com/a/apache-extras.org/p/myfaces-js-integrationtests/
>
> thats the correct one.
>
> Werner
>
>
>
Am 10/12/11 6:19 PM, schrieb Leonardo Uribe:
> Hi
>
>> ok guys I think I have found a suitable solution to the issue.
>> You can see my work and the integration test on the jsf.js testuite under
>> http://code.google.com/a/apache-extras.org/p/myfaces-core-examples/
>>
>
> I tried to download it but I can't see anything. Clicking on Source /
> Browse there is nothing there.
>
Hi Leo, wrong Link:
http://code.google.com/a/apache-extras.org/p/myfaces-js-integrationtests/
thats the correct one.
Werner
Actually I am sorry, I did not read the mail thoroughly and vice vers.
The CSS fix definitely will be enabled by default,
what I was talking about is calling the onload handlers in the case if set.
The CSS fix is uncritical and is definitely a bug since it is a content
update, and updating the css is spec compliant.
The onload handler calling in viewbody and viewroot case is a spec hole,
and I will enable it only via a config param.
Werner
Am 10/13/11 12:57 AM, schrieb Werner Punz:
> Actually the problem by enabling it by default simply is that there is a
> high chance that we break the existing complibs, after all we have
> a common behavior with mojarra here. This change has such a huge impact
> that if it is done it must be done in conjunction with mojarra.
>
>
> Werner
>
>
> Am 10/12/11 11:45 PM, schrieb Leonardo Uribe:
>> 2011/10/12 Werner Punz<we...@gmail.com>:
>>> Am 10/12/11 10:17 PM, schrieb Leonardo Uribe:
>>>
>>>>
>>>> Good question. I agree with you about clear this up with the jsf eg
>>>> guys, but I think we should at least fix the problem with the
>>>> stylesheets (and maybe do the script replacement) on the "mean time".
>>>> For the scope of MYFACES-3106, this is the only concern.
>>>>
>>>
>>> I just talked to Ed Burns regarding it, and he told me to leave it
>>> out for
>>> now. I probably will enable it via a config switch like we have it for
>>> iframe ppr event queuing different transports etc... And leave it off
>>> per
>>> default so that we have it in for users who want to use this stuff.
>>>
>>
>> Really I would like to have it enabled by default. For example look
>> this example:
>>
>> <h:commandButton ...>
>> <f:ajax render="content"/>
>> </h:commandButton>
>>
>> <f:subview id="content">
>> ...
>> <c:if test="#{...}">
>> <my:customComponent ....>
>> </c:if>
>> ...
>> </f:subview>
>>
>> customComponent.xhtml
>>
>> <cc:implementation>
>> <h:outputStylesheet ..../>
>> ....
>> </cc:implementation>
>>
>> Without the fix it will fail. Note h:outputStylesheet target all
>> stylesheets by default to<head>. Note that f:ajax render="@all" is
>> not used, so in theory the jsf implementation is responsible to detect
>> if a resource was added to head target and if that so, send an
>> additional<update id="javax.faces.ViewHead"> automatically. Why the
>> developer has to worry about an internal detail of a composite
>> component when using f:ajax?. It just breaks encapsulation principle.
>>
>> The point is in my personal opinion there is no reason why leave it
>> out for now or disable it by default. It is technically feasible,
>> doesn't break the spec, and if Mojarra don't want to implement it
>> doesn't mean we should do the same.
>>
>> Anyway, have a config switch to enable it is better than nothing, and
>> later we can fix it properly, getting rid the need of the switch. So
>> +1 to fix it, and ++1 to fix it and leave it enabled by default.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>>>
>>> Werner
>>>
>>>
>>
>
>
>
Actually the problem by enabling it by default simply is that there is a
high chance that we break the existing complibs, after all we have
a common behavior with mojarra here. This change has such a huge impact
that if it is done it must be done in conjunction with mojarra.
Werner
Am 10/12/11 11:45 PM, schrieb Leonardo Uribe:
> 2011/10/12 Werner Punz<we...@gmail.com>:
>> Am 10/12/11 10:17 PM, schrieb Leonardo Uribe:
>>
>>>
>>> Good question. I agree with you about clear this up with the jsf eg
>>> guys, but I think we should at least fix the problem with the
>>> stylesheets (and maybe do the script replacement) on the "mean time".
>>> For the scope of MYFACES-3106, this is the only concern.
>>>
>>
>> I just talked to Ed Burns regarding it, and he told me to leave it out for
>> now. I probably will enable it via a config switch like we have it for
>> iframe ppr event queuing different transports etc... And leave it off per
>> default so that we have it in for users who want to use this stuff.
>>
>
> Really I would like to have it enabled by default. For example look
> this example:
>
> <h:commandButton ...>
> <f:ajax render="content"/>
> </h:commandButton>
>
> <f:subview id="content">
> ...
> <c:if test="#{...}">
> <my:customComponent ....>
> </c:if>
> ...
> </f:subview>
>
> customComponent.xhtml
>
> <cc:implementation>
> <h:outputStylesheet ..../>
> ....
> </cc:implementation>
>
> Without the fix it will fail. Note h:outputStylesheet target all
> stylesheets by default to<head>. Note that f:ajax render="@all" is
> not used, so in theory the jsf implementation is responsible to detect
> if a resource was added to head target and if that so, send an
> additional<update id="javax.faces.ViewHead"> automatically. Why the
> developer has to worry about an internal detail of a composite
> component when using f:ajax?. It just breaks encapsulation principle.
>
> The point is in my personal opinion there is no reason why leave it
> out for now or disable it by default. It is technically feasible,
> doesn't break the spec, and if Mojarra don't want to implement it
> doesn't mean we should do the same.
>
> Anyway, have a config switch to enable it is better than nothing, and
> later we can fix it properly, getting rid the need of the switch. So
> +1 to fix it, and ++1 to fix it and leave it enabled by default.
>
> regards,
>
> Leonardo Uribe
>
>>
>> Werner
>>
>>
>
It actually is not a bug but a huge spec hole.
The spec is rather open what happens, it just says,
body and head will be replaced. Now, the head is not replacable you just
can simulate it.
What happens to onload handlers is left entirely open.
The problem i have with divergence to mojarra is, that we would
deliberately break component sets which rely on a certain behavior in
the ajax case for initialisation and on onload handlers for normal page
refresh initialisation.
This should and can only be done on spec level I think, or in a combined
effort on both impls to change the behavior.
Werner
Am 10/12/11 11:50 PM, schrieb Mike Kienenberger:
> if it doesn't break the spec, +1 to enable it by default and not have
> a config switch.
>
> I never really understood why we are so pedantic about making sure
> we have the same behavior as Mojarra at all times. We certainly
> shouldn't have as a goal to be bug-compatible with Mojarra.
>
> On Wed, Oct 12, 2011 at 5:45 PM, Leonardo Uribe<lu...@gmail.com> wrote:
>> 2011/10/12 Werner Punz<we...@gmail.com>:
>>> Am 10/12/11 10:17 PM, schrieb Leonardo Uribe:
>>>
>>>>
>>>> Good question. I agree with you about clear this up with the jsf eg
>>>> guys, but I think we should at least fix the problem with the
>>>> stylesheets (and maybe do the script replacement) on the "mean time".
>>>> For the scope of MYFACES-3106, this is the only concern.
>>>>
>>>
>>> I just talked to Ed Burns regarding it, and he told me to leave it out for
>>> now. I probably will enable it via a config switch like we have it for
>>> iframe ppr event queuing different transports etc... And leave it off per
>>> default so that we have it in for users who want to use this stuff.
>>>
>>
>> Really I would like to have it enabled by default. For example look
>> this example:
>>
>> <h:commandButton ...>
>> <f:ajax render="content"/>
>> </h:commandButton>
>>
>> <f:subview id="content">
>> ...
>> <c:if test="#{...}">
>> <my:customComponent ....>
>> </c:if>
>> ...
>> </f:subview>
>>
>> customComponent.xhtml
>>
>> <cc:implementation>
>> <h:outputStylesheet ..../>
>> ....
>> </cc:implementation>
>>
>> Without the fix it will fail. Note h:outputStylesheet target all
>> stylesheets by default to<head>. Note that f:ajax render="@all" is
>> not used, so in theory the jsf implementation is responsible to detect
>> if a resource was added to head target and if that so, send an
>> additional<update id="javax.faces.ViewHead"> automatically. Why the
>> developer has to worry about an internal detail of a composite
>> component when using f:ajax?. It just breaks encapsulation principle.
>>
>> The point is in my personal opinion there is no reason why leave it
>> out for now or disable it by default. It is technically feasible,
>> doesn't break the spec, and if Mojarra don't want to implement it
>> doesn't mean we should do the same.
>>
>> Anyway, have a config switch to enable it is better than nothing, and
>> later we can fix it properly, getting rid the need of the switch. So
>> +1 to fix it, and ++1 to fix it and leave it enabled by default.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>>>
>>> Werner
>>>
>>>
>>
>
if it doesn't break the spec, +1 to enable it by default and not have
a config switch.
I never really understood why we are so pedantic about making sure
we have the same behavior as Mojarra at all times. We certainly
shouldn't have as a goal to be bug-compatible with Mojarra.
On Wed, Oct 12, 2011 at 5:45 PM, Leonardo Uribe <lu...@gmail.com> wrote:
> 2011/10/12 Werner Punz <we...@gmail.com>:
>> Am 10/12/11 10:17 PM, schrieb Leonardo Uribe:
>>
>>>
>>> Good question. I agree with you about clear this up with the jsf eg
>>> guys, but I think we should at least fix the problem with the
>>> stylesheets (and maybe do the script replacement) on the "mean time".
>>> For the scope of MYFACES-3106, this is the only concern.
>>>
>>
>> I just talked to Ed Burns regarding it, and he told me to leave it out for
>> now. I probably will enable it via a config switch like we have it for
>> iframe ppr event queuing different transports etc... And leave it off per
>> default so that we have it in for users who want to use this stuff.
>>
>
> Really I would like to have it enabled by default. For example look
> this example:
>
> <h:commandButton ... >
> <f:ajax render="content"/>
> </h:commandButton>
>
> <f:subview id="content">
> ...
> <c:if test="#{...}">
> <my:customComponent ....>
> </c:if>
> ...
> </f:subview>
>
> customComponent.xhtml
>
> <cc:implementation>
> <h:outputStylesheet ..../>
> ....
> </cc:implementation>
>
> Without the fix it will fail. Note h:outputStylesheet target all
> stylesheets by default to <head>. Note that f:ajax render="@all" is
> not used, so in theory the jsf implementation is responsible to detect
> if a resource was added to head target and if that so, send an
> additional <update id="javax.faces.ViewHead"> automatically. Why the
> developer has to worry about an internal detail of a composite
> component when using f:ajax?. It just breaks encapsulation principle.
>
> The point is in my personal opinion there is no reason why leave it
> out for now or disable it by default. It is technically feasible,
> doesn't break the spec, and if Mojarra don't want to implement it
> doesn't mean we should do the same.
>
> Anyway, have a config switch to enable it is better than nothing, and
> later we can fix it properly, getting rid the need of the switch. So
> +1 to fix it, and ++1 to fix it and leave it enabled by default.
>
> regards,
>
> Leonardo Uribe
>
>>
>> Werner
>>
>>
>
2011/10/12 Werner Punz <we...@gmail.com>:
> Am 10/12/11 10:17 PM, schrieb Leonardo Uribe:
>
>>
>> Good question. I agree with you about clear this up with the jsf eg
>> guys, but I think we should at least fix the problem with the
>> stylesheets (and maybe do the script replacement) on the "mean time".
>> For the scope of MYFACES-3106, this is the only concern.
>>
>
> I just talked to Ed Burns regarding it, and he told me to leave it out for
> now. I probably will enable it via a config switch like we have it for
> iframe ppr event queuing different transports etc... And leave it off per
> default so that we have it in for users who want to use this stuff.
>
Really I would like to have it enabled by default. For example look
this example:
<h:commandButton ... >
<f:ajax render="content"/>
</h:commandButton>
<f:subview id="content">
...
<c:if test="#{...}">
<my:customComponent ....>
</c:if>
...
</f:subview>
customComponent.xhtml
<cc:implementation>
<h:outputStylesheet ..../>
....
</cc:implementation>
Without the fix it will fail. Note h:outputStylesheet target all
stylesheets by default to <head>. Note that f:ajax render="@all" is
not used, so in theory the jsf implementation is responsible to detect
if a resource was added to head target and if that so, send an
additional <update id="javax.faces.ViewHead"> automatically. Why the
developer has to worry about an internal detail of a composite
component when using f:ajax?. It just breaks encapsulation principle.
The point is in my personal opinion there is no reason why leave it
out for now or disable it by default. It is technically feasible,
doesn't break the spec, and if Mojarra don't want to implement it
doesn't mean we should do the same.
Anyway, have a config switch to enable it is better than nothing, and
later we can fix it properly, getting rid the need of the switch. So
+1 to fix it, and ++1 to fix it and leave it enabled by default.
regards,
Leonardo Uribe
>
> Werner
>
>
Am 10/12/11 10:17 PM, schrieb Leonardo Uribe:
>
> Good question. I agree with you about clear this up with the jsf eg
> guys, but I think we should at least fix the problem with the
> stylesheets (and maybe do the script replacement) on the "mean time".
> For the scope of MYFACES-3106, this is the only concern.
>
I just talked to Ed Burns regarding it, and he told me to leave it out
for now. I probably will enable it via a config switch like we have it
for iframe ppr event queuing different transports etc... And leave it
off per default so that we have it in for users who want to use this stuff.
Werner
Hi
2011/10/12 Werner Punz <we...@gmail.com>:
> Am 10/12/11 6:19 PM, schrieb Leonardo Uribe:
>
>> In theory that should not cause any problem. If we remove the old
>> scripts, the objects defined are still in "memory", so apply the new
>> ones will just refresh the memory.
>> In practice it is equivalent to
>> just run the new scripts, but anyway the head replacement looks
>> better, because you can see if the script was added or not using
>> firebug.
>>
> The entire viewroot replacement opens another question
> If we replace viewroot this theoretically would mean a full page refresh
> simulation.
>
> Aka, what should happen if the new page has body or window onload hooks.
> The question simply is if we fully simulate a page refresh those hooks ought
> to be called. Practically however neither myfaces nor mojarra do it at the
> moment.
>
> My personal preference would be to enable the onload handling via a config
> option and to try to clear this up with the jsf eg guys, so that
> we get a common ground there.
>
Good question. I agree with you about clear this up with the jsf eg
guys, but I think we should at least fix the problem with the
stylesheets (and maybe do the script replacement) on the "mean time".
For the scope of MYFACES-3106, this is the only concern.
Leonardo
> Werner
>
>
>
Am 10/12/11 6:19 PM, schrieb Leonardo Uribe:
> In theory that should not cause any problem. If we remove the old
> scripts, the objects defined are still in "memory", so apply the new
> ones will just refresh the memory.
> In practice it is equivalent to
> just run the new scripts, but anyway the head replacement looks
> better, because you can see if the script was added or not using
> firebug.
>
The entire viewroot replacement opens another question
If we replace viewroot this theoretically would mean a full page refresh
simulation.
Aka, what should happen if the new page has body or window onload hooks.
The question simply is if we fully simulate a page refresh those hooks
ought to be called. Practically however neither myfaces nor mojarra do
it at the moment.
My personal preference would be to enable the onload handling via a
config option and to try to clear this up with the jsf eg guys, so that
we get a common ground there.
Werner
Hi
> ok guys I think I have found a suitable solution to the issue.
> You can see my work and the integration test on the jsf.js testuite under
> http://code.google.com/a/apache-extras.org/p/myfaces-core-examples/
>
I tried to download it but I can't see anything. Clicking on Source /
Browse there is nothing there.
> if you just want to see the example itself which executes the css test run
> it with mvn jetty:run and then call
> http://localhost:9080
> http://localhost:9080/integrationtests/test13-cssreplacementhead.jsf
>
> You will see three divs with a border before the refresh
> and four divs with a border after the refresh, the three original divs
> have lost their border, which means the styles have been cleared out.
>
> I tried to reduce flickering caused by style clearing, so i clear the old
> styles out after the new ones are applied, nevertheless I am getting
> a short flicker with a background color set on firefox, but no other
> browser.
>
> Also I now clear the old scripts from the page and apply the new ones, so
> that a head replacement really is a head replacement.
> Not sure if we should keep this behavior or not though.
>
In theory that should not cause any problem. If we remove the old
scripts, the objects defined are still in "memory", so apply the new
ones will just refresh the memory. In practice it is equivalent to
just run the new scripts, but anyway the head replacement looks
better, because you can see if the script was added or not using
firebug.
regards,
Leonardo Uribe
> Werner
>
>
Am 10/12/11 3:21 PM, schrieb Werner Punz:
> Am 10/12/11 2:00 PM, schrieb Werner Punz:
>> Am 10/12/11 10:25 AM, schrieb Werner Punz:
>>> Am 10/12/11 12:18 AM, schrieb Leonardo Uribe:
>>>
>>>> Thanks Çağatay for the comment.
>>>>
>>>> @Werner : if you have time could you help me with this?
>>>>
>>> Sure... I will refine our head replacement part this week
>>> as far as my time permits (customers first as usual)
>>> and then lets see what I can achieve.
>>>
>> Ok I now know why I left the functionality out. The css replacement
>> techniques do not work
>> on webkit based browsers because webkit refuses to alter the head after
>> the document has loaded. I left it out intentionally to get the same
>> behavior regardless of the engine.
>>
> Ok good news, I finally found out why it was not working on webkit.
>
>
ok guys I think I have found a suitable solution to the issue.
You can see my work and the integration test on the jsf.js testuite under
http://code.google.com/a/apache-extras.org/p/myfaces-core-examples/
if you just want to see the example itself which executes the css test
run it with mvn jetty:run and then call
http://localhost:9080
http://localhost:9080/integrationtests/test13-cssreplacementhead.jsf
You will see three divs with a border before the refresh
and four divs with a border after the refresh, the three original divs
have lost their border, which means the styles have been cleared out.
I tried to reduce flickering caused by style clearing, so i clear the
old styles out after the new ones are applied, nevertheless I am getting
a short flicker with a background color set on firefox, but no other
browser.
Also I now clear the old scripts from the page and apply the new ones,
so that a head replacement really is a head replacement.
Not sure if we should keep this behavior or not though.
Werner
Hi Werner
Great!
Leonardo
2011/10/12 Werner Punz <we...@gmail.com>:
> Am 10/12/11 2:00 PM, schrieb Werner Punz:
>>
>> Am 10/12/11 10:25 AM, schrieb Werner Punz:
>>>
>>> Am 10/12/11 12:18 AM, schrieb Leonardo Uribe:
>>>
>>>> Thanks Çağatay for the comment.
>>>>
>>>> @Werner : if you have time could you help me with this?
>>>>
>>> Sure... I will refine our head replacement part this week
>>> as far as my time permits (customers first as usual)
>>> and then lets see what I can achieve.
>>>
>> Ok I now know why I left the functionality out. The css replacement
>> techniques do not work
>> on webkit based browsers because webkit refuses to alter the head after
>> the document has loaded. I left it out intentionally to get the same
>> behavior regardless of the engine.
>>
> Ok good news, I finally found out why it was not working on webkit.
>
>
> Werner
>
>
>
>
Am 10/12/11 2:00 PM, schrieb Werner Punz:
> Am 10/12/11 10:25 AM, schrieb Werner Punz:
>> Am 10/12/11 12:18 AM, schrieb Leonardo Uribe:
>>
>>> Thanks Çağatay for the comment.
>>>
>>> @Werner : if you have time could you help me with this?
>>>
>> Sure... I will refine our head replacement part this week
>> as far as my time permits (customers first as usual)
>> and then lets see what I can achieve.
>>
> Ok I now know why I left the functionality out. The css replacement
> techniques do not work
> on webkit based browsers because webkit refuses to alter the head after
> the document has loaded. I left it out intentionally to get the same
> behavior regardless of the engine.
>
Ok good news, I finally found out why it was not working on webkit.
Werner
Am 10/12/11 10:25 AM, schrieb Werner Punz:
> Am 10/12/11 12:18 AM, schrieb Leonardo Uribe:
>
>> Thanks Çağatay for the comment.
>>
>> @Werner : if you have time could you help me with this?
>>
> Sure... I will refine our head replacement part this week
> as far as my time permits (customers first as usual)
> and then lets see what I can achieve.
>
Ok I now know why I left the functionality out. The css replacement
techniques do not work
on webkit based browsers because webkit refuses to alter the head after
the document has loaded. I left it out intentionally to get the same
behavior regardless of the engine.
Werner
Am 10/12/11 10:25 AM, schrieb Werner Punz:
> Am 10/12/11 12:18 AM, schrieb Leonardo Uribe:
>
>> Thanks Çağatay for the comment.
>>
>> @Werner : if you have time could you help me with this?
>>
> Sure... I will refine our head replacement part this week
> as far as my time permits (customers first as usual)
> and then lets see what I can achieve.
>
> werner
>
>
>
Ok working on it, btw. just a fair warning i ran my newly written tests
regarding the css head replacement also against mojarra, they do not do
it as well. I will probably have to file a bugreport to Ed and Co. as well.
Werner
Am 10/12/11 12:18 AM, schrieb Leonardo Uribe:
> Thanks Çağatay for the comment.
>
> @Werner : if you have time could you help me with this?
>
Sure... I will refine our head replacement part this week
as far as my time permits (customers first as usual)
and then lets see what I can achieve.
werner
Hi Çağatay
Yes, there is no render="@head" or render="@body". Maybe it is
something to include in JSF 2.2.
So it is possible. I'll reopen MYFACES-3106. This issue is too
annoying. It is common that people try to use <ui:include src="#{...}"
/> or <c:if> and then <f:ajax> to update the content. If the content
add some .css or .js using @ResourceDependency over a
component/renderer or h:outputStylesheet/h:outputScript, the server
side ( in myfaces case
org.apache.myfaces.context.servlet.PartialViewContextImpl ) should
trigger <update id="javax.faces.ViewHead"> or <update
id="javax.faces.ViewBody"> automatically, and the javascript part of
myfaces should deal with this.
Thanks Çağatay for the comment.
@Werner : if you have time could you help me with this?
regards,
Leonardo Uribe
2011/10/11 Çağatay Çivici <ca...@gmail.com>:
> Hi,
> PrimeFaces themeswitcher also manipulates link tags in head to load css
> without page refresh;
> http://www.primefaces.org/showcase-labs/ui/themeswitcher.jsf
> One question, when <update id="javax.faces.ViewHead"> exists in partial
> response, there is no render="@head" right?
> Cheers,
> On 12.Eki.2011, at 00:23, Leonardo Uribe wrote:
>
> Hi
>
> Trying to fix MYFACES-3106, I notice that when an ajax request is
> triggered using <f:ajax render="@all"> for example, the javascript
> part that process the response does not check if new <link> tags has
> been added to <head> section, so if you have something dynamically in
> this part using combinations of <c:if> or <ui:include src="#{...}">
> and for example composite components using <h:outputStylesheet>, only
> the scripts are loaded but not the stylesheets.
>
> But looking on the internet I have found possible was to load .css
> files dynamically. For example see:
>
> http://stackoverflow.com/questions/574944/how-to-load-up-css-files-using-javascript
>
> There are other sites with some scripts that do the trick, adding a
> <link> node under <head>.
>
> My question is: it is possible to do something in this part to keep
> track of stylesheets loaded on <head> section and just load the ones
> required in a ajax request? If that so, I think we can do some
> modifications in myfaces code to check if a stylesheet was added and
> include a <update id="javax.faces.ViewHead"> section automatically.
>
> regards,
>
> Leonardo Uribe
>
> Çağatay Çivici
> Principal Consultant
> PrimeFaces Lead | JSF EG Member
>
> Prime Teknoloji
> Bilkent Cyberpark, A-303d
> 06800 Ankara/Turkey
> Tel: +90 312 265 05 07
> http://www.prime.com.tr
>
Hi,
PrimeFaces themeswitcher also manipulates link tags in head to load css without page refresh;
http://www.primefaces.org/showcase-labs/ui/themeswitcher.jsf
One question, when <update id="javax.faces.ViewHead"> exists in partial response, there is no render="@head" right?
Cheers,
On 12.Eki.2011, at 00:23, Leonardo Uribe wrote:
> Hi
>
> Trying to fix MYFACES-3106, I notice that when an ajax request is
> triggered using <f:ajax render="@all"> for example, the javascript
> part that process the response does not check if new <link> tags has
> been added to <head> section, so if you have something dynamically in
> this part using combinations of <c:if> or <ui:include src="#{...}">
> and for example composite components using <h:outputStylesheet>, only
> the scripts are loaded but not the stylesheets.
>
> But looking on the internet I have found possible was to load .css
> files dynamically. For example see:
>
> http://stackoverflow.com/questions/574944/how-to-load-up-css-files-using-javascript
>
> There are other sites with some scripts that do the trick, adding a
> <link> node under <head>.
>
> My question is: it is possible to do something in this part to keep
> track of stylesheets loaded on <head> section and just load the ones
> required in a ajax request? If that so, I think we can do some
> modifications in myfaces code to check if a stylesheet was added and
> include a <update id="javax.faces.ViewHead"> section automatically.
>
> regards,
>
> Leonardo Uribe
Çağatay Çivici
Principal Consultant
PrimeFaces Lead | JSF EG Member
Prime Teknoloji
Bilkent Cyberpark, A-303d
06800 Ankara/Turkey
Tel: +90 312 265 05 07
http://www.prime.com.tr
Ok first of all a short explanation why we are not loading the css now.
The original idea from the spec side was to run a full replacement of
the head and body. In other words, a simulated browser refresh.
While I could figure out a cross browser working way
of replacing the body, the head replacement was an entirely different beast.
Officially it is forbidden, some browsers allowed it but then had a
messed up dom and some did not allow it at all.
So I ended up with limitating myself on parsing the scripts but
not the css because I could not find a way to do it reliably.
As for tracking old css. I personally think a render head
needs to reload everything even if it is already there css can change
if you have dynamic system behind it.
We also need to make sure to drop the old script nodes and
and css nodes before. (We dont have that yet). My personal hope is
if even possible, that by doing that we might get a clean state on the
css and scripts before loading the stuff again.
If not we have to live with a slightly different behavior to what we
would get with a full page refresh.
I will do a deeper investigation to this issue this week.
Werner
Am 10/11/11 11:23 PM, schrieb Leonardo Uribe:
> Hi
>
> Trying to fix MYFACES-3106, I notice that when an ajax request is
> triggered using<f:ajax render="@all"> for example, the javascript
> part that process the response does not check if new<link> tags has
> been added to<head> section, so if you have something dynamically in
> this part using combinations of<c:if> or<ui:include src="#{...}">
> and for example composite components using<h:outputStylesheet>, only
> the scripts are loaded but not the stylesheets.
>
> But looking on the internet I have found possible was to load .css
> files dynamically. For example see:
>
> http://stackoverflow.com/questions/574944/how-to-load-up-css-files-using-javascript
>
> There are other sites with some scripts that do the trick, adding a
> <link> node under<head>.
>
> My question is: it is possible to do something in this part to keep
> track of stylesheets loaded on<head> section and just load the ones
> required in a ajax request? If that so, I think we can do some
> modifications in myfaces code to check if a stylesheet was added and
> include a<update id="javax.faces.ViewHead"> section automatically.
>
> regards,
>
> Leonardo Uribe
>