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.
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.
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.
Is it possible to make <t:tree2> tree node selectable? I would need to select a node, and based on this selection to print out certain info on the page.
The Myfaces Wiki - Tree2 says
"Almost any type of JSF component (text, image, checkbox, etc.) can be rendered inside the nodes"
So I guess you you can place a button for example and use it for interacting and showing the needed data
I haven't worked with Tomahawk nor its tree2... but I think whatever i suggested would work for any tree... Also.. i'm not so sure that Tomahawk is the library to be used for fancy web app... You should check primefaces component library its for JSF 2 and its showcase is amazingly BIG and RICH... take a look at their tree , it got all you ever wanted and event more
PRIMEFACES Tree - Single Selection
PRIMEFACES Tree
I'm loving the jsf 2.0 composite component setup. One other thing I love is prependId="false" on forms. Is there an equivalent that can be defined in cc:interface or cc:implementation that will prevent jsf from creating a j_id to prepend to the ids defined within the composite component?
That's not possible. Just give the component a fixed id instead letting JSF autogenerate one. The same applies on forms by the way. This way you can still select them using CSS selectors.
Or better, just give them a styleClass so that you don't need to select by ID, for the case that this aversion was actually caused by inability to select components/elements by client ID (I don't see other feasible reasons).
I have been involved in JSF + Facelets dev for a month or so. I used composition, insert, define and other tags from facelets. I am finding it difficult to understand what facelets really give me? What are its alternatives ? What is that View Handler technology?I am not able to find good material / online notes on the same. Can someone explain in laymen terms - What it is? Thanks
Facelets is a view technology. Facelets is the successor of JSP. The only alternative as far is JSP, which has almost no seamless support for JSF components. If you leave Facelets aside and step back to JSP, then the real advantages of Facelets will be quickly clear.
You may find my answer in the question useful as well: What is the difference between JSF, Servlet and JSP? Facelets is also covered in there.
Without providing a complete academic background on Facelets, here's what it really gives you:
First, the ability to create reusable HTML code that you write yourself: this is not possible with JSF (pre-v2). Facelets gives you more control over the output of your webpages.
It has been demonstrated in some editors you can preview parts of
your page this way as well, but in reality this is impractical as the
webpage has many states of which only the initial bare version would
be visible in the preview.
If you are going to use JSF for a public website, Facelets are a must
for SEO, considering that with JSF you have no control whatsoever of
what comes out of the standard JSF components.
Second: templating. The ability to define blocks of HTML (read: Facelet compositions) that can be reused using tags such as ui:define and ui:insert.
There are other benefits, but right now you should know that these two are why you are using Facelets over JSF. Also, JSF 2.0 by default contains a modified version of Facelets.
benefits of facelets: http://www.ibm.com/developerworks/java/library/j-facelets/