Conditional wrapping with tag

[Zhomart Sadyakas]

Hi everybody, I am not able to find some "nice" way of doing some "conditional wrapping with tag". Also this problem could be solved with render attribute which does not prevent content being rendered.

In "JSP way" it could be done like this:
<c:if ...><b></c:if>
Content
<c:if ...></b></c:if>

Hope somebody knows,
thanks in advance

[Tim Holloway]

The JSF way is like this:

<h:outputText rendered="#{myBean.renderMe}" value="content"/>

For more complex construct, use one of the container tags. For example:

<h:panelGrid columns="1" rendered="{myBean.renderMe}">
  <h:outputText value="Caption line"/>
  <h:panelGroup>
     <h:outputText value="Left Part">
     <h:outputText value="Right Part"/>
  </h:panelGroup>
</h:panelGrid>

Use of raw HTML or free text in JSF View definitions is not good practice. In earlier versions of JSF, the output could be pretty awful-looking. In modern-day versions, the output will usually format better, but it's still bad practice.

[Zhomart Sadyakas]

Tim Holloway wrote:The JSF way is like this:

<h:outputText rendered="#{myBean.renderMe}" value="content"/>

For more complex construct, use one of the container tags. For example:

<h:panelGrid columns="1" rendered="{myBean.renderMe}">
  <h:outputText value="Caption line"/>
  <h:panelGroup>
     <h:outputText value="Left Part">
     <h:outputText value="Right Part"/>
  </h:panelGroup>
</h:panelGrid>

Use of raw HTML or free text in JSF View definitions is not good practice. In earlier versions of JSF, the output could be pretty awful-looking. In modern-day versions, the output will usually format better, but it's still bad practice.

Thanks for the answer but you got me wrong.
in case rendered would resolve as false component would not be shown as well as it's content. But I need only conditional rendering for tag itself without affecting it's content display.
Example, if condition true, would result in:
<span>content</span>
If condition resolved to false:
content
(without tag surrounding it). Some kind of rendered attribute but which will still render inside content of the tag despite of rendering value.

[Zhomart Sadyakas]

I know that using html directly is bad practice, but some times I have no choice, because I need to optimize page for search engines.

[Tim Holloway]

Zhomart NoLastName wrote:I know that using html directly is bad practice, but some times I have no choice, because I need to optimize page for search engines.

The output of JSF is 100% pure HTML regardless. No JSF tags will be visible to search engines. So if you want search engines to key on particular layout quirks, you need to worry about what comes out of the JSF View rendering process, not what goes into it.

[Zhomart Sadyakas]

Ok, for example: I need <b> tag, in the final html output. Which JSF tag could result in that tag?

And guys, I still couldn't find a way to conditional content surrounding...

May be there is a tag, that would allow you to specify somewhere in attributes, which html tag it would be rendered as finally? It would solve all my issues....
Like: <some_pref:some_tag use_tag="b">content</some_pref:some_tag>
and in other scenario: <some_pref:some_tag use_tag="span">content</some_pref:some_tag>
and we can do: <some_pref:some_tag use_tag="#{bean.tagToUse}">content</some_pref:some_tag>

Because otherwise, I would need to write same "content" twice or more times.... That would be really bad idea for each time I face this problem... I am just started with JSF and more than sure, it should have solution for that basic stupid problem...

[Tim Holloway]

You're working with some really -up search engines if they key in on <b> tags. What do they do when someone uses CSS to do their boldfacing, instead?

If you absolutely must put explicit HTML into a JSF page, the recommended way to do it is with the use of the <verbatim> tag. Although in the case of wrapping tags, that can be a problem, since <verbatim></b></verbatim> is not a valid construct, for example. You could use the outputText tag with HTML escape turned off, however.

JSF actually isn't intended to be HTML-only. By simply switching rendering engines, a JSF View should be renderable as WAP or PDF, for example. Except that neither of those forms handles HTML, and that's one reason why mixing in HTML isn't recommended.

JSF is designed to provide a high-level abstract framework, not an element-by-element HTML page formatter. You can use constructs such as HTML-escaped outputText elements for small variances, but if the goal is to interact with an inflexible third party, JSF may be a bit like using a hammer to drive screws. For that kind of stuff, a straight servlet or JSP would be more appropriate.

[Zhomart Sadyakas]

Tim Holloway wrote:You're working with some really -up search engines if they key in on <b> tags. What do they do when someone uses CSS to do their boldfacing, instead?

it's just an example that came first in my mind, if you will differentiate some keywords with styled span tag, it will not make any difference for the se, since search engines do not parse css. Particularly b tag is not making much difference, but if you wish, we can consider <h1>.

Tim Holloway wrote:If you absolutely must put explicit HTML into a JSF page, the recommended way to do it is with the use of the <verbatim> tag. Although in the case of wrapping tags, that can be a problem, since <verbatim></b></verbatim> is not a valid construct, for example. You could use the outputText tag with HTML escape turned off, however.

I said, that I know it's not recommended, why everybody try to mention this, it's not a secret at all.... I am not coding stuff will be reused by somebody, moreover even by me, and that stuff is very narrowly targeted to html, so what's a problem with not having alternative like PDF? Sometimes you really need that "low level" control, in order to do it very precise, and not in common way. Good idea, about switching off escape tag =))), thanks a lot, now it's best solution that I have =), but anyway, I think it's not usable, since it will give you very high probability of forgetting to close that tag....

