0

Here is an simplified code sample, for what I'm trying to do. A text entered above in an inputTextArea is correctly displayed (with Line Breaks).

Below, in the dataTable, the same text is displayed without Line breaks.

<h:form id=myInputText#{id}>
    <h:inputTextarea id="myInputText" value="#{form.textWithLinebreaks}"/>
</h:form>

<h:form id=myOutput>
    <rich:dataTable 
        id="myTable"
        value="#{form.model}"
        var="f"
        style="table-layout: fixed;"
        styleClass="wordWrap"
        rows="5">

    <a4j:support event="onRowClick"
        action="#{action.selectText(f)}"
        immediate="true" reRender="myInputText#{id}" />

    <rich:column>
        <f:facet name="header">
                TextShouldHaveLineBreaks
        </f:facet>
        <h:outputText value="#{f.text}"/>
    </rich:column>

</rich:dataTable>
</h:form>

Things I tried to fix this:

<h:outputText value="#{f.text}" style="white-space: pre-wrap"/>

doesn't Change anything.

I also tried using a readonly inputTextArea as a workaound:

    <rich:column>
        <f:facet name="header">
                TextShouldHaveLineBreaks
            </f:facet>
            <h:inputTextarea value="#{f.text}" style="white-space: pre-wrap" readonly="true"/>
    </rich:column>

This doesn't help either, and will require lots of css to look just like all other columns.

Just in case this is relevant: My application runs on Seam with Richfaces 3.3.

Robert
  • 478
  • 6
  • 19
  • 3
    Should work: https://stackoverflow.com/questions/14647274/houtputtext-does-not-break-r-n-characters-into-new-lines check client-side what the differences are – Kukeltje Jan 08 '18 at 12:36
  • Which solution specifically do you mean, @Kukeltje? The css solution `style="white-space: pre-wrap"`worked fine for me in another project (uses Primefaces instead, and the relevant cell was in an `` element. I can't get this to work in this case. – Robert Jan 08 '18 at 13:37
  • Yes, and that is why I stated to check **client-side** in the html. See what css **is** applied... Is yours overridden...? – Kukeltje Jan 08 '18 at 14:01
  • The css is applied correctly - it is not overriden. And I get the same result with several browsers. – Robert Jan 08 '18 at 15:06
  • But is **other** css applied as well? Try disabling those and see if it makes a difference... – Kukeltje Jan 08 '18 at 16:01
  • I decided to use the `` Workaround in the end. It solves my problem and may even turn out to be useful. However, it still bothers me that I was not able to accomplish my original idea... – Robert Jan 11 '18 at 13:20
  • _"However, it still bothers me that I was not able to accomplish my original idea..."_ Well, there was a suggestion to see if **other** css was applied... You did not report back on that so that is up to you. And if `` works and `` does not, that is strange... – Kukeltje Jan 11 '18 at 13:55
  • I abbreviated the line in my comment, your's is the complete line. Sorry for the confusion! About the **other** css: I could not find anything that would interfere. – Robert Jan 11 '18 at 14:04
  • If it did not work, there 100% must be something that interferes... But since I don't have any richfaces project at hand, nor do I have the time (or need/urge/wish) to create one, I can unfortunately no help any further – Kukeltje Jan 11 '18 at 14:09

0 Answers0