Strategy for converting HTML mockups to JSF

[Joshua Hewitt]

This is a summary of our front-end development process:
- designers create PNG mockups
- UXers create HTML mockups
- developers create final JSF

Now, these HTML mockups are pretty complete. They use all our in-house JavaScript widgets, production CSS files, responsive design, accesibility requirements, SEO-friendly code, proper semantics etc. So basically the final HTML we need from the JSFs has to nail these mockups, otherwise widgets might not work, styles might not appear correctly, accesibility errors might crop in and SEO might suffer. The developers tend to have limited experience in HTML/JavaScript/CSS/accesibility, especially compared to the UXers, so the less they can do to screw up the HTML the better.

With this in mind we tell our developers to just convert the very minimum to JSF. So that basically means forms & form elements and the occasional loop. For example we tell them to avoid h:dataTable and just use the given HTML table and a loop - for some reason (probably lack of experience) we found it very difficult to nail the right HTML in terms of thead, tbody, th and td (or to get a rowspanned "There are no results" output for empty lists). We even tell them to use straight EL instead of h:outputText (unless they really need it) for i18n literals or form outputs. Then there is the added complication in that we use HTML5 (currently using a RenderKit for that). I also prefer to avoid tying my HTML to a given technology: I don't want my JavaScript/CSS to depend on JSF (or PrimeFaces or whatever) output, I want it to depend on what we consider the "correct" HTML in terms of semantics (ie, unobtrusive frameworks).

Would you say this is a correct strategy? I find it helps reduce developer workload (less to convert), reduces front-end errors (less to screw up), and might it also reduce memory footprint on the server (less component tree)? Or am I missing something?

[Tim Holloway]

For my opinion, a lot of that is backwards. You're making people code logic all over the prototype Views. I've always maintained that when the View Templates are full of logic, it makes maintenance much harder/more expensive, since you have to play hide-and-seek with code. Is the code in the View? Is it in the backing beans? Does it ping-pong between the two?

Complex EL is a to debug. Simple EL can be more easily debugged, since you can put breakpoints in the Java backing bean, but a View Template isn't code, it's a static template, and therefore logic flow is not an inherent property. BTW, if you're coding EL as a replacement for h: outputText in JSF2, that's OK with JSF, but the outputText renders <span> tags that can be stylized. Lacking those tags, you'd only have fine-grained text styling abilities via brute-force HTML and my position has always been that the amount of actual raw HTML in a View Template should be kept to a minimum. The JSF renderer doesn't track it and if you were to replace the HTML renderer with, say, a PDF renderer, those raw tags wouldn't translate.

Datatables are likewise designed for specific functionality. They respect that what you are actually trying to do is present a 2-dimensional data display, and there's nothing inherent in, say, a table of logarithms that demands an iterative process. In fact, you could generate the rows and/or columns as a parallel operation and the resulting display would still be the same. Plus, the dataTable's backing Model object automatically tracks things like links, clicks, or AJAX operation and knows what row was processed without having to code explicit logic on the View Template.

Of course, the real problem is that there's no good tool available to properly render JSF View Templates for layout design. Only very primitive stuff.

[Ranganathan Kaliyur Mannar]

The questions raised by the OP have been in my mind too. I think pass-through elements introduced JSF 2.2 have the potential to solve many of these issues.

[Joshua Hewitt]

(I think I might not have explained the EL bit properly. I definitely would avoid it to add any kind of logic in the XHTMLs.)

What do you mean code logic in the views? The original HTML/CSS/JS mockups only contain view, no logic. Same goes for the JSF that comes out of that. All logic stays in the Java: view in the BBs, business in the EJBs and persistence in the EMs.

When I talk about EL I mean just simple outputs, to just use #{text} instead of <h:outputText value="#{text}" /> unless you really need <h:outputText/> for some reason (eg, rendered or escape attributes). I'd even argue that if you get an HTML mockup with <span class="warn">Text</span> it's easier for everyone if you just change that to <span class="warn">#{text}</span> rather than <h:outputText value="#{text}" styleClass="warn" /> when converting it to JSF. Less to think about, less work, less mistakes, more like original mockup, easier to change framework in the future.

I see your point about rendering in a different format. That is definitelly one to add to my "or am I missing something?". Currently we only need HTML and JSON outputs, so it is not an issue. But it might be.

My main point is that, assuming I would rather tie myself to HTML than JSF (this is the fourth MVC framework I have used, and HTML has changed little in all this time), there is no weirdness in avoiding "useless" HTML abstractions provided by JSF, no? There is nothing inherently wrong when I tell our developers to use <a/> instead of <h:link/> unless they have a reason to do so (for example if they were to use an outcome instead of a straight href then yes, use the JSF tag - as long as it isn't the JavaScript-only <h:commandLink/>). Sure, we use h:dataTable and h:panelGroup when it makes sense, for region updating thru AJAX, for complex list/details interfaces etc. But in most cases we don't need it, so I say we just leave the original HTML.

[Tim Holloway]

The outputText element also counts for things like determining cells in a panelGrid, where raw text doesn't. I do use raw text myself on occasion, but only with more care than I'd expect most HTML-only people to understand. And definitely, if you had any intention of using a JSON renderer, it wouldn't care for raw HTML. Likewise, a JSF link tag automatically renders the servlet context part of the URL, but a straight HTML anchor tag <a> does not.

I'd argue that JSF would be a better UI design language than HTML overall. One of the biggest complaints about HTML since Day 1 has been that it's both a markup language and a content language. CSS was created to lessen that blurring, but the results are less than perfect. JSF's View Template Language, on the other hand, was designed specifically to be a layout design language. Display characteristics are the province of CSS rather than markup and the semantic difference between a data table and a display grid is preserved. All of which means that when the Next Big Thing comes along, you'll probably be able to use XSLT to convert JSF markup to whatever the next generation requires a lot easier than you can do with HTML. Automated processing of HTML is a longstanding problem, whether it's screen-scraping or bulk page source transformations.

One thing I'd definitely avoid is a case-by-case flip-flopping between HTML tables and JSF 2-dimensional controls. That's likely to confuse people, since it requires knowing about the cases involved and not the actual display layout. See the previous paragraph. And, if you make later AJAX-related enhancements to your tables, they'll have to be recoded.