Tim Holloway wrote:JSF actually isn't intended to be HTML-only. By simply switching rendering engines, a JSF View should be renderable as WAP or PDF, for example. Except that neither of those forms handles HTML, and that's one reason why mixing in HTML isn't recommended.

I know thanks.

Tim Holloway wrote:JSF is designed to provide a high-level abstract framework, not an element-by-element HTML page formatter. You can use constructs such as HTML-escaped outputText elements for small variances, but if the goal is to interact with an inflexible third party, JSF may be a bit like using a hammer to drive screws. For that kind of stuff, a straight servlet or JSP would be more appropriate.

I am not using JSP and Servlets, because I really need that high-level abstract framework, since "stuff" that I am working on is really "huge", and nice composition approach will save me much time and afford... But, I really don't need that "HTML independence", I need to that "precise control"...

I am thinking about declaring new tag, that will be rendered as specifiable.... But, still sure that it's already done many times by others... Just don't want to invent wheel.

[Tim Holloway]

OK, h1 makes more sense. I've done stuff like that, although not recently:

<h:panelGrid id="pageTitle" class="h1" rendered="#{myBean.renderTitle}">
   <h1><h:outputText id="pageTitleText" value="#{mybean.pageTitle}"/></h1>
</h:panelGrid>

This can be reasonably expected to render as a div containing an h1, and I expect any decent search engine to support that, since I'd do the same thing in raw HTML so that I could do things like use CSS-based text centering, margins/borders, background coloring, and so forth. No guarantees, however. It could also render as a 1x1 table containing an H1, but that, too has been done in raw HTML. There is a JSF core tag that's very explicitly defined in the JavaDocs to render as a div or span if it's truly important, but I'd have to RTFM to recall which one.

There are, I believe, some third-party taglibs that may support more JSF-centric things like "<xh1>" to bridge the gap. But if it's 100% control you want, use the "verbatim" tags and code the raw HTML directly in there.

[Zhomart Sadyakas]

btw, what is the purpose of verbatim?

[Tim Holloway]

Zhomart Sadyakas wrote:btw, what is the purpose of verbatim?

JSF doesn't simply pass stuff along the way that JSP and simple HTML do. Instead, a tree is constructed from the View source and then used to render the output.

In JSF1, this lead to problems, because the non-JSF stuff ended up "outside the tree", and would render in unwanted locations (if at all). The "verbatim" tag allowed page source test to be captured and held "inside the tree" at the proper location so that everything rendered at the right time.

In later releases, JSF has handled the problem of free-floating (non-JSF) source text much better, but the "verbatim" tag is still useful since it allows you to explicitly direct that the elements in the body of the tag are non-JSF stuff that needs to be handled properly.

[Zhomart Sadyakas]

thanks =)
btw, that views, I don't clearly understand it.
As I understand: view Is tree of components that is being stored for some time, after some JSF page was visited with GET query.
And view is only restored when postback(Post) query is done.
Could you clarify me following:
1) What could be the root of the view? Root tag of every accessible from outside JSF page?
2) If same view accessed for two times, sometimes users press F5 when they are submitting some values, which results in duplicate actions, would be it handled with just giving away previous response? (not performing action again).
3) What components are tree nodes, every JSF component?

[Tim Holloway]

I'll try and answer as much as I can. Some of this stuff I'd have to RTFM to refresh myself on, since for the most part I simply rely on it to "just work".

I use the term View in the MVC sense to refer to the JSF definition and rendering of the page. I say "View" rather than "page" since it's more abstract and (hopefully) avoids confusion between the actual source JSP/xhtml and what ends up on screen. View means the abstract when I talk about it, not the details.

Incidentally, a popular misconception is that a backing bean is an MVC "Controller". It isn't. It's a Model with an option for business logic capabilities. JSF's primary controllers are the FacesServlet and the tag implementations. The only user-written controller code is things like listeners, which are more the exception than the rule - at least in well-designed apps.

When you make an initial View request, the view component tree is constructed, populated from backing beans (if required) and then rendered to produce the HTML that will be the web page going out on the response datastream. When the user initiates a postback (form submit), the received form data (including some additional invisible JSF data) is applied against the View tree to perform the various JSF lifecycle phases. On the Render Response phase, the updated View is again rendered into HTML and sent out with the new response. AJAX-based functions work in basically the same way, although usually only parts of the data are affected.

Refresh (F5) is actually just a request to the browser to resubmit the last GET/POST request. JSF doesn't (can't) tell the difference between a refresh request and an ordinary one. There is supposed to be some sort of protection against "double-clicking" a submit button in recent JSF releases, but I'm not well informed on that (and a double submit isn't the same thing as Refresh, anyway).

The View Root is constructed first, and the tree is then fleshed out based on the view component sources supplied. In the most basic case, an initial request comes in as an HTTP GET, the FacesServlet deconstructs the URL to find the View Template (JSF/xhtml resource "file"), and the template is parsed (compiled) to fill in the various child nodes of the View tree. For View-to-View navigation, the same general process occurs, except that the location of the new view template is supplied as part of the navigation process.

The View tree is used to produce one and only one HTML web page. When you go to a new page, a new View tree is constructed containing the elements that render that new page.

Basically every JSF component is in fact a view node. Not every JSF tag will compile to product a view node, and in some cases, one JSF source tag may result in several nodes being generated, especially these days, when the appearance of a custom control may inspire the framework to add nodes containing JavaScript and/or style definitions at the top or bottom of the page.