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.
Related
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.
Short Version:
If two JSF library jar files both include a custom renderer for the same family and type, is there any way from within the library itself (i.e. not from the containing app) of specifying which one should be used? Something like assigning a priority, with higher ones used in preference to lower ones?
Longer Version:
I'm using Primefaces in a project and trying to override the provided head renderer with my own:
<render-kit>
<renderer>
<component-family>javax.faces.Output</component-family>
<renderer-type>javax.faces.Head</renderer-type>
<renderer-class>com.example.MyHeadRenderer</renderer-class>
</renderer>
</render-kit>
If I put that into the WEB-INF/faces-config.xml of the war file then it's all good, and my renderer gets used.
However, if I try to deploy my code as part of a library jar (my-utils.jar), with the renderer defined in META-INF/faces-config.xml, then the Primefaces one is used. This contains exactly the same definition, so I'm guessing it just depends on the order they get loaded. Indeed, renaming my library to "xx-comps.jar" works, so it would appear that JSF is loading faces-config.xml files from all jar files in alphabetical order, with later entries just overwriting earlier ones.
Is there any way of forcing the selection to my library?
So far, I have these options:
Put my renderer directly into the WEB-INF/faces-config.xml of the war.
Build a custom Primefaces jar with that one renderer definition
removed.
Rename my library and rely on some (undocumented as far as I can
see) behaviour from the JSF loader.
Add a custom renderkit which extends the standard one, and reference
that from my war WEB-INF/faces-config.xml.
The first three all work but are not ideal, as (1) and (2) require changes outside my library, and (3) just looks dodgy as hell....
The fourth is just an idea as I've never written a render kit before so not aware of the effort involved. No idea if it is practical or would work, but it is better than (1) because at least the application only references a single render kit, and does not need to be updated if/when new renderers are added. Happy to put more effort into researching this approach if it seems a reasonable solution.
Also, I'd ideally prefer to use annotations rather than XML:
#FacesRenderer(componentFamily = "javax.faces.Output", rendererType = "javax.faces.Head")
public class MyHeadRenderer extends Renderer {
...
}
Thanks
You can specify the ordering via <ordering> in faces-config.xml of the JAR.
E.g. if you want your utility library to be loaded after all others, then just do so:
<ordering>
<after>
<others />
</after>
</ordering>
If you want to force an explicit ordering, then hook on specifically PrimeFaces, which has a <name>primefaces</name> in its faces-config.xml:
<ordering>
<after>
<name>primefaces</name>
</after>
</ordering>
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 am using seam with EJB3 + JSF and I would like to add a tree view component to the UI. The tree view must allow sorting of the nodes (preferably drag and drop) and must allow selection of leaf nodes.
The options I have looked at are:
RichFaces Tree
jsTree
Is there a major benefit to one option over the other?
If I use jsTree, what is the best way to connect to my data in EJB3? Should I use RESTEasy , Java script Remoting, or some other way?
I would use Richfaces tree as you are already using JSF becuase in this way everything is pretty much integrated and you wouldnt have to "wire" all the requirements manually.
The major benefit with richfaces is that everything is already there so the development time is shorter.
I noticed that c:set does not work well used inside "include of include of include", as important notice facelets documentation does't recommend it too.
Now I am using ui:param inside ui:include, but it is a bit dispersive when no attached notes about params comes with the include, is there something other way to declare "global vars"?
This is really a matter of trying to fit old JSP programming into the JSF framework. You should be using backing beans to hold your data.
If you try to hard-code data directly into your xhtml file, you are defeating the purpose of JSF's MVC framework. If you have a specific example of what you are trying to do, I could give you a specific recommendation.