As all JSPs are generated / translated to Servlets before their execution, is its true for Facelets too?
I am working with JSF 2.0 and Facelets and wanted to see its generated Java Code which might be Servlet.
No, Facelets files are parsed to a XML tree using a SAX parser. The XML tree is stored in the Facelet cache. The XML tree is during view build time turned into an UIComponent tree which is accessible by FacesContext#getViewRoot() (which you can traverse by getChildren() during runtime). The component tree normally generates HTML code by their own encodeXxx() methods or the ones on the associated Renderer, starting with UIViewRoot#encodeAll().
Facelets files do not generate any class files. The XML trees are by default stored in server's memory. Since JSF 2.1 you can however specify a custom FaceletCache implementation by <facelet-cache-factory> in faces-config.xml wherein you can write code to store the XML tree on for example the disk file system (which would be slower, though).
If you use <ui:debug> in the view and open it, then you can see the textual representation of the component tree behind UIViewRoot. See also how to debug JSF/EL
See also:
Why not JSF pages are precompiled (atleast partially) but instead parsed, evaluated each time view is built?
What's the view build time?
Measure the render time of a JSF view after a server request
Why Facelets is preferred over JSP as the view definition language from JSF2.0 onwards?
Not exactly the same way, it gets cached. But it doesn't generate servlet code.
Related
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).
Indeed, very less has been written/shed on the component tree itself, that seems to be source for a whole lot of problems when one takes on understanding JSF.
One of the quote I recently read on a social networking site-
LIBRARY - Because not everything on the Internet is true.
Neither the above nor its opposite holds true either.
This is a screenshot from Anghel Leonard's book- Mastering Java Server Faces 2.2
I think this is plainly wrong. The author seems to be confused on whether its the component tree that gets saved OR the states of the components in the view(tree of UI components)
Considering this thread by BalusC-
When the form is submitted and the view is restored, the JSF
component tree is just rebuilt from scratch and all binding attributes
will just be re-evaluated like described in above paragraph. After the
component tree is recreated, JSF will restore the JSF view state into
the component tree.
Don't forget to read the comments.
Nonetheless, I would love to clarify the above note. Is my understanding perfectly correct?
... only if the component tree was previously saved ...
This is indeed not specific enough. How it really should read is:
... only if the non-transient state of the component tree was previously saved ...
Short Version:
If two JSF library jar files both include a custom renderer for the same family and type, is there any way from within the library itself (i.e. not from the containing app) of specifying which one should be used? Something like assigning a priority, with higher ones used in preference to lower ones?
Longer Version:
I'm using Primefaces in a project and trying to override the provided head renderer with my own:
<render-kit>
<renderer>
<component-family>javax.faces.Output</component-family>
<renderer-type>javax.faces.Head</renderer-type>
<renderer-class>com.example.MyHeadRenderer</renderer-class>
</renderer>
</render-kit>
If I put that into the WEB-INF/faces-config.xml of the war file then it's all good, and my renderer gets used.
However, if I try to deploy my code as part of a library jar (my-utils.jar), with the renderer defined in META-INF/faces-config.xml, then the Primefaces one is used. This contains exactly the same definition, so I'm guessing it just depends on the order they get loaded. Indeed, renaming my library to "xx-comps.jar" works, so it would appear that JSF is loading faces-config.xml files from all jar files in alphabetical order, with later entries just overwriting earlier ones.
Is there any way of forcing the selection to my library?
So far, I have these options:
Put my renderer directly into the WEB-INF/faces-config.xml of the war.
Build a custom Primefaces jar with that one renderer definition
removed.
Rename my library and rely on some (undocumented as far as I can
see) behaviour from the JSF loader.
Add a custom renderkit which extends the standard one, and reference
that from my war WEB-INF/faces-config.xml.
The first three all work but are not ideal, as (1) and (2) require changes outside my library, and (3) just looks dodgy as hell....
The fourth is just an idea as I've never written a render kit before so not aware of the effort involved. No idea if it is practical or would work, but it is better than (1) because at least the application only references a single render kit, and does not need to be updated if/when new renderers are added. Happy to put more effort into researching this approach if it seems a reasonable solution.
Also, I'd ideally prefer to use annotations rather than XML:
#FacesRenderer(componentFamily = "javax.faces.Output", rendererType = "javax.faces.Head")
public class MyHeadRenderer extends Renderer {
...
}
Thanks
You can specify the ordering via <ordering> in faces-config.xml of the JAR.
E.g. if you want your utility library to be loaded after all others, then just do so:
<ordering>
<after>
<others />
</after>
</ordering>
If you want to force an explicit ordering, then hook on specifically PrimeFaces, which has a <name>primefaces</name> in its faces-config.xml:
<ordering>
<after>
<name>primefaces</name>
</after>
</ordering>
In this beginner's JSF tuorial
section 1.1 says:
JSF UI components and their state are represented on the server with a defined life-cycle of the UI components.
But in the example that follows, I am unable to see how the state of an UI component is managed by the server? The example looks like a standard servlet jsp example minus the servlet mappings.
My other question is that in the example, we are accessing the jsp directly. Is this the standard thing to do in JSF as opposed to using servlet mappings?
First of all, if you're a beginner, I encourage you not to look at that old tutorials and find a good JSF 2.x one. JSF 2 was released in 2009 and you should consider it as the branch to learn, as it brings several advantages comparing with 1.x old versions.
JSF has its own lifecycle for any request you make from the browser which can be a GET or POST request, even an ajax based one. What you basically have to understand about JSF comparing with other frameworks is that it's stateful. In other words, you can keep a component's state from one request to another (you actually have a view state, which can be kept no matter how many requests you do, until you change the view).
Appart from that, about your last statement, in old JSF ages the servlet mapping used to be done over .*jsf suffix. It means, when you make a request for that in the browser, jsf will convert the matching jsp page and display it.
JSF 2 however introduced facelets, which are based in .xhtml view pages. It's now also possible to do the mapping as .xhtml having the source code in an .xhtml too and JSF will make the conversion. The main advantage for this is that end user will not be allowed to see the sources, as browser's request matches source page's url, so JSF servlet will always be invoked.
Jsf 1.x compiles jsp into servlet, jsf 2 use vdl instead of jsp, I wonder what is the source of performance gain compared to jsf 1.x?
The most important reasons why JSF 2 performs better are:
Use a fast SAX parser instead an static compiler (facelets): An Abstract Syntax Tree (AST) is built and keep in memory, so further request don't require parse the xml once built and component tree creation is done without extra steps.
Partial State Saving algorithm (taken from MyFaces Trinidad).
If you are looking on MyFaces 2.0.x/2.1.x, you'll get these improvements too:
Refresh build view when necessary (MyFaces 2.0.x/2.1.x specific): Only refresh view on PSS on postback when necessary (see org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS).
Caching EL expressions when necessary (coming soon on MyFaces 2.0.8/2.1.2): EL expressions are cached wit the AST, so no extra EL parsing per request is done. (see MYFACES-3160 for details)
JSF 2 is a big step in the righ direction.