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
Related
This question already has an answer here:
What is the use of faces-config.xml in JSF 2?
(1 answer)
Closed 4 years ago.
I have been studying JavaEE8 and practicing with some projects, understanding the new technologies like Servlet 4.0 and JSF 2.3. I have read in many forums and pages, in some I see that they say that web.xml and faces-config.xml are not necessary, because annotations are now used, but in some others they continue to use them.
In which cases should you continue to use the Web Deployment Descriptor-> web.xml and the application configuration resource file-> faces-config.xml?
They aren't required, but I'd highly recommend to use them since you'll need them sooner or later for additional configuration anyways.
The annotations are used to achieve better readability and to simplify the faces-config.xml and web.xml, however they do not even nearly allow for the configuration options that can be made in the configuration files.
For example you can use the #FacesValidator Annotation instead of declaring and referencing the corresponding class in the faces-config.xml.
A task that can't be achieved by using annotations would be the declaratation of a welcome page. If you want to specify it, you need the web.xml.
I found a specific problem in the Mojarra implementation of JSF 2.3 when using the web.xml or faces-config.xml file. In the code of this implementation, the ELUtils class has the following condition:
if (getFacesConfigXmlVersion(facesContext).equals("2.3") || getWebXmlVersion(facesContext).equals("4.0")) {
throw new FacesException("Unable to find CDI BeanManager");
}
which throws an exception: "Unable to find CID BeanManager". I only had the faces-config.xml file with the latest version of JSF specified in the namespace and I was throwing that exception.
To avoid this problem, you can specify a different version of JSF (before 2.3) in the faces-config.xml file and specify a different version of the web.xml file (before 4.0), or simply do not add any of these configuration files. In my case, I removed the faces-config.xml and ran the application without problems.
I hope that the implementation of Mojarra will solve that little detail.
In the JavaServer Faces documentation it is written that it is possible to use different view declaration languages.
But, Facelets apart, it is impossible for me to find other view declaration languages to use with JavaServer Faces.
Where can I find other view declaration languages for JavaServer Faces?
It just hasn't happened - view definition languag is an extension point in the specs, but no other VDL emerged (maybe it will?). The only actually used methods of building JSF views is the deprecated JSP way or the common Facelets way.
It looks like people are more interested in dynamically building component trees in code - but this area of JSF is also surprisingly tricky to get right (it's supposed to be improved in JSF 2.3).
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.
when using CombinedResourceHandler in a Richfaces application only stylesheets and user defiend scripts are combined. The standard JavaScript resource and all Richfaces specific resources remain as seperated resources.
The Omnifaces documentation states:
RichFaces has the same problem with several JS files, but this is so far not exactly trivial to workaround
So my question is what this 'non-trivial workaround' would be?
As far as I can see, CombinedResourceHandler wont handle resources when getRendererType() returns org.richfaces.renderkit.ResourceLibraryRenderer. These are then handled by org.richfaces.renderkit.html.ResourceLibraryRenderer.
I am not sure what would be the best way to combine RichFaces behaviour with OmniFaces here.
I was able to create a solution by modifying OmniFaces CombinedResourceHandler.
Details in short:
Richfaces utilizes a concept called ResourceLibrarys wich means a resource may not only be a single file but instead a collection of those files. For example, RichFaces uses a resource named base-component.reslib. RichFaces ResourceHandler interpretes this resource dependency as dependency to
javax.faces:jsf.js
jquery.js
richfaces.js
richfaces-base-component.js
So the CombinedResourceHandler needed some extra functionality to seperate dependencies to ordinary Resources from Richfaces ResourceLibraries. The latter needed to be resolved according to specifications obtained from RichFaces sources.
It was not trivial to work this around without modifying the CombinedResourceHandler itself. The CombinedResourceHandler itself has really to be modified to use a reflection hack which extracts the resources from RichFaces' org.richfaces.resource.ResourceLibraryFactoryImpl. The reflection hack is necessary in order to keep OmniFaces free of RichFaces dependencies so that it can be used together with other component libraries like PrimeFaces.
As per issue 107, this was implemented in 1.3-20121206.
I have been involved in JSF + Facelets dev for a month or so. I used composition, insert, define and other tags from facelets. I am finding it difficult to understand what facelets really give me? What are its alternatives ? What is that View Handler technology?I am not able to find good material / online notes on the same. Can someone explain in laymen terms - What it is? Thanks
Facelets is a view technology. Facelets is the successor of JSP. The only alternative as far is JSP, which has almost no seamless support for JSF components. If you leave Facelets aside and step back to JSP, then the real advantages of Facelets will be quickly clear.
You may find my answer in the question useful as well: What is the difference between JSF, Servlet and JSP? Facelets is also covered in there.
Without providing a complete academic background on Facelets, here's what it really gives you:
First, the ability to create reusable HTML code that you write yourself: this is not possible with JSF (pre-v2). Facelets gives you more control over the output of your webpages.
It has been demonstrated in some editors you can preview parts of
your page this way as well, but in reality this is impractical as the
webpage has many states of which only the initial bare version would
be visible in the preview.
If you are going to use JSF for a public website, Facelets are a must
for SEO, considering that with JSF you have no control whatsoever of
what comes out of the standard JSF components.
Second: templating. The ability to define blocks of HTML (read: Facelet compositions) that can be reused using tags such as ui:define and ui:insert.
There are other benefits, but right now you should know that these two are why you are using Facelets over JSF. Also, JSF 2.0 by default contains a modified version of Facelets.
benefits of facelets: http://www.ibm.com/developerworks/java/library/j-facelets/