This question already has an answer here:
Difference between h:link and h:outputLink
(1 answer)
Closed 5 years ago.
Why does this JSF Tag
<h:link outcome="hello/sayhi">Spring MVC</h:link>
<h:outputLink value="hello/sayhi" >Spring MVC</h:outputLink>
becomes
<span>Spring MVC</span>
Spring MVC
in the browser so that the <span> is completely useless?
How can I get h:link working so it outputs the correct link including the context path?
The component h:link requires a valid (and existent) outcome target, if for any reason the server do not find the outcome target in your project, then a span will be rendered.
In this case, review your application files and check if the target "hello/sayhi" really exists and is declared correctly. Maybe you are just forgetting a bar ("/hello/sayhi") before the path (it's impossible for us to know).
According to it's documentation, an h:link should only render as a span if you set it as disabled=true. So I'm 100% sure that your problem really is a incorrect navigation path.
Related
This question already has answers here:
How to find out client ID of component for ajax update/render? Cannot find component with expression "foo" referenced from "bar"
(6 answers)
Closed 4 years ago.
I have such id of dialog form form:processFilterPanel_fpanel_tv:dialogFormIO:j_idt195:ItemWidget_input
And I want to work with one element of form at backend side. The problem that this part of id j_idt195 is always changing by jsf (when it starts a new session) and I don't know how to get it. Have any ideas?
Just use id="yourFavId" on the component and reference it.
JSF gives those weird looking ids to the html components that didn't have a defined one.
This question already has an answer here:
EL proposals / autocomplete / code assist in Facelets with Eclipse
(1 answer)
Closed 5 years ago.
You are analyzing the Facelets code of a very large JSF web application written by others (e.g. during a production incident) and you want to find the bean class that is implementing a bean, knowing its name as it comes in EL expression.
You didn't write it and the bean's name does not match any Java class in the project.
You can't assume that the class is annotated.
While there are several methods to reach to the same result, I hope this question can document the best practices to solve this problem.
NOTE: This question is not about how to enable an IDE option to do so, it is about how to deal with it, without IDE support. I have made many searches and haven't found this question in StackOverflow, in the terms expressed here.
Print it!
(-) Requires to redeploy.
Edit the XHTML file to write out the class' name
<!-- #{msg.getClass().getSimpleName()} -->
Redeploy the modified XHTML file
Reload the page
Look for Annotations
(-) Not always works
Search for the annotation ("#ManagedBean") across the workspace and find the annotation.
Look in Face-Config
Search in faces-config.xml (e.g. ResourceBundles)
IDE Support
E.g. Eclipse with JBoss Tools
EL proposals / autocomplete / code assist in Facelets with Eclipse
This question already has answers here:
How does the 'binding' attribute work in JSF? When and how should it be used?
(2 answers)
Closed 7 years ago.
I have read about component binding with binding attribute in following questions:
JSF component binding - some confusion
component binding vs findComponent() - when to use which?
I understand that it binds the UI component behind the JSF tag in the view to an UIComponent property in the backing bean. However, I am confused what the use of component binding is and when we should use it. Can someone explain it in a more simpler way and give some practical examples?
You should use it if you want to have access to the entire UIComponent instead of just only its value. For example, to access some methods which can't be invoked/bound in the view. This is answered in the 1st question you found: JSF component binding - some confusion
The 2nd question which you found, component binding vs findComponent() - when to use which?, merely answers "binding versus findComponent()", it does not answer "binding versus value" at all as you seem to think. Please don't get confused by this. value would obviously win over binding.
In real world code, component binding to the backing bean is often only used whenever the developer needs to manipulate its children programmatically by e.g. component.getChildren().add(...). The bean should however be request scoped. A broader scope may lead to inconsitenties as component instances are basically created on a per-request basis and shouldn't be shared across multiple requests. The view scope can also, but this is very memory inefficient, and on Mojarra versions older than 2.1.18, partial state saving must also be turned off, otherwise the view scoped bean instance referenced by binding will implicitly be recreated on every request. See also JSTL in JSF2 Facelets... makes sense? for a related answer.
It's also possible to bind the component to "the view". E.g.
<h:someComponent binding="#{some}">
This refers to an instance of UIComponent in the Facelet scope ("page scope"). This enables you to use for example #{some.clientId}, #{some.value} elsewhere in the same page. Note that no backing bean is involved here. See also JSF component binding without bean property.
Here are some real world use appliances of binding attribute:
disabling second text field after data validation through ajax of first text field
Check which form has an error
Input text validation based on drop-down list selection
How to let validation depend on the pressed button?
How to implement row numbering into h:dataTable
Split java.util.Date over two h:inputText fields representing hour and minute with f:convertDateTime
read this answer:
What is the advantages of using binding attribute in JSF?
However, a lot of people in the community do not recommend binding. See this article for example:
http://drewdev.blogspot.com/2009/01/jsf-component-binding-stinks.html
I am trying to get the reusable group of jsf 1.2 components inside a panelgrid using Facelet tag file. #Balusc's previous answer at How to make a grid of JSF composite component? was a fabulous resource. I have a couple of followup questions:
In my c:when how do I test for the tagName itself instead of checking for the attributes. Instead of
<c:when test="#{type != 'submit'}">
I want to check tagName itself to decide how to format it. If 'input' do xxx.
2 Is this approach is still valid with jsf 1.2 other than f:ajax? If yes, can I replace with a4j:support...?
In my c:when how do I test for the tagName itself instead of checking for the attributes.
I'm not sure how this question makes sense. It sounds like that you're approaching something not entirely right. Do you maybe have copypasted exactly the same piece of code over multiple tag files? You should not do that. Make it a reuseable <ui:composition> or maybe <ui:decoration> instead which you compose/decorate in every tag file along with a fixed and unique <ui:param> value depending on the taglib file.
Is this approach is still valid with jsf 1.2 other than f:ajax? If yes, can I replace with a4j:support...?
Being able to create tag files is not necessarily specific to JSF, but to the view technology used, which is in this case Facelets. You can even do similar stuff in its predecesor JSP, see also this answer for an example: JSF 1.2 custom component from jsp:include It should work just fine in every JSF version supporting the view technology in question.
As to ajax support, it doesn't matter to the tag file what you're all doing inside the tag file. If you want and can use <a4j:support> then just do it.
This question already has answers here:
back commandbutton in jsf
(5 answers)
Closed 8 years ago.
How do I make a link which navigates the user back one page (i.e. same as clicking browser back)?
Thanks.
To the point: just remember the request URL or the JSF viewId of the previous page so that you can use it in the href or value of the output/commandlink. There are several ways to achieve it, depending on how you're actually navigating through the pages and how "jsfish" you want to achieve it. You could pass it as a request parameter by f:param in h:outputLink, or you could set it as a bean property by f:setPropertyActionListener in h:commandLink, or you could create a PhaseListener which remembers the viewId and make use of navigation cases, or you could grab the -much less reliable- JavaScript history.go() function.