Resources not loaded when using a dynamic ui:inlclude and rendered via ajax

[javaserverfaces]

I'm migrating my project from JSF 1.2 to JSF2.1 and I was using a <ui:include src="#

{guiMB.viewID}

" /> tag wrapped in a tag (from RichFaces) and rendering the a4j:outputPanel via ajax. However in JSF2 this doesn't load the resources for the page i'm including.

So anything i include dynamically like this doesn't have any of the styling or javascript that should be loaded with it.

I have created a test project which demonstrates the issue so i'll attach for you to replicate the issue.

Environment

Windows 7, JBoss AS 6, Richfaces 4.0.0 Final, JSF2

Affected Versions

[2.1.0]

[javaserverfaces]

Reported by luciano_deriu

[javaserverfaces]

luciano_deriu said: Forgot to mention when you use the war file attached hit the test.xhtml page... http://127.0.0.1:8080/Test/faces/test.xhtml

[javaserverfaces]

luciano_deriu said: Also i posted the issue on the Richfaces forumn a couple of weeks ago about this issue... http://community.jboss.org/message/591723#591723

[javaserverfaces]

luciano_deriu said: I also tested this issue with myfaces and the same issue exists so i created a ticket on their Jira... https://issues.apache.org/jira/browse/MYFACES-3106

[javaserverfaces]

jorelia said: I'm confirming this issue - Under rich faces, see the bug # RF-11694 and the workarounds proposed for CSS style and javascript resources.

https://issues.jboss.org/browse/RF-11694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12646453#comment-12646453

More over, if the included file contains some form elements, it seems that the form does not work well, I mean that submit button or any dynamic behavior do not do the expected behavior. We need to press F5 or force to reload the form twice. Then after F5, the form is fully functional.

Our conf is Websphere 8 - RAD 8 - JSF Mojorra 2.1.4 - Spring 3.0.6 Final - Use @Inject @Named @SessionScoped as annotations - Firefox 7.0.1 - Windows 7 (6.1 sp1)

[javaserverfaces]

jorelia said: A link to read, related to the ui:include with ajax: http://community.jboss.org/message/633448

[javaserverfaces]

@edburns said: I've converted the reproducer Test.war into a maven project, but I highly doubt it needs all the dependencies that were in the war.

I would appreciate it if the reporter could download the patch and tweak the pom.xml so it only contains dependencies truly needed by the reproducer.

Also, I've attached a screenshot of what I see. Does that demonstrate the problem?

[javaserverfaces]

@edburns said: I'm not at all sure that this is still broken. When I press the "Change View" button, I do see this text in the red box:

8<------ Loading resources via a dynamic ui:include doesnt work Resources aren't loaded if this page is part of a dynamic ui:include and its rendered via ajax. Refreshing the page works (F5). Tested with Richfaces and Primfaces libraries and they have the same result. This worked in JSF1.2. 8<-------

In addition to this, I do see a change in behavior when I press the equivalent of F5 in my system. The change is that some additional CSS is delivered that makes the first line appear with a grey background and also changes the font of the text in the entire page.

Is the fact that I have to press F5 to see this behavior the problem? Should it be the case that I should see this when I simply press "Change View"?

I'm going to mark this as Incomplete until my questions are answered.

[javaserverfaces]

luciano_deriu said: Hi Ed,

When you click "Change View" it should show the text with a Rich faces Panel around it (the grey background and border) but it fails to load the resources needed so it just shows plain text.

F5 works correctly and thats what the page should look like.

Sorry about all the included jar files in the WAR. The only ones i think you need are the richfaces ones and richfaces dependancies...

+        <dependency>
+          <groupId>org.richfaces.ui</groupId>
+          <artifactId>richfaces-components-ui</artifactId>
+          <version>4.0.0.Final</version>
+        </dependency>
+        <dependency>
+          <groupId>org.richfaces.ui</groupId>
+          <artifactId>richfaces-components-api</artifactId>
+          <version>4.0.0.Final</version>
+        </dependency>
+        <dependency>
+          <groupId>org.richfaces.core</groupId>
+          <artifactId>richfaces-core-api</artifactId>
+          <version>4.0.0.Final</version>
+        </dependency>
+        <dependency>
+          <groupId>org.richfaces.core</groupId>
+          <artifactId>richfaces-core-impl</artifactId>
+          <version>4.0.0.Final</version>
+        </dependency>    
+        <dependency>
+          <groupId>com.google.guava</groupId>
+          <artifactId>guava</artifactId>
+          <version>r08</version>
+        </dependency>
+        <dependency>
+          <groupId>org.w3c.css</groupId>
+          <artifactId>sac</artifactId>
+          <version>1.3</version>
+        </dependency>
+        <dependency>
+          <groupId>net.sourceforge.cssparser</groupId>
+          <artifactId>cssparser</artifactId>
+          <version>0.9.5</version>
+        </dependency>
+    </dependencies>

