I'm looking for Java "Faces" that supports RTL (Right To Left) user interfaces. The only library that I've checked so far is RichFaces. It seems that it doesn't support it natively.
What is a good resource that talks about this issue?
What other "Faces" can be recommend that natively support RTL user interfaces?
RichFaces components support the dir attribute.
The JSF standard components already do it since ages. They just supports all of the HTML attribues, including the dir attribute, which you can set to "rtl". I would be surprised if any of the 3rd party component libraries didn't inherit it.
In richfaces, it does support dir="rtl" in all components, yep it does not say you can not set the attribute dir but when you put it on, it will not display correct. To do so, in richfaces you need override its style, replacing left with right and right with left, i have checked it for simple components but for others like tree, like menu it would not be easy as i say. I have no idea what other components would support that.
btw i speak for 3.1.5. GA.
I didn't used it on my own, but was just googling about it and wikipedia states it might be candidate:
http://myfaces.apache.org/trinidad/
Related
Regarding the <composite:interface> tag for JSF composite components, what is the use of the "expert" property of the (interface tag](https://docs.oracle.com/javaee/7/javaserver-faces-2-2/vdldocs-facelets/cc/interface.html)?
The description is awfully vague and I found no references to its use or documentation online.
What is its purpose and usage?
I've scanned the Mojarra source code. It's ultimately set in java.beans.FeatureDescriptor class.
But it's in turn not really anywhere used.
With this I conclude that it's just unused inherited logic. The same applies to dislayName, shortDescription, hidden and preferred attributes. Only the name and componentType are actually concretely used.
The unused attributes are at most only used by tooling such as IDEs like Eclipse and Netbeans so that they can parse and show the right labels and tooltips here and there when working with (custom) composite components.
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.
when using CombinedResourceHandler in a Richfaces application only stylesheets and user defiend scripts are combined. The standard JavaScript resource and all Richfaces specific resources remain as seperated resources.
The Omnifaces documentation states:
RichFaces has the same problem with several JS files, but this is so far not exactly trivial to workaround
So my question is what this 'non-trivial workaround' would be?
As far as I can see, CombinedResourceHandler wont handle resources when getRendererType() returns org.richfaces.renderkit.ResourceLibraryRenderer. These are then handled by org.richfaces.renderkit.html.ResourceLibraryRenderer.
I am not sure what would be the best way to combine RichFaces behaviour with OmniFaces here.
I was able to create a solution by modifying OmniFaces CombinedResourceHandler.
Details in short:
Richfaces utilizes a concept called ResourceLibrarys wich means a resource may not only be a single file but instead a collection of those files. For example, RichFaces uses a resource named base-component.reslib. RichFaces ResourceHandler interpretes this resource dependency as dependency to
javax.faces:jsf.js
jquery.js
richfaces.js
richfaces-base-component.js
So the CombinedResourceHandler needed some extra functionality to seperate dependencies to ordinary Resources from Richfaces ResourceLibraries. The latter needed to be resolved according to specifications obtained from RichFaces sources.
It was not trivial to work this around without modifying the CombinedResourceHandler itself. The CombinedResourceHandler itself has really to be modified to use a reflection hack which extracts the resources from RichFaces' org.richfaces.resource.ResourceLibraryFactoryImpl. The reflection hack is necessary in order to keep OmniFaces free of RichFaces dependencies so that it can be used together with other component libraries like PrimeFaces.
As per issue 107, this was implemented in 1.3-20121206.
I have links and pictures related to these links on my page. I want to change the pictures everytime when onmouseover event occurred in the links. I want to do this in JSF.
A lot of Thanks to everyone.
You are looking specifically for JSF to do it, or you are open to other Javascript frameworks that provide a slick and easy solution on this? For example Jquery and Dojo etc may be easy to incorporate in your application and will give Rich UI effects.
On the other hand if you are looking at JSF specifically for these UI effects than probably I can try to think of some ways and let you know.
JSF isn't designed directly to do this; It's designed to give you the tools to do this yourself. In order to do this you would need to create a custom JSF component to do this and you would use Java script to do it.
You could possibly find a JSF framework that does this already (a4j, IceFaces, etc.) but this is such a simple and well documented JavaScript thing that just tossing a little Java script among your JSF is perfectly acceptable. However, if you don't want to reinvent the wheel, take a look at those other options.
Javascript solution:
Define onmouseover event on the commandLink tag calling some kind of javascript you may give link address from like onmouseover="doSomething('addressOfImage')" then in doSomething javascript method, first find the image, then set src attribute of a default image to given address.
JSF Solution:
You might want to use a4j for this.
Add a4j:support to link for onmouseover event then just rerender graphicImage component ofcourse you need to give value of graphicImage dynamically. There is an example of using a4j support below. You can add this a4j:support between your link tags for mouseonover event. Then manage everything on backing bean to handle which image to be displayed.
example
<h:graphicImage id="imageToBeRendered" value="#{myBean.imageAddress}"/>
Just google a4j if you have no idea.