Pass URL parameters through outputLink and viewParam in JSF 2.2

[marlon min]

This is my index.xhtml, which has a search box to take user input. The h:commandButton executes the search action. It then outputs search result through h:outputText. Also it outputs related information through a h:outputLink.

 <h:form id="wordForm">
            <h:panelGrid columns="3">
                <h:outputLabel for="word">Enter a word:</h:outputLabel>
                <h:inputText id="word"
                    value="#{wordController.word}" />
                <h:message for="word" />
            </h:panelGrid>
            <h:commandButton id="search" value="Search!"
                action="#{wordController.info}" />
        </h:form>
        <br />
        <h:outputText value="#{wordController.wordInfo}"
            rendered="#{not empty wordController.wordInfo}" />
	    
	    <h:outputLink value="relatedSearch.xhtml">
			<h:outputText value="#{wordController.related}" />
			<f:param name="relatedWord" value="#{wordController.related}" />
		</h:outputLink>

When user clicks this link, it will pass the parameter in 'related' variable to relatedSearch.xhtml, as below: 
<ui:define name="content">
		<h:messages />
		<f:metadata>
			<f:viewParam id="related" name="relatedWord" value="#{wordController.word}" />
			 <f:viewAction action="#{wordController.info()}" />
		</f:metadata>
		<h:message for="related" />
			
		<h:outputText value="#{wordController.wordInfo}"
			styleClass="preformatted"
			rendered="#{not empty wordController.wordInfo}" />
		

I have two questions for help:
1) is this the right way to use h:outputLink and f:viewParam & f:viewAction to pass URL parameters in this case?
2) wordController.related actually returns a List<String>, not one string. How can I make a loop in h:outputLink to pass one string to relatedSearch.xhtml in each iteration?

Thank you.

[Tim Holloway]

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.

[marlon min]

Hi, Tim, thanks for the insights! Just getting into this new world. could you specifically answer my two questions:
1) Is my way of using outputLink correct in the above code?
2) If it's correct, how to make a sort of loop in the outputLink to iterate through the variable "related", which is a list of String?

Thank you again.

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.

[Tim Holloway]

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.

[marlon min]

Hi, Tim:

Thanks for the detailed instructions, and I have been trying to digest all the information here, but it needs more time. I am trying to follow some tutorials provided in JBoss wildfly app server.

As for JSF, I indeed read some negative comments on it. Do you have any comments on whether you prefer JSF over other frameworks?

Here is one perspective on it. http://blog.primefaces.org/?p=3035

Thank you.

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]

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.

[marlon min]

That article is a rebuttal to criticisms from ThougtWorks:

"We continue to see teams run into trouble using JSF -- JavaServer Faces -- and are recommending you avoid this technology. Teams seem to choose JSF because it is a J2EE (sic) standard without really evaluating whether the programming model suits them. We think JSF is flawed because it tries to abstract away HTML, CSS and HTTP, exactly the reverse of what modern web frameworks do. JSF, like ASP.NET webforms, attempts to create statefulness on top of the stateless protocol HTTP and ends up causing a whole host of problems involving shared server-side state. We are aware of the improvements in JSF 2.0, but think the model is fundamentally broken. We recommend teams use simple frameworks and embrace and understand web technologies including HTTP, HTML and CSS."

As the article said, JSF 2.0, especially JSF 2.2 have changed a lot. I will stock to learn JSF, since I can see that it makes things a lot easier based on those tutorials I saw. Heavy use of scripting languages seems horrible to me!

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]

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.

[marlon min]

What does "abstract away html, css, http" exactly mean?

I just got into JSF world and started from JSF 2.2 from scratch. It seems pretty neat to do things with minimal configuration requirement in JSF 2.2. Many years ago I programmed a little bit php, asp, javascript, jsp. Just a little bit for each. Now I want to develop a site by myself and a lot needs to be learnt. I read that new JSF, coupled with PrimeFaces, can do amazing things. And you just mentioned PrettyFaces, which is good too. RichFaces is great too, although I haven't started to use it!

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]

You really don't need to re-quote everything I ramble on at length about. It's already visible from the previous post. :)

"Abstracting away" means that you would provide a simpler alternate mechanism to do what these existing mechanisms already do. For example, the original HTML spec controlled all layout and format characteristics for a web page, including positioning, font types and styles, colors, and so forth. CSS abstracted this out. Now it's considered bad practice to do such things using HTML, since CSS abstraction means that the HTML now only needs basic layout information, framing and data content. Separating out CSS allows you to "skin" a web page, changing its appearance for user preference or to adapt to different client display hardware. The HTML remains the same, except for referencing an alternative set of CSS definitions.