See here for more info... https://community.jboss.org/wiki/HowToAddRichFaces4xToProjectsNotBasedOnMaven

[javaserverfaces]

@manfredriem said: Closing issue out

[javaserverfaces]

luciano_deriu said: Manfred, why has this been closed?

[javaserverfaces]

@manfredriem said: Sorry, that was inadvertently done

[javaserverfaces]

@manfredriem said: Since Ed previously stated the issue is incomplete I will downgrade its priority to Major until the submitter gives the information requested by Ed.

[javaserverfaces]

luciano_deriu said: Thanks Manfred.

Hopefully my comment on the 2nd Feb is all that Ed needs from me, if its not then let me know.

[javaserverfaces]

jorelia said: We have prepared a little Web application that show the problem of refreshing a form by using ajax. In this case, the submit button does not work even if the form is refreshed. The form is included inside the index.hxhtml file.

So here is the detailed description of the case: We have one page that contains two forms. The first form contain a menus bar (ajax switchType) while the second contains a tabPanel (also in ajax switchType). When a user select a menu, we select the corresponding tab that contains a submit button. Once the tab is selected, the submit button does not work. We have to click twice for submitting.

1) If we move the menu bar inside the second forms, it is working. 2) If we set the menu bar in client switchType, selecting the menu doesn't do anything. 3) If we set the menu bar in server switchType it's working.

As the rendering is well executed, the submit button should works but is not whatever we set as render="@all, or any valid id".

Steps to reproduce:

1) Setup the application, read the readme.txt file from the zip 2) Once the index page is displayed, the tab "Items Management" is selected by default 3) Click one the first static tab "Tab S-#1" 4) From the menu, select the menu "items management" 5) Then click on button "New List" 6) A list of items should be displayed

But at the step 5, you have to click twice the button or to do F5 that refresh the whole page, it is like restarting the appl. from the beginning.

[javaserverfaces]

jorelia said: what's the status of the work? Did you still working on it? We got, again and again the problem with the version 2.1.7. I will attached a new demo. What we did as a work around is to preload manually the missing resource.

1) http://localhost:9080/NestedWeb2/index.html - Please, read the file readme.txt 2) Once the index page is displayed, select the tab "Items Management" 3) Enter a number and press the button ""New List" 4) A new tab is created with an items listing according to the number entered 5) Click on "Open" link, the content page is refresh 6) Select the sub-tab #2 to see the accordion object

To see the bug now: edit the template basePage.xhtml from \webContent\templates and remove the following lines and replay the application - The accordion object is not rendered properly. You must do F5 to force to reload the resource:

<h:outputStylesheet library="org.richfaces" name="accordion.ecss" />
<h:outputScript library="org.richfaces" name="accordion.js" />
<h:outputScript library="org.richfaces" name="accordionItem.js" />

[javaserverfaces]

jorelia said: The zip file of the web workbench project. Please, readme.txt file to setup the application.

[javaserverfaces]

@manfredriem said: Can you verify if it is still a problem against the latest 2.1 release?

[javaserverfaces]

jorelia said: Hello,

I've tried with the version 2.1.20 and the problem is still here. We need to load "manually" the richfaces ressources according to what we use in our page.

[javaserverfaces]

@manfredriem said: Can you reproduce the issue without RichFaces in the mix? If so could you send a zip file containing the webapp and the sources to issues@javaserverfaces.java.net

[javaserverfaces]

jorelia said: Well, in our case, it is a little bit difficult to do without because, this is precisely the richFaces resources which are not loaded. I can imagine that it can be any css ou js as long as there are under the form of resources ?, not embedded in plain text in our template. Resource have to be explicitely loaded to make the page "running" well.

We tried JSF 2.1.20 and it is worse for our application and we revert back to the version 2.1.17 - 2.1.19 seems working. However, our application is more complex and too big to be shipped and it is why we built the ITBH (Integration Technologies Bug Hunter) to validate the software stack. This application is small but have the same mechanism in terms of dynamic includes and also the same base page structure.

There is several issue related to dynamic include, I imagine that you have review all of them or it might interest you to know/read:

• https://jira.springsource.org/browse/SPR-10380 (you can download the ITBH from here)
• http://stackoverflow.com/questions/2118656/hcommandlink-hcommandbutton-is-not-being-invoked
• http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-790
• http://java.net/jira/browse/JAVASERVERFACES-2575
• http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-988
• http://java.net/jira/browse/FACELETS-296
• https://issues.jboss.org/browse/RF-12040
• https://issues.jboss.org/browse/RF-11694
• https://issues.jboss.org/browse/RF-11764

Shipping soon.... the ITBH... (on 20 Marh) but you can download the version you already have: NestedWeb2_RF_2016-Accordion.zip. This version runs with CDI (WeldGlassFish) and the version from the Spring JIRA 10380 is with Spring as DI but it is the same software and you can play with to test whatever you want. Better to take the Spring version, (jar are all already there) and copy/paste the "accordion" fragment from the NestedWeb2_RF_2016 to the Spring version.

Another way to test, is to go the basePage.xhtml and remove specific workaround for loading resources.

Well, or wait for me...

[javaserverfaces]

jorelia said: Ok, I'm back - My little child was sick. So, here is the steps to reproduce and miscellaneous information for the coming ITBH shipping.

1) There are 2 symptoms with the JSF 2.1.20 1.1) You have to perform a click twice on buttons, links,... to make it working. 1.2) Dynamic include does not include all resources needed by the XHTML fragment

For issue 1.1, the version 2.1.20 breaks the application. The application ITBH as is, is working well with the version 2.1.17.

For the issue 1.2, is still here from the "beginning". Datatable and other component that needs resources are not well rendered. See RF-11694 workaround.

2) The basePage.xhtml is a template page where we put the workaround

<!--             -->
   <!--  RF 11694 workaround        -->
   <!--  JSF JAVASERVERFACES-2016   -->
   <!--             -->
   <h:outputStylesheet id="datatableEcss" library="org.richfaces" name="datatable.ecss" />
   <h:outputScript id="datatableJs" library="org.richfaces" name="datatable.js" />
   <h:outputStylesheet library="org.richfaces" name="accordion.ecss" />
   <h:outputScript library="org.richfaces" name="accordion.js" />
   <h:outputScript library="org.richfaces" name="accordionItem.js" />

3) About ITBH 3.0 It was built in order to validate the technology stack and it is a way for debugging 3rd party materials as this application is much less complex to the real application. 3.1) Install the application- Please, see the readme.txt file at NestedWeb root folder. 3.2) ITBH works with GlassFish and WAS - Respectively v3.1.2 and v8.0.0.1 3.2) ITBH works also with Spring 3.0.6 or Spring 3.2.2 3.3) ITBH works also with RichFaces 4.2.3 or 4.3.1 3.4) ITBH works also with CDI from GlassFish, however you have to adapt the code but the code is already prepared to support it. (see readme file) 3.5) ITBH emulates a management system, it can be a client management, a items management. You begin by a search, then you obtain a list, and then you open the item or the file (client or article). From the opened item or client file, you might have other actions. 3.6) ITBH implements the concept of Single Page Application. Then, we have a single page and all user actions take place in this page. Page is refreshed by Ajax Request (JSF or RichFaces) by including dynamic XHTML fragments calculated on the user actions. 3.7) ITBH use mainly the tab component as the base component of the application. Some tabs are constructed statically (search), while some other are dynamics (Search result and task tabs).

[javaserverfaces]

jorelia said: Email Sent to: issues@javaserverfaces.java.net at : 2013-03-22 12:23 - #2020 - Manfred Riem - Screen Shots.

Hello Manfred Riem,

Here are some screen shots of the ITBH. Screen shots show you the behavior of the ITBH with dynamic includes with and without the workaround

Whithout the work around, the CSS and the javascript are not loaded. We have to press F5 in order to make the page working.

More over, with the version 2.1.20, button and links are not working anymore (It is a regression from the version 2.1.17 and 2.1.19).

It would be nice to have a way, to know what are the missing ressources and having a warning at the log or whatever it is necessary to have to help us.

[javaserverfaces]

jorelia said: Step to reproduce after the first installation

