JSF div tags

[greeshma silam]

Hello All,

Can we use regular HTML 'div' and 'span' tags in JSF ?

[Brendan Healey]

You can, or you can use h:panelGroup with/without layout="block" to generate div
& span tags respectively. It's important to use h:head & h:body, but I don't know
any reason why you can't use div & span, but I bet someone comes up with
something!

[Tom mmeke]

The whole idea of JSF is to avoid using raw HTML, so JSF can build its own tree of components.
If you use

h:outputText
h:panelgroup (with embedded h:ouputText)

JSF will decide whether to generate this into span or div.
In general, just use JSF tags, and don't worry about what the generated HTML code will look like.

There is one exception though; in your template you can use html tags to design your page.
(eg. make a menu on the left or top)

[Brendan Healey]

The thing is that the use of standard html tags works as we all know, because of
this line in any facelets page: xmlns="http://www.w3.org/1999/xhtml". Does it
work by accident or design? I'm pretty sure it's by design, and a useful feature
it is too. It's certainly a lot less typing to use <hr/> than <h:outputText escape=
"false" value="<hr/>" every time you want a horizontal rule, or line break. Given
that it works now I can't imagine this functionality could ever be removed,
breaking thousands of applications at a stroke.

Here is a similar discussion for reference:

http://stackoverflow.com/questions/5375821/when-should-i-use-jsf-components-and-when-should-i-use-html-tags

Regards,
Brendan.

[greeshma silam]

Thanks for your response. That really helps, I will try to use JSF tags as much as I can in my code and avoid HTML tags, but I was wondering h:panelGrid renders <table></table> and I have seen it being used in many examples such as even login page that has only 2 form fields ...are they being used for styling ...I think it is better to use CSS to align the form fields ...correct me if I am wrong ...Please find the example below

<h:panelGrid columns="2" >
Name:
<h:inputText/>
Password:
<h:inputSecret id="password"/>
</h:panelGrid>

Thanks

[Brendan Healey]

I think using a panelGrid to align form fields is the way to go, potentially with additional
CSS to get things just right. You probably want either multiple h:message tags or a
single h:messages tag for error reporting in there somewhere also. I tend to use a
single h:messages tag as an error window, I find that easier to manage.

[Tim Holloway]

<hutputText escape="false" value="<hr/>"

AAARGGGHHH!

That's just plain nasty. If you MUST do stuff like that, use the f:verbatim tags, at least! Although as far as it goes, CSS is supposed to be able to do all that stuff for you these days, and is the preferred approach even in raw HTML, much less in JSF.

No. It's bad practice to mix JSF and raw HTML. JSF uses an abstract rendering mechanism to produce a View from a 2-dimensional data structure. Mixing in raw HTML adds caltrops to the process because HTML doesn't get inserted naturally into the JSF View tree. And, in fact, in JSF 1.1, the HTML had a bad habit of falling out of the page layout and landing in inconvenient (and ugly) places. Also, if you ever find it necessary to switch on an alternate renderer, such as PDF or WAP, that raw HTML is going to ugly-up the output, since JSF will naively pass it through, even though it doesn't work on those platforms.

One of the major complaints about HTML, in fact, was that it incoherently mixed display format and display functionality. CSS was designed to minimize that problem. JSF takes the separation even further. Although some of the JSF constructs can be a bit awkward (who hasn't cursed the lack of a decent "colspan"?) nevertheless, for the visible part of the page, there's really no need to embed raw HTML at all. For people who prefer not to diddle around with CSS for things like spacing and line drawing, there are even extension tags such as the RichFaces "spacer" and "separator" tags.

Just because HTML is part of the xhtml schema doesn't mean that it's a good idea to use raw HTML on JSF. While in certain cases, you have no choice, such as the HTML header elements, which have little direct JSF support, xhtml not only defines HTML elements, it also enforces XML formatting (and hence validation) on JSF.>

[greeshma silam]

Thank you all for clarifying my questions, So I conclude and will practice not to use HTML tags in JSF pages unless necessary.

I have a requirement to divide the screen into 2 columns and each column has some form fields. I was using divs and CSS float to style the form fields and align the fields. I was wondering if I can use h:panelgrid to divide into 2 columns but I am afraid it will render the table tags ....I am not sure if I have to use CSS or panelGrid

Thank you All.

[Tim Holloway]

Please don't tell me you too are under some silly Pointy-Haired Boss Dictate that Tables Are Verboten. That whole idea had a limited justification on a limited platform for a limited period in time and has no place whatsoever in JSF. Do they also mandate that the JVM not generate the MULS instruction or use Register 5? That's about what the div/table controversy amounts to in JSF. JSF is not an HTML generator, it's an application framework designed for high-level design and implementation of Enterprise Technology, and if/when it chooses to generate tables it's not going to be doing so for bad reasons. They did after all spend a lot of time getting that stuff right.

OK, give me a moment to wipe the spittle off my keyboard (second time today ).

Now then.

In JSF2 Facelets are standard, and they are easily added to JSF1. Facelets provide a very good tiling framework. You can (and I do) layout a tiled page with things like a top masthead, sidebar menu, bottom zone (good for displaying copyright notices and so forth). The panelGrid is a natural fit for that. And yes some implementations will generate those tiles using an HTML table as the compiled JSF. That's because the HTML table construct is a good fit for stuff that arranges itself that way - better, in fact than juggling a whole bunch of independent divs and forcing them to line up like a table. However, as I said, what gets generated is JSF's business and no practical concern to the high-level programmer unless he/she is either A) encountering browser-specific problems or B) being constrained by a micro-manager. The rest of us can spend our time on more productive pursuits.

[greeshma silam]

Thanks got it

Please clarify if I can go with panelgrid with two columns when creating a form to align all the form fields instead of creating CSS to align the labels and the the textfields

Last Name : John
First name : Smith
Address : 123
Line 2 : 234


Thanks

[Tim Holloway]

JSF does not attempt to be a styling framework. It figures that CSS is already there, why duplicate things?

Instead, JSF's more complex elements add specialized ways to apply CSS support to the abstract high-level constructs that it uses in place of "brute-force" low-level HTML.

Unless I misread, you're looking for a tabular display where the left-hand column is a fixed-width area containing labels and the right-hand column contains values. The panelGrid control can do this easily. Use the "columnClasses" attribute to specify the names of the CSS style classes that define the format of the left and right columns. For example;

.xcolLeft {
   font-weight: bold;
   text-align: left;
   width: 180px;
   white-space: wrap;
}

.xcolRight {
  font-weight: normal;
  text-align: left;
}

I let the width of the right-hand column float, so unless the style for the panelGrid itself indicates a width, the panelGrid's width will vary with the text content. You can do whatever you prefer.

The net effect is going to be pretty much the same as an HTML table with a few exceptions. Most notably, panelGrid does not use explicit row and column delimiters (<tr>, <td>). So you can't apply a custom style to a single cell except by making that cell be a rectangular construct itself with its own styles, such as a 1x1 panelGrid, Also, in most cases, you can't just simply slap in an ad-hoc style attribute, you have to use a named class. But that does make it easier to "skin" pages.