views:

738

answers:

1

Hi. The problem I have today is about dealing with HTML in an included JSP, with JSF. So here's the situation : I use JSF 1.2 by IBM on RAD with Websphere v6.1 I have a custom component (from the company layer) to use tabs. And in order to have a cleaner code, I just want to separate the JSF code of each tab in a separated JSP, this way, main.jsp :

<customTag:tabComponent>
<jsp:include page="/jsp/workflow/tab1.jsp"></jsp:include>
<div align="right">
    <customTag:switchToTab title="Next" tabValue="2"></customTag:switchToTab>
</div>
</customTag:tabComponent>

And my tab1.jsp :

<!-- Taglibs declared here -->
<f:verbatim>
<div id="myDivId">
    <fieldset>
        <legend>myLegend</legend>
        <h:outputText value="#{myBean.someContent}"></h:outputText>
        <!-- HERE are a lot of JSF components, selectItems, inputText... -->
    </fieldset>
</div>
</f:verbatim>

So the JSF components are processed, but HTML seems to be treated after and appears after, outside of the HTML generated by JSF. Something like

<table>
    <!-- generated content -->
</table>
<div id="myDivId">
...

although the table should be inside the div. I tried to use the <f:verbatim> tag different ways, and the only solution was to surround <div> and </div> by the verbatim opening and closing tags, which is dirty and makes Websphere going crazy.

Google did not find anything relevant, so have you guys already encountered the same issue? Is it possible to find a clean solution or do I have to include all my code inside the same JSP? Thanks in advance.

+1  A: 

First of all, that's recognizeable as legacy JSF 1.0/1.1 behaviour. The f:verbatim was indeed required to take template text into the JSF component tree. However, the f:verbatim is entirely superfluous since the new view handler of the 2006's JSF 1.2 which automatically takes any template text inside f:view into the component tree. Thus, are you really using JSF 1.2? Websphere 6.1 ships with builtin JSF 1.1 libraries and upgrading to 1.2 isn't as easy as just placing libs in /WEB-INF/lib.

As to your actual problem, you need to wrap only template text with f:verbatim, not worthfully JSF components. Thus, the following should work:

<f:verbatim>
    <div id="myDivId">
        <fieldset>
            <legend>myLegend</legend>
</f:verbatim>
<h:outputText value="#{myBean.someContent}"></h:outputText>
<!-- HERE are a lot of JSF components, selectItems, inputText... -->
<f:verbatim>
        </fieldset>
    </div>
</f:verbatim>
BalusC
Thanks again for your time.Maybe it's stupid but, how can I know the JSF version? I thought it was 1.2 but you should be right, because the company shipped the entire environment and I didn't change anything so it's still JSF 1.1 I guess.About your solution : I already tried it, and did it again after your answer, and it works the first time I start Websphere, but after "republish" I got a "republish failed" (not sure about the exact translation, french RAD environment) because <fieldset> is missing. So I have to restart WS each time to make it work.(BTW impressive profile!)
Baztoune
If you was using JSF 1.2, you would have seen that in the startup log (which was lacking in 1.1). Also, you would have been able to use 1.2-only classes, such as `ValueExpression` or 1.2-only methods such as `Application#evaluateExpressionGet()`, or 1.2-only tags such as `f:setPropertyActionListener` and `h:panelGroup layout="block"`. As to the "republish failed" error after a publish, I'd suspect a dirty classpath. Ensure that there are no version collisions in libraries throughout the entire classpath (which unfortunately involves a *lot* of paths in Websphere, I can tell from experience).
BalusC
I didn't find anything weird in the classpath, but the solution I found is "enable publishing when the application contains errors" in RAD so it doesn't complain about "crossing tags" during publication. The output is still correct so It's ok (I will post here later if I find something more, for others). Thanks.
Baztoune
Websphere/RAD **is** weird ;) Glad you got it to work.
BalusC