1)Home/Welcome Page: http://localhost:9080/NestedWeb/index.html 2)Click on English Link at the top right to switch in English if necessary 3)Click on Tab "Items management" 4)Enter a number for "Item quantity" input - Eg.: 10 - Mandatory field 5)Click the button "New list" ==> When you got the list, you see that the list is not well construct (See screen shots) ==> You have to press F5 in order to have a well constructed page (it is a workaround) ==> Another way is to use a plain "h:commandButton", instead of an ajax call ==> In our real application, even the button "newList" does not work. We have to retrofit to version 2.1.17 or 2.1.20. 6) From the listing, click on link "Open" 6.1) The link does not work even if the ajax call is started. But no action is performed on the backing bean. ==> You have to click TWICE to be OK -> Regression of JSF 2.1.20 ? with or without the workaround for RF ==> or Press F5 to reload ==> Then clicking on the link, it works ==> We got the same behaviour if you click on "Annul" button 7) From the listing, click on link "Open" 8) From the refreshed tab, a new set of tabs appear 9) Click on tab "Nested Static Tab #2" ==> Accordion component is not well constructed (See screen shots) ==> You have to press F5 to have a well constructed page ==> Screen does not work at all ==> If you switch to the tab "Nested Static Tab #1" you got the error of TypeError: RichFaces.ui.DataTable is not a constructor

Note: It is very important to stop and start the server before each change and to clear the navigator cache in order to get your changes and to be certain being not disturbing by cached data during your tests.

[javaserverfaces]

jorelia said: Here is the page structure to help you to understand the ITBH

---------templates/basePage.xhtml
            | - <ui:insert name="header" />
            | 
            |  <form>
            |      form for ajax status
            |  </form>
            | 
            | - <ui:insert name="content" />
            | 
            | - <ui:insert name="footer" />

---------index.xhtml (inherit basePage.xhtml)
            | 
            | 
            | - define header by <ui:include src="/fragments/header.xhtml" />
            | 
            | - define content
            | 
            |  |-----<h:form id="desktopForm">
            |  | 
            |  |---------<rich:toolbar> 
            |  | 
            |  |---------Quick Search panel
            |  | 
            |  |-------- <rich:tabPanel id="desktopTabs"
            |       | 
            |       | Static Tabs
            |            | 
            |            | 
            |            | -- dynamic include <ui:include src="panelOne.xhtml" /> (Search panel)
            |
            |       | Dynamic Tabs
            |            | 
            |            | -- dynamics include <ui:include src="#{tab.xhtmlFile}" />
            | it can be : listItem.xhtml or viewItem.xhtml
            |
            | -----</h:form>
            |
            | define footer <ui:include src="/fragments/footer.xhtml" />

[javaserverfaces]

jorelia said: We really appreciate if we can have more explanation about this JSG bug and also have some advises about how can we do to avoid such problems, good practices, practices to avoid and any information that help us. Because what we notice today, year after year, is the fragility of the UI. Changing JSF version or RichFaces version, breaks the software at the regularly basis. It's a lot of effort to follow 3rd Party updates. UI is more complex to build and more easier to break, we are not any more into the page to page flow, but instead of in one single page, one flow, one screen like the old Desktop application we built around the end of 1980 with GUI.

Thank you very much for your good willing.

[javaserverfaces]

jorelia said: I got a message from your server:

SYMPA sympa@javaserverfaces.java.net

Impossible to distribute your message for list 'issues@javaserverfaces.java.net' for the following reason :

Your message could not be sent because its size was over the maximum size allowed on list 'issues@javaserverfaces.java.net'.

For further information, please contact issues-request@javaserverfaces.java.net

[javaserverfaces]

