I m using Bootsfaces0.9.1. When i try to use the bootsfaces datatable as suggested in showcase, i am not able to use b:dataTableColumn tag. It says that the "value" attribute is not defined in b:dataTableColumn tag.
<b:dataTable value="#{bookingAdminController.itemsBookDet}" var="items">
<b:dataTableColumn value="#{items.}"
</b:dataTable>
I am not able to access "items" in value attribute.
Actually, that's a bug (or feature) of Netbeans. The application works, but your IDE shows an error (or a warning). Either use BootsFaces-0.9.2-SNAPSHOT (see issue #369 on the BootsFaces GitHub repository to see how to get it), ignore the squiggly lines or use another IDE. You can also use the standard h:column tag, but in this case, the other attributes aren't supported by your IDE.
There's also a (solved) bug report on the BootsFaces bug tracker which addresses the problem.
Please note that the snapshot version is a developer preview. Don't use it in production.
Related
In my project I have to implement a page which use primefaces v6.1 but other pages are written in primefaces version 3.
Its hard to update versions for other pages, on the other hand i dont want to use v3 for the new page.
First i have a idea; manipulating primefaces-p.taglib.xml which is in META-INF,
<namespace>http://primefaces6version.org/ui</namespace> . Try to use in the xhtml page:
xmlns:p="http://primefaces6version.org/ui" and components now can be in primefaces 6 versions! But its not worked, i dont know why.
Is there any idea how to use different primefaces versions in same project?
This is not easily possible and would require a lot of work. It would e.g. require fully refactored (classes renamed etc) version of PrimeFaces including everything in the taglibs and more. You could try just creating a customized PF version for just the datatable, but personally I'd bite the apple and upgrade the application.
I have not lot work experience with PrimeFaces. I have to migrate a java web PrimeFaces project from 3.4 to 5.2. Although I searched it all over the internet there was not proper solution for my situation. If you ever have any experience with this kind of problem or ever heard of that please let me know or send me link for that. Basically I want to the way of doing it. I already have idea about witch component should be changed. Is there anything to do except replacing the jar? I already tried to replace PrimeFaces 3.4 with PrimeFaces 5.2 jar. But it does not allow me to replace the jar. Do I have to to change the code too? Please i want the migration steps.
There is a PrimeFaces migration guide. you need to go step by step to get from 3.5 to 5.2.
Here is the full migration guide for your situation:
Copied from MigrationGuide
3.4 to 3.5
Component Changes
DateSelectEvent, ScheduleDateSelectEvent, ScheduleEntrySelectEvents classes are removed, use SelectEvent instead.
Column class in SortEvent and ColumnResizeEvent is replaced with UIColumn to support dynamic columns.
Scrollable and Resizable DataTable-TreeTable features are reimplemented. DataTable and TreeTable no longer render cell container div element with classes ui-dt-c and ui-tt-c.
Sheet component is removed as it duplicated functionality of DataTable. Galleria is reimplemented.
General Changes
IE7 support is phased out.
3.5 to 4.0 Component Changes
MenuModel is rewritten and not backward compatible with the old version.
(skip this when e.g. directly migrating from 3.x to 5.x, it is 'reverted' again in 5.0) DataTable sortBy and filterBy expressions require the plain property name meaning "name" instead of "#{person.name}".
Backward compatibility is maintained for expressions like
"#{var.property}" but not for complex expressions.
FileUpload is reimplemented and it is backward compatible except "showButtons" option is removed.
disabledSelection option of column, moved to DataTable, change is backward compatible and the option will be removed from column in a future release.
AutoComplete: removed process/global/onstart/oncomplete in favor of "p:ajax event="query" process/global/onstart/oncomplete"
General Changes
Preferred way of accessing widgets is via PF('widgetVarName').show(), old way (e.g. widgetVarName.show())
is still supported and will be removed in a future version.
4.0 to 5.0 Component Changes
Chart components are deprecated in favor of new generic chart component with new Chart API. Old chart components are still supported but will be removed in a future release.
ToolbarGroup deprecated, use left and right facets of toolbar instead. (Reverted back as of 5.0.1, both facets and toolbar groups will be supported instead)
Defining fields in sortBy-filterBy attributes is deprecated use a value expression instead.e.g. sortBy="#{user.name}" instead of sortBy="name"
DataTable frozen rows feature take an integer value instead of a collection from now on. This value defined how many rows from the start should be frozen.
LazyDataModel's filters parameter changed to Map instead of Map as a requirement of the new Advanced
Filtering Feature.
Dialog: appendToBody was removed in favor of appendTo="#(body)" to gain more flexibility
Watermark: forElement was removed in favor of for="#(yourSelector)".
Widgets must be referenced via "PF". e.g. PF('widgetVarName').show() instead of widgetVarName.show();
DataTable layout changed to table-layout:fixed.
PrimeFaces Push is reimplemented, PushContext is deprecated, use EventBus instead along with the new Push API.
ScrollPanel is reimplemented, usage is backward compatible however UI is slightly different.
5.0 to 5.1
Support for literal texts in filterBy-sortBy expressions were deprecated in 5.0 and it is removed in 5.1. These attributes only work with value expression as in the past.
Deprecated chart components are removed.
You can't directly migrate from 3.4 to 5.2.
There are some steps given to migrate in MigrationGuide. Perhaps you could first migrate from 3.4 to 4.0 there are some components changes on DataTable, DateSelectEvent, etc. Then you could proceed with 4.0 to 5.0 migration which involves more changes in LazyDataModel's and some of componets. Please go thought link given for MigrationGuide above.
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'm having the following issue with the OpenNTF Bootstrap4XPages plugin: the NamePicker control uses a the Bootstrap renderer which displays it without the search field or the "add" field. I have raised this an issue on OpenNTF but in the meantime, I figured I would attempt to apply the ExtLib renderer for this control.
To date I have tried adding "com.ibm.xsp.extlib.OneUINamePicker" directly to the Renderer-Type property on the control (didn't work), added a renderer property set (taken from the ExtLib source) to the faces-config.xml (didn't work) both with theme enabled and disabled on the control.
So my questions are a) is this possible and b) if so, what am I doing wrong?
Thanks to Tim's comment, I had a moment of clarity in which I realised that I had been an idiot and had overcomplicated matters. I didn't need to worry about changing the renderer-type/adding a custom renderer. The simple answer was just to disable the theme for the NamePicker control which then forced it to use the ExtLib renderer anyway, giving me back the search button and both fields, albeit without styling.
The issue only occurred with the Bootstrap 3 themes. In the Bootstrap 2 themes, the correct renderer class was used.
I traced this down to a bug in the ExtLib theme file for Bootstrap 3. I've fixed it in the source code by setting the correct renderer class, so this will be solved in the next release.
See also: https://github.com/OpenNTF/Bootstrap4XPages/issues/59
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.