Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>In JSF 2 (i.e. in Facelets), a template is a static piece of content that can have dynamic content composed within it.</p> <p>If you want to use a different template, firstly you have to point to a different page with a different URL path, then the different page can use a different template:</p> <pre><code>&lt;ui:include src="./header{$HeaderTemplateSuffix}.xhtml" /&gt; </code></pre> <p>Then headerABC.xml can have:</p> <pre><code>... &lt;ui:composition ... template="http://someserver/somefileABC"&gt; ... </code></pre> <p>and headerDEF.xml can have</p> <pre><code>... &lt;ui:composition ... template="http://someserver/somefileDEF"&gt; ... </code></pre> <p>Alternatively, you could abandon using templates against headers, and generate all header content dynamically (even including the static parts).</p> <p>Note: merging html header template back into the main template is NOT a solution to this problem, because it doesn't address the core challenge of the header template being <em>dynamic</em>.</p> <p>Hope that helps! Cheers :^)</p> <hr> <p>Note: it is possible to set the following in web.xml:</p> <pre><code>&lt;!-- Time in seconds that facelets should be checked for changes since last request. A value of -1 disables refresh checking. --&gt; &lt;context-param&gt; &lt;param-name&gt;javax.faces.FACELETS_REFRESH_PERIOD&lt;/param-name&gt; &lt;param-value&gt;0&lt;/param-value&gt; &lt;/context-param&gt; &lt;!-- Set the project stage to "Development", "UnitTest", "SystemTest", or "Production". --&gt; &lt;!-- An optional parameter that makes troubleshooting errors much easier. --&gt; &lt;!-- You should remove this context parameter before deploying to production! --&gt; &lt;context-param&gt; &lt;param-name&gt;javax.faces.PROJECT_STAGE&lt;/param-name&gt; &lt;param-value&gt;Development&lt;/param-value&gt; &lt;/context-param&gt; </code></pre> <p>HOWEVER, that is intended to serve a whole different purpose: to allow the developer to change any static resource on-the-fly and the JSF container will dynamically check for changes and load it during development. It is not an intention that you use this to simulate dynamic templating, and setting the above properties will have a negative impact on performance and secure behaviour in your Production environment.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    1. COThanks for your comments. You mention, that I can point to different external pages, yet in our case the header always comes from a given URL which provides us the current header which we have to use. So the URL is always the same, but its content can change over time. And you mention abandoning using templates against headers and generate content dynamically, but how? Again, the content is not in our hands, it comes from an external source providing us with a static html div block.
      singulars
    2. COThat might work. As long as you have different included file headerXXX.html for each case, you *might* be able to point to the same template URL (template="http://someserver/somefile") but you must ensure that it returns a different appropriate header template in each case. I'm not sure how you achieve an appropriate template while always reusing the same URL?? If you still have problems, trivial to fix: just introduce additional header template URLs on the server - if you need, they can be mapped to same resource (servlet/JSP) via web.xml.
      singulars
    3. COMaybe I haven't made myself clear enough - in our application there is only one header template, it never changes, all pages use the same header XHTML and never something else. But, the **content** of this header, which points to an external URL may change. So some CMS guy may decide to make the header green instead of white and it should just appear as such in our application, since all we do is including an external HTML DIV, where we know nothing about and just display it where the header should appear in our pages.
      singulars
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload