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/
Related
i work on a project where we use JSF + Primefaces
I would like to know if it's preferable to use JSF components as much as possible even if there are sometimes the same components in Primefaces (for basic use)
Using Primefaces only for specific things not available on the JSF version
When should we use Primefaces instead of JSF ?
sorry for any faults
In general, I'd say prefer them than JSF standard components, the reason is simple: CSS skinning. For example, even if h:inputText and p:inputText are exactly the same component, you might want to have the same CSS skinning for all JSF components (specially if you use a premium layout from PF)
But, I think there are few exceptions:
If you use JSF 2.3. For example, I'd rather use h:commandScript than p:remoteCommand. As they're not "visual" components, I'd prefer to use standard components. See also what works better for you ;-)
Also, Oleg presents some performance killer using PF components in datatable, see here http://ovaraksin.blogspot.com/2013/05/jsf-choice-between-legacy-components.html
I think the most important point is consistency, which comes in a couple of flavours.
PrimeFaces (PF) components have a lot of styling put on them (through the theme options). If you use PF components throughout your application, you'll get a consistent style. If you mix PF and JSF components this will look messy.
PF components have a particular way of doing things - organising options, defining ajax calls etc. While it's important to know how the JSF stuff works underneath, using PF components consistently will make your code consistent too.
Finally, in many cases PF components are exact replacements for JSF components, but often with extra features added. There's no reason not to take advantage of them.
Better choose one of them and develop all application using mainly one stack. Will be easy to support, easy update, easy bug fix.
Primefaces at the moment good choose.
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).
Hy,
I have read many time that JSF separates more than other MVC framework the view from the model/business logic and I dont really understand why. I mean, if I have a non JSF application and I have a servlet and a JSP page; the servlet does the business logic and pass some message to the JSP page which shows it to the user;here I am not mixing any businnes logic with the view, so why with JSF I get more separation? could you show me a little example?
Thanks
When you just have a servlet and a veiw that combining "M" and "C". I use servlets as something that you go through to get to the model and vice versa. Servlets are a good definitive controller to separate the view from the model.
Also, what's wrong with a few more layers? :D
This is such a fundamental MVC question I have a feeling the answer is already on SO and I just can't find it. Please forgive me if it's a dupe.
I am reimplementing a big legacy JSP/servlet app in JSF2/Spring3/Facelets. I think in general we want to leave the presentation formatting to the .xhtml and use the backing bean to make the data suitable for display. This makes for a nice separation of concerns even though I believe both are part of the View. However, the legacy app has an attractive table that contains headings on the left and HTML formatted stuff on the right, like links that pop up a dialog (only one row has this). I decided to put all the content in objects that a datatable iterates through and it worked but I found myself putting sort of ugly HTML (for links and such) in the backing bean, and putting ugly conditions in the datatable (e.g. if this is row 0, then use this CSS class). This works but it doesn't feel right. I've very tightly coupled the backing bean to the presentation, but I can't think of a simple way to get around it. Does anyone have any guidelines around how to handle this? Thanks in advance.
This looks like a valid usecase for a JSF Component. A very good guidance is this book: http://jsfatwork.irian.at/book_de/custom_component.html (Free available online)
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.