ui is undefined jsf primefaces - jsf

I have a problem with using primefaces autocomplete component. When triggered ia get the error $ui. is undefinded and the backing bean is not even called.
My code is:
<p:autoComplete completeMethod="#{auto.uliList}" value="#{naroc.ulValue}"></p:autoComplete>
Big thanks for any help!

This is recognizeable as a jQuery / jQuery UI conflict.
PrimeFaces ships with jQuery and jQuery UI libraries by itself already. If you have manually included jQuery and/or jQuery UI by a custom <script> or <h:outputScript>, then it would only conflict with PrimeFaces-provided ones and result in this kind of "foo is undefined" errors. You should remove your manually included jQuery scripts from the page (and your webapp) and rely on PrimeFaces-provided ones instead.
If you have pages which don't necessarily use PrimeFaces components (and thus its bundled jQuery scripts won't necessarily be auto-included on every page), then you need to explicitly specify PrimeFaces own jQuery instead:
<h:outputScript library="primefaces" name="jquery/jquery.js" />

I just managed to resolve my problem.
it was quite simple but effective. So if you come up with a prolem similar to mine just add this code to your page head:
<h:outputScript target="head">
jQuery.noConflict();
</h:outputScript>

Related

How to include pages in a JSPX and Trinidad project in run-time without breaking the JSF lifecycle?

I am struggling to figure out a way to include dynamically determined pages in run-time in a JSPX and Trinidad project. You will have an idea when you see what I have, which is:
<tr:panelAccordion>
<tr:showDetailItem
text="Test tab">
<jsp:include page=".test.jspx" /> <!-- This part is working fine -->
</tr:showDetailItem>
<jsp:scriptlet>
BackingTest backing = (BackingTest) session.getAttribute("backingTest");
for (CaseTabConfigurationDTO tab : backing.getTabs()) {
java.io.File f = new java.io.File(request.getRealPath(tab.getPagePath()));
if (f.exists()) {
pageContext.include(tab.getPagePath(), true);
}
}
</jsp:scriptlet>
</tr:panelAccordion>
jsp:include part is working fine, nothing is breaking the JSF lifecycle.
jsp:scriplet part is successful for including the correct pages. However, it is breaking the later actions in JSF lifecycle including still persisting backing beans of dialogs opened using useWindow="true".
In order to be make it complaint with Facelet, thus not breaking JSF lifecycle. I tried using tr:forEach, c:forEach, ui:include, ui:repeat approaches without any luck of actually including pages.
Can you share a proper solution for it? Thanks in advance!
You probably want to reconfigure your project so you can use Facelets with Trinidad. After reconfiguring your project can use Facelets for templating. You will end up using xhtml instead of jspx though.
See also:
When to use <ui:include>, tag files, composite components and/or custom components?
How to include another XHTML in XHTML using JSF 2.0 Facelets?

reRender via JS API

I was wondering if there is any JS function in jsf/richfaces which does the same functionality as that of reRendering a component.
Also will the reRender work on any component which has display:none style?
You could use a4j:jsFunction with 'render' set. Then from javascript call the jsFunction and the render will be done. I think that render does not check the display style setting.
<h:form>
<a4j:jsFunction name="render" render="componentToRenderId"/>
</h:form>
<script>
render();
</script>
MAG,
Milo van der Zee
I assume you are using RichFaces 3.x because you are using jsf-1.2.
If so, you can use the component as 'Milo vd Zee' showed but your attribute should be changed as "reRender" instead of "render".
For Richfaces 4.2 "render" attribute is ok.

How to not render whole block in JSF?

Is there a JSF 2.1 component which lets me conditionally render (or not render) all its content? Something like
<h:component rendered="#{user.loggedIn}">
...a bunch of jsf components and HTML code...
...even more HTML code...
</h:component>
I am using PrimeFaces 3M4 as this may influence your answer!
<h:panelGroup>
If you set attribute layout="block", you will have a <div> tag
Otherwise, you have a <span> tag.
In general most of jsf components support the render attribute (never bumped in some that does not),
container components like h:panelGrid or h:panelGroup supports the rendered attribute and if its set to false all its child will be hidden too
Same goes for the primefaces components ,and if not it probably a bug (i think there was an issue with tabview of primefaces)
Here's a link for primefaces user guide, you can find supported attributes of all primefaces components there User’s Guide for 3.0.M4

how to generate dynamic rich:panelMenu?

i have a problem to generate dynamic menu, i'm using JSF1.2. I tried the c:forEach with an arrayList to generate dynamic rich:panelMenu as BalusC advised in a related forum, but get Accessor never triggered in c:forEach. it ruined me a day. can anyone provide me a solution ?
<c:forEach items="#{serviceListBean.services}" var="child">
<rich:panelMenuItem mode="none">
<h:outputText value="#{child.serviceId}"></h:outputText>
</rich:panelMenuItem>
</c:forEach>
what's wrong in this code? can anyone enlighten me?. For info, serviceListBean is request scoped bean.
Two possible causes:
JSTL is not declared as taglib in JSP or Facelets. To confirm this, rightclick page in browser and choose View Source. Do you see <c:forEach> tag unparsed among the generated HTML? If you're using JSP, declare it as follows:
<%#taglib prefic="c" uri="http://java.sun.com/jsp/jstl/core" %>
Or if you're using Facelets, declare it as follows in root element:
xmlns:c="http://java.sun.com/jsp/jstl/core"
On some servers like Tomcat, which doesn't ship with JSTL out the box, you would also need to install JSTL first, see also this info page.
This piece of code is in turn been placed inside a JSF repeating component, like <h:dataTable> with a var="serviceListBean". This is also not going to work. You would need to replace the JSF repeating component by <c:forEach> as well.

JSF and PrimeFaces Strategy

What is or could be a best practice?
Using standard JSF components and combine them by PrimeFaces components when needed (for example when DHTML or AJAX components are needed)
Forget all JSF Components and try to use all PrimeFaces components as much as possible
Please explain it and tell me about your experiences.
Thanks in advance...
PrimeFaces is your AJAX framework, so if you need to send ajaxical request, then use PrimeFaces components.
Even though, you dont need to send ajax request, but you can still use PF component, if u need to provide a consistency look for your web page. For example, h:commandButton and p:commandButton. Use p:commandButton if u need to send ajax request, but u can also do this
<p:commandButton ajax="false" action="Your Action here"/>
This will provide the same result as:
<h:commandButton action="Your Action here"/>
but this way, you can provide the same consistent look for your button throughout the page.
PrimeFaces does not have replacements for h:panelGrid, h:panelGroup, h:inputText, h:outputText ...
Depends on the sole functional requirement. If you're already using PrimeFaces and whatever you want to achieve can better/easier be achieved using a PrimeFaces component, use it.
Option 1 comes close, but option 2 goes overboard. PrimeFaces for example doesn't have a <p:form>, <p:panelGroup>, <p:outputText> or something.
With Primefaces it's very easy to get a consistent look for your application since it comes with Themeroller CSS framework. And you can easily switch designs. Although it is not difficult to let plain jsf components look like primefaces components if you apply the right css classes.
I think primefaces is a great component library. However some components are still buggy (e.g. date picker). So if you get some unexpected behavior with a primefaces component, it is alway good to have a jsf fallback (or an alternative from another component library or from jquery).
I have no experience with mixing different component libraries. Would be interesting to know, how they interact. But that would be subject of another question ...

Resources