Before asking this question, I visited many other related ones and tried to gather the maximum of information. But, what I found till now let me understand that there is no real/major difference between ui:repeat and h:dataTable, and that whenever we can use h:dataTable we can also use ui:repeat (sometimes one of them is a little complex than the other, but at the end we got same results).
So, is there any use cases where the only choice is to use h:dataTable? or the opposite (only choice is ui:repeat)?
is there any use cases where the only choice is to use h:dataTable?
If you want to use an UIData-based component (with all of its special attributes absent in UIRepeat).
If you want to render a HTML <table> by a JSF component.
If you want to be able to customize the <table> rendering (like PrimeFaces <p:dataTable> does with sorting, filtering, grouping, folding, lazyloading, etc, etc).
If you aren't using Facelets as view technology.
or the opposite (only choice is ui:repeat)?
If you don't want any of above and thus need a pure markup-less iteration component.
If you want to be able to skip every n items during iteration (using step attribute).
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'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 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.
I'm looking for a ready made, freely available component that provides the following features:
editing list entries
deleting entries
adding a new entry - possibly invoked multiple times
bind to property in managed bean of type List, or similar
optional: reordering entries
optional, simple: allow verification that at least one element is entered (required="true"? required="1"?)
optional, better: restrict by minimum and maximum allowed number of elements
The simplest way to allow editing entries would be to represent them as input element. Preferably the element won't need to sync to the server for every change in the number of elements.
Alternatively: is there a trivial way to create or compose such a component oneself?
If this if of importance: currently I'm using Richfaces 3.3.3 and MyFaces 2.0.
Edit: The component is expected mostly to be used for creating new lists from scratch, so that should be as simple for the user as possible. Preferably just tabbing to the next empty input element automatically created at the end of the list. I'd like to use the component for editing these lists, too, but that feature is expected to be used much less often.
You could take a look at Primefaces p:collector. The example in the Primefaces showcase is a good starting point. It can be used for adding elements to a list and for editing and removing these elements.
Probably the simplest way that I would know of going about almost all of these is the PrimeFaces dataTable component. With the exception of adding and deleting entries inline, all of this comes out of box. Deleting entries can be as simple as adding a delete button in a row and adding entries can be done through invoking a modal dialog with a form to create a new entry, add it to the backing bean list for the table, then asynchronously updating the dataTable.
http://www.primefaces.org/showcase/ui/datatableHome.jsf
It really does seem to be the most fully featured JSF dataTable component out there.
Can we sort values in column of a panelGrid. If yes, can I see an example
Rather use h:dataTable to represent a dynamic table which is backed by a List<RowObject>, wherein RowObject is basically just a Javabean (DTO - Data Transfer Obejct, VO - Value Object, whatever you call it :) ) representing a single row.
Such a List can be sorted using Collections#sort(). All you need to do is to implement a Comparator which takes care about the ordering. Then in the JSF page just have a bunch of buttons or links which calls Collections#sort() on the List. Those buttons/links just have to pass the sortfield along.
You can find here a basic example: http://balusc.blogspot.com/2006/06/using-datatables.html#SortingDatatable
No, you can't. <h:panelGrid> = <table>
If you want sorting, look at Richfaces or another component framework (Icefaces, primefaces, trinidad, tomahawk, etc). There are <x:dataTable> components there which allow sorting on their <x:colum>.