Clearly I am missing something. What I read about RowSets(Cached/Filtered/Joined) is that they are Beans capable.
So, on my .xhtml, I have the following kind of code, and I am using PrimeFaces 5.x
...
<p:dataTabel var="aRow" value="#{pageBean.List<Type>}">
<p:column value="#{aRow.property}" / >;
...
</p:dataTable>
If I use one of the RowSets to fetch my data, where do I define it so that I can access it without having to copy everything into Lists ?
Thanks,
Nick
The PrimeFaces datatable at this time of writing (5.2) does not support this. The reason for this is outlined in the link below, but it boils down to the fact that the current implementation of the PF datatable needs the total 'rowcount' and a rowset does not support this.
See also
http://forum.primefaces.org/viewtopic.php?f=3&t=4500
Related
I have a problem I can't quite get a handle on.
First the context: I am developing a web application using Primefaces 3.5 (yes, unfortunately I am stuck with this old version for now), running on JBoss 7.
There is a form with id "form" encompassing all following xhtml code.
I have a component in my view which is provided by usage of the binding attribute:
<p:dashboard id="dashboard" binding="#{myBackingBean.dashboard}" />
Then sometimes I would like to perform an ajax update on this component, this is done by using the RemoteCommand component of primefaces:
<p:remoteCommand
actionListener="#{myBackingBean.someActionListener()}"
process="#this" id="myRmtCmd" oncomplete="myJsFunction();"
update=":form:dashboard" name="myRemoteCommand" />
The RemoteCommand is triggered by a clicking on a Link:
Some Text
This works pretty well so far. However after deploying this code to production I sometimes get a FacesException:
javax.faces.FacesException: Cannot find component with identifier ":form:dashboard"
referenced from "form:myRmtCmd".
This is where my problem lies because I cannot reliably reproduce this exception. My question is this: What could lead to this exception being thrown? It seems to work 95 % of the time but being the perfectionist I am (and many of you reading this are as well, I'm sure ;) ) I would like this code to work 100 % of the time. What am I missing?
Before answering please consider these constraints:
yes, i have to use the binding attribute for providing the dashboard as I need a great deal of control over what gets added to the component
to avoid using IDs I also tried updating the dashboard by its css class via one of primefaces' advanced selectors: #(.ui-dashboard) - this also does not work!
yes, it would be possible to use a commandbutton/link instead of wiring up the remotecommand component to a simple html link but in this case the link is rendered by a JSF renderer component and I made some bad experiences with dynamically adding buttons etc (due to JSF Spec Issue 790)
Cheers,
p.s.
I also had this weird behavior.
There are probably more than one component bindded to #{myBackingBean.dashboard}, so the first one sets the id and there will be no one called "dashboard".
I use sorting in primefaces datatable and it's does not work with paginator. Where I made a mistake?
<p:column headerText="Year" sortBy="#{questionnaireListBean.getQuestionnaireData(questionnaire, 'YEAR')}">
#{questionnaireListBean.getQuestionnaireData(questionnaire, 'YEAR')}
</p:column>
And view scoped bean with init data in #PostConstruct method:
public String getQuestionnaireData(Questionnaire questionnaire, String column) {
return questionnairesData.get(questionnaire).get(column);
}
So the true title of your question is : "Sorting and pagination not working together in lazy loading datatable, primefaces", that's more of a precise description of your problem.
As for the issue, it apprears that you should expect the problem. In this link, the question was "Is there any datatable JSF component than can perform lazy load pagination, and filtering and sorting on server side. If I need to implement my own solution thanks to the teams that made client side sorting and filtering, they are useless", to which the answer came "No, there isn't. Because the component library cannot know what will be the persistence mechanism.". Of course that dated from 2010...
Taking a look into Primefaces user guide 3.5, it apprears that sorting/paginator/lazy loading can cohabit, but that's more elaborte then just adding sortBy to your columns.
In fact, checking page 144 of the guide, you can see that you need to :
have a LazyDataModel object in your bean ;
Override the load method of this object ;
Bind the value of your datatable to this model.
Doing this, you might have sorting along with lazy loading. Haven't tried it, but this seems to adress your issue.
Best of luck.
I am currently working on a project that I would like to migrate over to RichFaces 4 from version 3.3.3.Final. I was wondering...
is there anything major I should think about or know or think about before migration?
(might be a silly question but...) can you "mix" richfaces 3 with richfaces 4?
One of the main reasons I wanted to make the switch is to use richfaces 4 autocomplete, is there a way to do something like this useing richfaces 3 or would migrating over be the easiest?
I am using JSF.
TLDR: RichFaces reached a richly merited end of life in June 2016. It was a poorly managed catastrophe of a project that deserved no better.
Noting here that the official migration guide is no better than about 30% complete. As a metric on that, I wrote an XSLT stylesheet of 378 lines in 2011 based on the migration guide. I then left the project in abeyance until June 2015 and based on further investigations and getting it working it is already up to 1090 lines. Bearing in mind that any XSLT stylesheet has some overhead, 378/1090 = about 35%.
After you've done what it says in the Migration Guide:
Open the TLD/VLD generated documentation for each component you use in adjacent browser tabs, one for each version, and compare them carefully. There are dozens of undocumented changes in attribute names and purposes, and some attributes have been moved from parent containers to child containers.
There are also important things that have just been arbitrarily removed, such as rich:page and rich:layout.
I'll provide a list of some of the extra things I have discovered at the end of this.
You will then be confronted with the unpleasant realization that they have also changed large numbers of their own style class names, so if you've defined styles for any of those in your own style sheet you have yet more work to do.
You will also discover that their claim that you can define your own style classes and specify them in the rich components to implement your own styles is simply untrue. Your style classes are applied at a containing level but in many cases such as table cells they have seen fit to define fonts etc at the table cell level, where the only way you can override them is by redefining their cells styles by name.
You also have to ensure that your stylesheet is included after the Rich Faces ones. In 3.3 this was automatic, as theirs were included first. Theirs are now included last, so you have to use h:outputStylesheet and do so as late as possible, to ensure it is generated afterwards.
I used an XSLT transform to implement the Migration Guide and accomplish 1-2 above. It presently has over 1000 lines and I have by no means finished yet. Why they couldn't have provided such a thing themselves is a mystery to me.
Why it was deemed necessary to make such major changes between release 3 and 4 is another and deeper mystery. It is a very poorly managed product. I won't be migrating it again, or deploying it anew.
EDIT Undocumented changes I have found (using XPath syntax for brevity):
a4j:status
The documentation is vague on the point, but the for= attribute has been removed: it now operates by default within the nearest parent a4j:region, unless there are tie-ups to specific widgets via the status= attributes. So if you have multiples within the same region they will now all fire.
If you want it to apply to a specific widget via status= you have to change the corresponding a4j:status/#id to an #name attribute.
After you fix all that, it still doesn't work:
An a4j:status with #for (removed) attribute won't stop
with an #name attribute and no #id won't do anything
and with both #name and #id won't stop.
rich:column/#breakBefore now breakRowBefore
rich:page removed.
rich:layout removed.
rich:column/#sortOrder now must be lowercase.
rich:dropDownMenu/#value now rich:dropDownMenu/#label
rich:dropDownMenu/#direction and rich:dropDownMenu/#jointPoint
The values for these have been changed from {top-left, top-right, bottom-left, bottom-right} and {tl, tr, bl, br} respectively to {topLeft, topRight, bottomLeft, bottomRight}.
rich:contextMenu/#submitMode, rich:dropDownMenu/#submitMode, rich:menuItem/#submitMode
These are now all now rich:<whatever>/#mode, and the value "none" needs to be changed to "client".
rich:isUserInRole
This has simply ceased to work, at least for me, with Mojarra 2.2.08 and EL 2.2. Fortunately with EL 2.2 you don't need it any more and can use request.isUserInRole(...).
rich:menuGroup/#value now rich:menuGroup/#label.
rich:tab/#label now rich:tab/#header.
rich:tab/f:facet/#name[.='label'] now rich:tab/f:facet/#name[.='header'].
rich:tabPanel/#activeTabClass, rich:tabPanel/#contentStyle, rich:tabPanel/#disabledTabClass, rich:tabPanel/#inactiveTabClass, rich:tabPanel/#tabClass
Now tabActiveHeaderClass, tabContentClass, tabDisabledHeaderClass, tabHeaderClass, tabInactiveHeaderClass, tabContentClass respectively.
rich:tree/#adviseNodeOpened
This has been removed and rich:treeNode/#expanded added. This is not well documented: it must be an EL, e.g. "#{true}", not "true", and it can be a bean property of the tree node, e.g. "#{node.expanded}", or of any other bean; must be a boolean. (The same is true of the new rich:collapsibleSubTable/#expanded attribute.)
rich:tree/#nodeFace now rich:tree/#nodeType.
rich:tree/#switchType now rich:tree/#toggleType and possibly rich:tree/#selectionType.
rich:tree/#treeNodeVar now var, or possibly just removed.
rich:treeNodesAdaptor
now rich:treeModelAdaptor, and no longer handles arrays, nodesets, ... or anything not a Map or Iterable. It has also lost its var attribute, which as far as I can see breaks it completely for nested use. The only var attribute now available is that of the ancestor rich:tree. So for example if you wanted the parent node and the current child node at the same time, they are simply not available. This change entails either a non-trivial rewrite, or the following kludge.
OLD:
<rich:tree>
<rich:treeNodesAdapter var="vm_host">
<rich:treeNode .../>
<rich:treeNodesAdapter var="vm_guest">
<rich:treeNode .../>
</rich:treeNodesAdapter>
</rich:treeNodesAdapter>
</rich:tree>
NEW:
<rich:tree ... var="node"> <!-- Add a 'var' attribute -->
<rich:treeModelAdapter>
<c:set var="vm_host" value="#{node}"/>
<rich:treeNode .../>
<rich:treeModelAdapter>
<c:set var="vm_guest" value="#{node}"/>
<rich:treeNode .../>
</rich:treeModelAdapter>
</rich:treeModelAdapter>
</rich:tree>
You could also use <ui:param> instead of <c:set>.
The conversion process is made a lot more difficult by RichFaces' refusal to error-check attribute names. You can continue to use the old names, but they just don't work. Silently.
is there anything major I should think about or know or think about before migration?
Their recommendation is to follow their own RichFaces 3.3.x - 4.x Migration Guide — which appears to be far from complete, see EJP's answer below for the real experience.
(might be a silly question but...) can you "mix" richfaces 3 with richfaces 4?
No, you can't. It would conflict with itself.
I have one searched arraylist that i am getting from Database for that array list i want to apply paginataion with links First, Prev, Next, Last and Goto page dropdown here i don't want to call database for every request(i.e First,Prev,etc) i want to use arrylist that returned at the time of search.And one more requirement is field level sorting need to do Ascending,descending if user clicks on header field.can any one help me to fix this i want to use only JSF2 no RichFaces,etc
Thank in advance.
Why do you not want to use rich or prime faces or others? Just use primefaces datatable with paginator="true".
If you don't want it, but want to do it the hard way. I suggest you fetch everything from database. Use a datatable and in the getter of that table, you only give back a portion of your array. (index 10 to 20, or index 20 to 40 or...)
On top or bottom of your datatable you put some outputlinks. These can set the indexes you want to retrieve.
Hope my explanation is clear.
In case Myfaces Tomahawk is an option for you...
I see it (Myfaces Tomahawk) as a bit different from PrimeFaces/Richfaces cause MyFaces are responsible for the MyFaces JSF Implementation as well (so it could be an excuse for using Myfaces Tomahawk), so you can use the Myfaces JSF implementation + Myfaces Tomahawk
Take a look at the Myfaces Tomahawk datascroller
Here's the situation:
In a rich:dataTable in an a4j:form, i create a a4j:commandLink to select the values and pass it to the bean with the jboss el action syntax
action="#{bean.myaction(myparameter)}"
This works without problem.
But If I re-render the form to filter the datatable with an ajax call, when I select the value, it gives me the wrong results: the index from the selection, but the data from before the filtering.
Any ideas?
Thank you Zack for giving me the right solution in only 5 minutes.
I think passing parameter in the action between parenthesis is more elegant but, hey: this works. :)
Thank you a lot.
P.s. I'm editing the title too.
Try using:
<a4j:commandLink action="#{bean.myaction}">
<f:param name="myparameter" value="paramValue" />
</a4j:commandLink>
and then access that parameter in your action via the requestParameter("myparameter") through the FacesContext.
As a side-note, this isn't jboss EL, it's unified expression language (EL). It's just a feature of JSP/JSF in general, as specified by Sun.
In addition to the Zack's answer, I would say that if you need to extend the EL expressions in order to have the ability to call method with parameters, you can use the EL Functors library:
action="#{bean.myaction$[myparameter].action}"
Is your datatable populated using a Collection annotated with #DataModel ? If so try removing it from the context when filtering so that it gets re-requested.
eg.
//In filter method
Contexts.removeFromAllContexts("yourDataModelCollection");
Putting the dataTable in a <a4j:region> worked for me. This way, you can still use JBoss EL parameters.