I'm not sure what you mean by "not have the corret[sic] style applied". Properly marked up HTML should be independent of the style sheets.
If you're creating shoddy HTML such as:
then, yeah, you're going to run into problems.
But if you're using CSS and CSS selectors approriately, none of the HTML your tags emit should interfere with applying styles to that HTML.
Keeping the styling separate from the markup is the whole purpose of CSS in the first place.
[ January 12, 2006: Message edited by: Bear Bibeault ]
Some would rather tear out their eyes than write a line of HTML from within Java code.
One case where I like to do this is with HTML Select List Option tags.
I like to be able to remove all of the looping and branching from the JSP and replace it with one bean property (or custom tag).
This still leaves all the look and feel in the JSP but moves the logic in a bean where (I think) it belongs.
Other than option tags, however, I rarely ever build HTML from within Java.
Tag files are a nice compromise.
They give you the ease of an include with a lot of the power of custom tags.
[ January 12, 2006: Message edited by: Ben Souther ]
Favor HTML in Java handler classes over Java in JSPs
Sometimes cleanly separating HTML, JSP tags, and HTML-like custom tags from Java requires unnecessarily convoluted code. In these cases, you either include Java scriptlets and expressions in the JSP or put some HTML code in the Java tag handler class. I'd rather see a small amount of HTML code in the Java class than see Java, such as scriptlets and expressions, in the JSP. Since custom tag handlers are specific to the custom tags they implement (and not reusable outside JSPs), placing necessary HTML there is not troublesome. Sun's Java 2 Platform, Enterprise Edition (J2EE) Blueprints documentation discusses this issue further.
There are exceptions to this standard: if including one or two lines of Java code as scriptlets in the JSP solves the same problem that would require many more lines of HTML in the Java handler class, allowing Java code to exist in the JSP page might be prudent.
Originally posted by Ben Souther:
Tag files are a nice compromise.
Indeed, as of JSP 2.0, if a tag is going to be predominantly HTML I always use tag files.
Pre-JSP 2.0, I had come up with a "Poor Man's" tag file implementation that I had dubbed "taglets". There's an old JavaRanch Journal article on it in the archives.
That article that Ben linked to is from 2001, and JSP has changed a lot since then. I have a similar case that doesn't involve (much) HTML, but does raise the Java-versus-JSP question. We have a "cost" bean that needs to display like "23.47 (1.96 each)" or just "3.27" in some cases, and a retail bean that needs to display like "1.99 (37.3%)" with optional effective date. And these numbers appear in several different places in the application.
Now I originally had that formatting being done by a static method of a helper class written in Java, but while rewriting JSP+scriptlets to JSP+JSTL I found I couldn't make the scriptlet go away. So I changed that Java code to JSTL and used jsp:include to avoid the sin of pasting it into many places.
But I'm not convinced that was the best way to do it. The new all-JSP version is noticeably slower, for one thing, but also from a design standpoint it's a lot easier to write that finicky formatting code in Java. So I'm leaning towards bringing back the Java version and making myself figure out how to call it from JSP+JSTL. Any comments on that?
What you describe is exactly the type of usage I would use a custom tag for.
Originally posted by Bear Bibeault:
I find it interesting that you've noticed a performance drop after de-Java-izing your pages. I've never noticed any such issue.
Yes, well, it's also true that it's running in my IDE that could do with more memory. And I probably notice it more because JSPs are being compiled. In production it might well turn out to be insignificant.