jorelia said: email to issues@javaserverfaces.java.net ( Previous email has been still rejected....

(Attachment) Nested-SRC-Tiny (1081K)

2020 - Manfred Riem - ITBH - Source Again - Again - TINY at 2013-03-22 16:10

[javaserverfaces]

jorelia said: We have just tested the version 2.1.21 and it solves the problem of the step 6.1 describe above. Thx. If you can give us some information about the root cause of the problem, we will really appreciate. Best regards, JA

[javaserverfaces]

@manfredriem said: JA,

Does that mean we can close this issue? Note sometimes changes because of another issue will cause your problems to go away . For a list of changes for 2.1.21, see http://java.net/jira/secure/ReleaseNote.jspa?projectId=10204&version=16353

[javaserverfaces]

jorelia said: We found a new case when the step 6.1 does not work. Interesting, and if you can explain what is wrong, it will really help us.

If you change the code from panelOne.xhtml by the following code, the bug comes back. Then there is probably something wrong with the @form and/or with the execute attributes.

<!--            -->
   <!--  NEW LIST  -->
   <!--            -->
    <a4j:commandButton id="newListCmd"
           value="#{msg['common.command.new.list']}"
           action="#{panelOneController.doNewList}"
           render="@form"
           execute="searchItemsPanel"
           status="ajaxStatus" />&#160;

Old code was:

<!--            -->
 <!--  NEW LIST  -->
 <!--            -->
 <a4j:commandButton id="newListCmd"
       value="#{msg['common.command.new.list']}"
       action="#{panelOneController.doNewList}"
       render="desktopTabs,menuOpenedTabs"
       status="ajaxStatus" />&#160;

Results of tests

Following code, just add execute, it works.

action="#{panelOneController.doNewList}"
render="desktopTabs,menuOpenedTabs"
execute="searchItemsPanel"
status="ajaxStatus" />

Following code, just add render="@form", it does not work.

action="#{panelOneController.doNewList}"
render="@form"
status="ajaxStatus" />

Open aslo this bug at Jboss/JIRA: https://issues.jboss.org/browse/RF-12907

We test the fix on the real application, and it works. The problem seems to come from the "@form" for the "render" attribute. Replacing the @form by specific id, solve the problem but it is a workaround.

[javaserverfaces]

rogerk said: Is this in IE? I ask because there is an issue with form render targets in IE

[javaserverfaces]

jorelia said: Well usually, we did our test under Firefox. What we noticed also is that the behavior can be impacted by an upgrade to Glassfish version 3.1.2.2 instead of 3.1.2 only. Additional tests must be done. However, in production we run WAS 8.0.0.5 and we got the same issue.

We noticed also that running under IE, usually we got much more problem related to the refresh problem but if you can give us some information about why, I will really appreciate.

What we really want, is having at least a message from the framework, because, the request returns something, the action is not performed and we do not have any reason about this situation. It is very difficult to understand and debug because everything seems ok. So somewhere, the request is stopped but no reason is given to the user (I mean the developer).

What we noticed also and it is the most valuable information we found lastly about this strange issue: Imagine you call an action by ajax, in our case, mostly with RF, and the action render two ids like ID-A, and ID-B. From the rendered page (which is also a fragment), you have an ajax button to return to the previous page (I mean the fragment), you MUST render the same IDs, ID-A and ID-B. If you put @all or @form or any upper container it may not work in subsequent calls. You have to press F5 or press twice the link or the button because the first click does "nothing".

Page MUST have a certain amount of complexity because too simple cases does not trigger the phenomenon. We are not able to reproduce the case with a single page, with a single form, with a single path.

All effort we did until now to report various bugs, at JSF side and also at RF side related to this hot topic, is really to put a END, a true END that will put back this problem like an old nightmare. Having a clear message, understanding why it does not work, what we should avoid, what are the REAL framework limitation, what we should know from JSF and RF team/project.

Please do you have the # about IE bug/refresh ?

[javaserverfaces]

jorelia said: We have mavenized the project. Can be download at: https://issues.jboss.org/browse/RF-12907.

[javaserverfaces]

@manfredriem said: JSF 2 does not allow resources such as JavaScript or Cascading Style Sheets (CSS) to be added if the element requiring the resource is not initially present in the JSF tree. As such, components added to the tree via Ajax must have any required resources already loaded.

[javaserverfaces]

gus.ehr said: Hello Manfred.

Do you consider the dynamic resource loading for future releases of the JSF spec? Thanks in advance.

[javaserverfaces]

@manfredriem said: To clarify if you have a resource that is targeted using target="head" it is a browser limitation that does not allow you to dynamically include resources using Ajax.

[javaserverfaces]

luciano_deriu said: Hi Manfield,

I'm not sure if you can answer this but how was this possible in JSF1.2 using the jboss A4J library?

Luciano

[javaserverfaces]

luciano_deriu said: Sorry Manfred. My tablet changed your name

[javaserverfaces]

@manfredriem said: Well if you are not targeting it to the section it should work.

[javaserverfaces]

gus.ehr said: Thank you Manfred. I think that a dhtml script that appends a new child to the head tag should work, but I don't think this is supported by all browsers.

[javaserverfaces]

File: 20120202-1529-i_mojarra_2016_reproducer.patch Attached By: @edburns

[javaserverfaces]

File: message.tiff Attached By: @edburns

[javaserverfaces]

File: NestedWeb2_RF_2016-Accordion.zip Attached By: jorelia

[javaserverfaces]

File: NestedWebWithMenu.zip Attached By: jorelia

[javaserverfaces]

File: Test.war Attached By: luciano_deriu

[javaserverfaces]

Issue-Links: is related to JAVASERVERFACES-2838

[javaserverfaces]

This issue was imported from java.net JIRA JAVASERVERFACES-2016

[javaserverfaces]

Marked as works as designed on Wednesday, October 16th 2013, 9:31:54 am