• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

XHTML doctypes gets replaced by HTML5 doctype

 
Ranch Hand
Posts: 47
IntelliJ IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello,

I am working on a university jsf project. We have to implement a simple login system.

However, my problem is, that the XHTML doctype in my xhtml file gets replaced by the html5 doctype. This is a snippet of my code:


But when I view the source code in either Firefox or Internet Explorer, I get this:


Why does this happen? I'm confused right now...
 
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
OK, I know it's a training exercise, but no matter how many books do this, using a user-designed security system in a webapp is an absolutely horrible thing to do. Probably 90% or more of the web apps I've seen over a long and evil career (JSPs hadn't even been invented when I first used J2EE) that incorporated DIY login systems could be broken by non-technical personnel in 10 minutes or less. And that includes systems designed by "experts" and used in financial institutions and even military apps.

J2EE/JEE defines a standard container-managed authentication and authorization system. It was designed by full-time security experts, vetted by more experts, and has been in operation essentially unchanged since the year 2000, give or take. And I've never heard of anyone exploiting it.

In almost all cases, in real-world web applications, this is the security/login mechanism I recommend that people use. Life's too short to explain to customers and shareholders why critical customer data is now residing in Ukraine.

So, for the protection of users yet unborn, I plead with your professors to pick some more innocuous example for a simple JSF webapp.

OK, so much for the

Here's where your problem lies. The xhtml resources in your JSF webapp are NOT actual page prototypes. Technically, xhtml is a standardized XML format for HTML documents. Straight HTML has some loopholes in it that make it very bad for machine parsing. What's actually in the xhtml files is what's known as View Template Language (VTL) or sometimes as View Definition Language (VDL). In JSF version 2 and higher (and properly turbocharged version 1, but that's a long time ago), these view templates are compiled to product the internal JSF component tree that corresponds to the web page.

It's the component tree that's rendered to produce the actual HTML output sent to the client. And originally, JSF was intended to support custom renderers, so that alternatives to HTML were also possible. Back then, when mobile devices were less capable, for example, there was an XML format designed for mobile UIs. In theory, also you could render PDF pages with submittable forms on them. And so forth. This is why I discourage the use of raw HTML on View Templates. You render a PDF from a template with a "<div>" on it, and the document text is going to include the "<div>" as verbatim text.

JSF version 2 is more speciically targeting HTML, but it's still good practice to use JSF constructs in place of raw HTML where possible.

So, in brief, the doctype on your VTL (xhtml) file is processing information for the VTL compiler. It instructs the compiler (and many text editors) of the required format for valid xhtml. The doctype on your output page, on the other hand, is generated as part of the JSF page rendering process, and has no relation to the input doctype.
 
Christian Wansart
Ranch Hand
Posts: 47
IntelliJ IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for your long answer. I appreciate it!

I tried to re read it a few times and tried to understand it. So, you say I should not use html in my view files? But what should I use?

I mean, xhtml ist meant to contain xhtml, isn't it?

Regrards,
Christian
 
Tim Holloway
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
xhtml allows HTML constructs in View Templates, but as I said, I don't encourage it.

Specifically, avoid stuff like <p>, <br>, <hr>, as the same effect can be done with CSS. Likewise the <ul>, and <ol>, and <li> constructs.

A <div> and a 1x1 h:panelGrid are approximately the same. A <table> would be best rendered using h:dataTable, or in some cases, ui:repeat.

There are a number of reasons why raw HTML isn't a good thing to do. One of them, as I mentioned, is that if the xhtml View Template is used to rended a non-HTML document such as a PDF, then the HTML tags will be passed through verbatim and result in very ugly output.

An even more important reason is that JSF doesn't account for HTML elements when JSF tags process their children. This construct:

Should not be counted on to create 3 columns like "Hello", "JSF", "World" in a table, but rather a 3 column table with only 2 columns filled and where the location of the word "JSF" is unpredictable, because panelGrid organizes by JSF elements.

In JSF vesion 1, in fact, a special "escape" tag was needed to insert HTML safely into a JSF page. JSF 2 isn't quite as sensitive to this, but it's still a good idea to use the f:verbatim tag when in doubt.
 
Christian Wansart
Ranch Hand
Posts: 47
IntelliJ IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the fast answer. Ok that makes sense. I didn't use any pure html tags in my work so far.

 
Greenhorn
Posts: 22
Python Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I'm not as experienced as Tim, but I'd like to add my two cents since I disagree with some of the suggestions in this thread.

On the one side, JSF's VTL has the advantages of simple nesting and easy to use, rich component libraries. As XML it's also validate-able. This is as far as the pros go.

On the other side, there are many disadvantages: the learning curve is extremely steep, as new developers need to not only know XHTML, XML and the used components, possibly extended by PrimeFaces or RichFaces. They also need to learn your company's custom components and at least some of the converters, filters and backing beans. This is a huge drawback for people used to HTML or simple templating languages. This is also the point at which I disagree with Tim on preferring JSF elements over plain HTML. For HTML you easily find many good web devs and designers. These people are punished for their skills, as JSF's VTL misses to re-use their knowledge. You see that in a different handling of IDs (JSF concatenates IDs of some(!) parents and children), the use of a "class" attribute, which is not to be confused with "styleClass", and many other things like that.
Many times, when starting a new project, you get a static page in HTML from a designer which you need to make dynamic for a project. In such cases it doesn't make any sense to replace the all the well-known (by people and browsers), semantically richer and most probably shorter HTML code with JSF XHTML unless necessary.

As for the argument with PDF generation: the conversion of XHTML to PDF never really worked well and almost nobody ever used it. Why would you invest time and money in making your pages multi-format capable if that will most probably never be of use?

Just my two cents.
Hubert Grzeskowiak
 
Saloon Keeper
Posts: 15484
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Holloway wrote:Specifically, avoid stuff like <p>, <br>, <hr>, as the same effect can be done with CSS. Likewise the <ul>, and <ol>, and <li> constructs.


Can you elaborate on this a bit, Tim? Don't these tags convey semantic information, rather than just style?
 
Tim Holloway
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:

Tim Holloway wrote:Specifically, avoid stuff like <p>, <br>, <hr>, as the same effect can be done with CSS. Likewise the <ul>, and <ol>, and <li> constructs.


Can you elaborate on this a bit, Tim? Don't these tags convey semantic information, rather than just style?



Actually, these particular tags are not merely something I don't recommend for VTL, they've been disparaged for years by CSS purists. And they're not purely semantic, as each of them also has a visual characteristic. The drive to separate format from semantics is older and wider than JSF, and in fact, it's one of the premier reasons why CSS was developed in the first place.

So PDF rendering "was a failure". Debatable point, as PDF forms have become pervasive in some circles, but the point is that JSF wasn't designed merely to render as HTML, but to operate with plug-in renderers. Back when it first came out, for example, there was an XML markup language (WML) designed for what passed for "smart phones" at the time. If you'd defined your View Templates as pure JSF, you'd just need to swap renderers and perhaps map some different templates to the backing beans to accomodate alternate screen sizes. But because WML was NOT HTML-compatible, any HTML tags in the View Template would be passed straight through and make ugly screens. WML is now essentially extinct thanks to smartphones with enough power to handle full HTML/CSS/JavaScript, but why hamstring future platforms? What if a demand pops up for Braille or voice rendering? Or a VR markup language? It's like opening up your cornflakes and mixing in sawdust for the extra fiber. Maybe other people in the house don't want sawdust. It's easier to mix in than to remove, and once you go down that road, you might as well start coding scriptlets while you're at it.

JSF's VDL is actually simpler and more rigorously defined than HTML is, while concurrently being more expandable. If necessary, you can pretty much do functional sites using only the f and h tagsets that make up JSF's core and I have certain projects that deliberately do so. Many shops do prefer to augment them with third-party and/or custom tagsets, but there's also a lot of support for those third-party tagsets, including this very forum.

HTML's ubiquity isn't that much a virtue. A lot of people "know' HTML in the same way that they "know" MS-Word or "know" BASIC. Meaning that they can wield it like a blunt instrument and end up being more hindrance than help in the long run. HTML has a lot of cruft left over from pre-CSS days, where JSF expects CSS to be the sole determinant of colors, fonts, text alignment, [i]etc.[/] The relatively large number of defined elements (including the discouraged ones) also means that shop standards can vary widely. HTML is also the Assembly Language of web page markups. JSFs tags were defined as more abstract entities. So for example, a panelGrid doesn't require table, thead, th, tr, td and footer tags, it only requires the panelGrid tag, annotated by f tags for the headers and footers. And no explicit cell tag definitions (tr, td) at all. Also, a panelGrid is semantically different than a dataTable, so when automated scanners get turned loose on the templates, it's easy to tell whether a given 2-dimensional control has repeating-row semantics or individual cell characteristics.
 
Stephan van Hulst
Saloon Keeper
Posts: 15484
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Tim, that makes sense.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic