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)
Related
in JSF we have the well-known problems that originate from the distinction between taghandlers and components, which manifest for example in the question why JSTL-tags in datatables do not work as expected.
My question is, is there an intrinsic reason why this distinction had to be made? Why cannot we have e.g. a datatable implemented as a taghandler so that every row exists as a component in the JSF-Tree?
I am just wondering why so many people have to fall into the pits created by this distinction.
My question is, is there an intrinsic reason why this distinction had to be made? Why cannot we have e.g. a datatable implemented as a taghandler so that every row exists as a component in the JSF-Tree?
Efficiency. Imagine that your table has 100 rows and that there are 10 column components which in turn have 2 child components. You'd bump from 30 components to 3000 components. Ugh. The server memory wouldn't be happy with it.
... which manifest for example in the question why JSTL-tags in datatables do not work as expected.
Just don't use JSTL tags if you rely on variables which are only available during view render time. Use the rendered attribute instead.
General advice for starters in JSF: do not use JSTL until you understand the distinction between view build time and view render time. Only when you understand it, you're going to highly appreciate the powers of JSTL. It will save you from among others programmatically creating components in beans.
See also:
JSTL in JSF2 Facelets... makes sense?
JSTL c:if doesn't work inside a JSF h:dataTable
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.
I'm using Primefaces and I know that p:panelGrid extends h:panelGrid as it's clearly stated in the documentation.
However I can't see the exact difference between them. What extra functionalities does p:panelGrid provide? In which cases should I prefer using the Primefaces version over the HTML Basic one?
Although p:panelGrid extends h:panelGrid, it actually lacks many of the attributes that h:panelGrid contains. Which ultimately got me confused.
I can't speak for PrimeFaces' actual intention (I'm no PrimeFaces developer), but based on my observations so far, I can only conclude that they omitted attributes which only invite bad practices in HTML perspective (mainly HTML-deprecated attributes — use CSS instead) or makes no sense otherwise (and are better at its place in a parent or child component). I can only say that it's a Good Thing.
Upon further inspection in the source code I can also confirm that it doesn't technically extend from <h:panelGrid> (HtmlPanelGrid class), but from the UIPanel superclass (which is also used by a.o. <h:panelGroup>). This design decision is most likely done to have more flexibility in the rendered output as shown in the showcase.
Generally, you should only prefer an enhanced component whenever you start to actually need the enhanced/new feature. This usually only happens once you figure out you actually need such one feature and discover that it is missing in the standard component. You'd then usually already know the keywords you're looking for and simply start exploring the component libraries using those keywords if they haven't already implemented it.
I have another Richfaces question which may seem rather weird. I am developing a web-based application, using Richfaces for a front-end, that allows users to create templates for certain documents. For example: the user is presented with a rich:editor component, which, perhaps, has certain text already typed in, but it also has an input for a date, or specific text. The date can be entered in rich:calendar, the text can be entered in rich:inplaceInput, but the main idea is to be able to place those components INSIDE the rich:editor. I was trying to find an example where it's used and couldn't. So, my question is: is it even possible? Can you place RichFaces components (and, maybe, Seam components) into rich:editor? If not, is there a something similar out there that allows the user to do this? Can Seam do that? The reason I'm asking about Seam is because it appears to have some template-friendly logic and can work along with JSF and Richfaces.
Thanks for your help
Essentially your asking if you can add HTML elements to a textarea tag, and have them work. Unfortunately, no you can't.
What I've done in the past for such things has been to either weave boilerplate text, with inplaceInput, and free form text areas, or to simply provide the needed fields above/beside/below the editor.
I noticed that c:set does not work well used inside "include of include of include", as important notice facelets documentation does't recommend it too.
Now I am using ui:param inside ui:include, but it is a bit dispersive when no attached notes about params comes with the include, is there something other way to declare "global vars"?
This is really a matter of trying to fit old JSP programming into the JSF framework. You should be using backing beans to hold your data.
If you try to hard-code data directly into your xhtml file, you are defeating the purpose of JSF's MVC framework. If you have a specific example of what you are trying to do, I could give you a specific recommendation.