0

I have some code that uses <h:outputText> to conditionally render groups of JSF elements. Examples:

<h:outputText rendered="#{authorization.admin}">
  <h:outputText value="#{msgs.someinfo}" />
  <h:inputSecret value="#{usermanager.password}" />
</h:outputText>


<h:outputText rendered="#{contactmanager.editAction}">
  <li>
     <label for="name"><h:outputText value="#{msgs.nameinfo}" /></label>
     <h:inputText id="name" value="#{contactmanager.name}" />
     <h:messages for="name" />
  </li>
</h:outputText>

The code is on glassfish 2.1.1 which has the MANIFEST.MF in jsf-impl.jar looking like this (I'm not sure whether it actually uses this jar or some other one for JSF):

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.0
Created-By: 1.5.0_19-b02 (Sun Microsystems Inc.)
Specification-Title: JavaServer Faces
Specification-Version: 1.2MR2
Implementation-Title: Mojarra
Implementation-Version: 1.2_13-b01-FCS
Implementation-Vendor: Sun Microsystems, Inc.
Implementation-Vendor-Id: com.sun
Extension-Name: com.sun.faces

I'm trying to move to glassfish 4 which has some version of JSF 2 or higher.

All the hundreds of instances of this construct worked on the old glassfish, but they no longer work on the new one - they are replaced with nothing, regardless of what the rendered attribute evaluates to. Why?

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
Dog
  • 7,707
  • 8
  • 40
  • 74
  • 4
    AFAIK you should not use `` to wrap the content you want to render or not. Use `` instead. Refer to http://stackoverflow.com/q/3713468/1065197 for more options. – Luiggi Mendoza Nov 08 '13 at 21:41
  • @LuiggiMendoza: But the construct seems to be uncontested [here](http://stackoverflow.com/questions/17685804/which-properties-in-a-jsf-backing-bean-can-be-set-by-a-user) – Dog Nov 08 '13 at 21:53
  • I don't understand what you mean. – Luiggi Mendoza Nov 08 '13 at 21:55
  • @LuiggiMendoza: `` was used the same way there, and nobody said not to do it. – Dog Nov 08 '13 at 21:57
  • Then looks like `#{authorization.admin}` always returns `false` (similar with other beans). There's not enough info to reproduce the problem. I would recommend creating a new page and try to isolate it to find the real culprit. By the way, GlassFish 4 uses JSF 2.2 by default. – Luiggi Mendoza Nov 08 '13 at 22:03
  • That's a weird way of doing things... – Simon Arsenault Nov 08 '13 at 22:12
  • @LuiggiMendoza: "they are replaced with nothing, regardless of what the rendered attribute evaluates to.". In other words, replacing it with rendered="true" doesn't even work. – Dog Nov 08 '13 at 22:14
  • Again, *there's not enough info to reproduce the problem*. Did you try to isolate the problem or just keep complaining against an incomplete figure of the problem? I already made a test with `rendered="true"` and works with no problem, so your real problem lies elsewhere. – Luiggi Mendoza Nov 08 '13 at 22:17

1 Answers1

0

Indeed, since JSF 2.0, children of UIInput and UIOutput are by default not anymore rendered. This is the consequence of fixes for issue 1154. In Mojarra 2.x, you can still turn it back on via a web.xml context parameter:

<context-param>
    <param-name>com.sun.faces.allowTextChildren</param-name>
    <param-name>true</param-name>
</context-param>

See also the Mojarra 2.0.0 release notes.

It's however more recommended to instead use <h:panelGroup> or <ui:fragment> for conditional rendering of blocks as the <h:outputText> is just the Wrong Tool™ for the job.

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • 1
    I couldn't use `` because it creates a `
    ` or `` in the HTML, which changes the web browser's behavior. [This](http://stackoverflow.com/questions/3713468/alternative-to-uifragment-in-jsf) post is saying `` doesn't support the `rendered` attribute? So far I've started converting the ``s to `` and it's working.
     – Dog Nov 11 '13 at 15:19
  • The `` does **not** create a `
    ` or `` as long as you don't specify attributes which should end up in client side. As to the ``, it certainly supports the `rendered` attribute, please re-read that post. It's simply a documentation bug, not a logic bug.
     – BalusC Mar 10 '21 at 09:44