Tim Holloway wrote:Well, I don't encourage mixing HTML tags with JSF tags. But sometimes it's unavoidable. And sometimes it's avoidable, but too much trouble.
I think you can PROBABLY make Eclipse happy if you add an XSD schema declaration for HTML5 to your view template.
Tim Holloway wrote:
We think JSF is flawed because it tries to abstract away HTML, CSS and HTTP,
That's what blew my fuses from the start.
Slightly before JSF2 first came out, Facelets became popular. Facelets was specifically targeting HTML, although seen abstractly, Facelets isn't HTML-specific. Still, that's the way the wind was blowing.
JSF2.0 attempted to make JSF more HTTP-friendly, allowing things like better support for GET - although I still think that the PrettyFaces add-on does a more complete and tidier job for that. Plus - very importantly - JSF2 added native AJAX support. Prior to JSF2, AJAX came only via external add-ons. JSF2 also made an attempt to support multi-view workflows, although it did so poorly. It added View scope, which reduced the clutter of dangling session objects, and Flash scope, which I've used, but have misgivings about.
It is true that JSF2.2 is turning even further away from JSF's initial abstractions and more towards HTTP specifically. I don't know that I'm really happy about that. From a 50,000 foot perspective, I see too many "metadata" things. And that screams "kludge" to me. The pass-through concept for HTML5 support strikes me as a cop-out. I'd rather see the core tags upgraded for HTML5 and if additional passthrough support was desirable, a separate sub-element for that purpose strikes me as being cleaner.
The one thing I'm really not sanguine about is all the hoopla about making JSF "stateless". When your primary goal in life is to interact with a single form via multiple postbacks, to me that is pretty much the definition of "stateful". If I want stateless, I'd much rather consider using something like ReST, which is more in tune with such a thing.
And yes, I have a major app in production that's based on JSF, but using Apache CXF for ReST functions. Like I said. I like JSF. But I'm not a small child with a hammer. I'll code the parts of the app that are suited to JSF in JSF. The parts that aren't, I'll use something that fits them better.
Tim Holloway wrote:I read the article you linked to. It's rather strange, since it has a tone like it's against JSF, but if you read the whole thing, it's probably in favor of JSF, except the whole thing is rather vague. Less-than-perfect English didn't help in making it clear, either.
I am a very big fan of JSF and it's usually my first choice when I need to do a GUI-heavy webapp, especially if there's a lot of data validation required. JSF automatically provides those services with mininal coding required by the developer. But that doesn't mean that when I develop a JSF-based webapp, that everything in it is JSF. JSF is not a "greedy" platform, and it will happily co-exist in a webapp alongside of regular servlets, JSPs, and even some other platforms such as Struts. So, for example, if I have a fill-in-the-form webapp that needs to produce a PDF, the forms are JSF, but the PDF is produced by a servlet, since JSF really isn't designed to output non-HTML documents.
Not everyone feels that way. In fact, one or 2 of my fellow JavaRanch Moderators has gone on record against complex web frameworks such as JSF. They prefer to roll their own. My viewpoint is that I don't have time to re-invent the wheel, optimizing (and debugging) a custom framework for every webapp I do, but not everyone sees it that way. JSF works for me, and since it's part of the JEE standard, I can produce webapps that I know that other people can understand without first puzzling out my particular custom framework. They can buy books to help them, and, of course, ask questions on forums such as the JavaRanch, StackOverflow and the main Java forums. Documentation for custom frameworks - whether they're for GUIs, for security, or whatever, tend to either not have formal documentation at all, or if they do, it's incomplete and/or out-of-date, since their creators usually have "more important" things to do.
Tim Holloway wrote:You appear to be using certain words in a strange way and it's confusing me. But the overall function of what you are doing seems clear, so let me describe what I do.
More than once I've had a web page with a "search" feature on it. You'd enter a term and (usually) it would navigate to a new page containing a list of matches.
You can, if you prefer, dedicate a backing bean solely to the search form, since it's all self-contained. Or you can place the search term Model property and action method on a shared bean. The action method does the search and makes up a list of results. This list is also a JSF Model property, since we're going to render it to a JSF View.
This View can be a new page, or it can be a sub-View of the current page, in which case, you'd probably want to use AJAX to reduce the re-rendering.
What I typically do is output the results to a dataTable control. That allows each result to occupy 1 row of the resulting table. I use a corresponding DataModel wrapper around the results list so that I can make the results themselves be clickable commandLinks and use a common dispatcher (action method) for the entire table's links. That approach is about the simplest and cleanest way to do an all-JSF solution, such as a database record search/display/edit.
The limitation on that approach is that it expects the results to be all-JSF. What if you want to output links to non-JSF webpages? Possibly even in other websites? Or maybe it's JSF and you want "bookmarkable" links?
In that case, you can either use the h: outputLink tag or you can output a raw URL (using the "escape=false" option on h: outputText). Which solution you choose depends on what form of links you are creating. If you're pulling raw link data from a database, use the non-escaped outputtext and output them verbatim. If you're dynamically creating links in a standard format with variable arguments, the outputLink plus f: param solution is cleaner.
The one thing I haven't done is use all those new fancy JSF2-only tags like in your example. For several reasons.
1. My "money" webapps are based on RichFaces 3 and I'm not budgeted to upgrade to RichFaces 4. RichFaces 3 interferes with the use of many of the new JSF2 tags.
2. I haven't found that I actually needed those new tags to get what I want in a clean and straightforward manner.
3. The new tags used in the manner that you're illustrating strike me as being too much like "programming" the View. To me, the View is a canvas on which to paint and the only logic there should be minimal and directly limited to how the view appears. Otherwise you begin to lose the Separation of Concerns that makes MVC so powerful. And more importantly significantly raise support costs, since now anytime the page changes you have to go on a "treasure hunt" to find out where the logic for a given function is. Which, in worst-case scenarious is splattered randomly between View Template and Backing Bean.
Tim Holloway wrote:Welcome to the JavaRanch, Marion!
Actually, JSF isn't very much on URL parameters. For one thing, JSF is a MVC framework where the Controllers are all pre-written - you only have to write Model (backing bean) and View Template (xhtml) components. JSF's built-in controllers then take care of the process of synchronizing data values between Model and View (and vice versa) automatically as part of the JSF lifecycle process. So mostly you use form controls for data entry and the command processor methods work with the values that have been set for you in the backing bean. You don't normally want to set "parameters" on a View Template. Or for that matter, code anything resembling business logic on a View Template. In fact, the less "code" on the template, the better, since EL is a to debug in addition to being a violation of the MVC Separation of Concerns consideration.
JSF is very different that way from other UI frameworks such as Struts. On the plus side, however, it requires fewer files and is much better for processing forms where you want automatic error reporting and a built-in interlock that ensures that forms whose data is wholly or partially invalid will not be processed.