|
|
Win a copy of Helidon Revealed: A Practical Guide to Oracle’s Microservices Framework this week in the Java in General forum!
|
|
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.
JSF as originally conceived was supposed to provide an abstract JEE MVC framework. Although it was implemented for HTML and HTTP, it wasn't supposed to be limited to either HTML or HTTP. In fact, at the time, WAP was a serious competitor for mobile device web access on units lacking sufficient resources to do full HTML and JavaScript. Likewise, it opened the possibility that you could have used it for things like interactive PDF forms documents. You can see that legacy in the fact the the renderers for JSF are plug-replaceable.
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.
As a diversion, incidentally, I should note that long before JSF, the idea of abstracting HTML, CSS and JavaScript was widely seen as a Good Thing, even outside of the purely Java world. HTML has been long criticized for muddling together content and rendering, which is what led to the development of CSS. So I'd hardly count JSF's efforts in that regard as a point against it. JSF delegates to CSS and server-side scripting where appropriate, rather than re-inventing a technology just for the sake of being a "JSF" technology.
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.
Then there's the latest fads. A lot of people sneer at JSF because it's "Old Style". The idea is that you can be more "productive" using one of the newer platforms based on scripting languages such as JavaScript, Ruby, or Python. I'm not, as I said, one to force JSF to do things that JSF doesn't do well, but I tend to view this "new stuff" with a jaundiced eye. You're "more productive" using them in large part because you arent' "wasting time" on the design and compile phases. But one thing I've learned over many languages and many platforms is that a major project is a major project regardless of what it's based on, and if you do something that speeds up one phase, it's borrowing from the productivity of somewhere else. In the case of scripting languages, that means that the "post-development" debugging phase is going to become very demanding, since a lot of the "wasted" time in platforms such as JEE is in making the compiler and design tools happy up front. Personally, I'd rather have my errors come out in the privacy of my office than in production all over the Internet, but as you can see by the headlines, my viewpoint isn't widely accepted.
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.
So the first part of the project would be to define a separate h:form on the starting page (or in the page masthead or other shared tile). That form contains the inputText control to get the search terms and a "submit" commandButton (and probably some JavaScript to make "Enter" work with Internet Explorer). Note: HTML forms cannot be nested, so make sure that this form is independent of any other forms on the page! It's important not to share the search control with a general form, since JSF would fail to execute the search if any control on the submitted form had an invalid value.
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 ato 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.