I'm implementing file uploading using Richfaces version 4.0. I've noticed, that there is quite a big differences between rich:fileUpload component in version 3.2 and the one in the latest version. As I see, there aren't possibility to set automatic uploading or limit number of downloaded files. I can't set auto clear option as well. Am I right? Could you point the reason of this or suggest a solution?
Thanks in advance
The maxFilesQuantity attribute was added as part of RichFaces 4.1.0.M3 (see RF-10996).
At the time of this answer, RichFaces 4.1.0.M4 is already available, so I'd recommend you use that instead.
If you are stuck on RichFaces 4.0.0.Final until 4.1.0.Final is released, you could use a fileUploadListener to count the number of files uploaded, and limit it that way.
The main reason is that RichFaces guys have spent enormously a lot of time in migrating the component library from JSF 1.x to JSF 2.x. So some things have to be prioritized. In order to be "in time" with a JSF 2.0 compatible component library (to prevent users from changing the component library to another JSF 2.0 compatible one such as PrimeFaces; PrimeFaces for JSF 2.0 was already out half 2009 while RichFaces for JSF 2.0 was out by end of 2010 only, more than one year later!), they have scratched some hard-to-implement and/or least-used features for RichFaces 4.0 and postponed them for RichFaces 4.1 or later. The Flash-based <rich:fileUpload> was one of them. It does now not use Flash anymore, but plain HTML/CSS/JS and hence the capabilities are very minimal.
Currently there are several rich:fileUpload feature and enhancement requests open for RF 4.1. There are plans to let it utilize HTML5 and XHR2 powers in the future.
Related
We have a java wicket 1.4 application not so large, but now we need to integrate bootstrap 4 to it. Consulting the apache wicket site, we see a integration come since wicket 6.0 version but it is not supported for older versions.
Having project time considerations, We have two alternatives: First, migrate from 1.4 to 1.5 and then to 6.0, this to support the "native" integration, or second, to include bootstrap in the html head instead of the html generated directly from wicket.
The first one is probably the best option but could imply a great effort. The second one, is not a clean solution but could be a temporal one.
Do you know which implications or potential issues could be arise both alternatives?
I guess you want to use https://github.com/l0rdn1kk0n/wicket-bootstrap because Wicket itself doesn't provide anything special for Bootstrap. The "problem" here is this library does not provide integration with Bootstrap 4 (https://github.com/l0rdn1kk0n/wicket-bootstrap/issues/540) because v4 is "almost ready" for about 3 years now.
I'd suggest you to use the second approach.
Updating to a newer version of Wicket would be good anyway! Ignoring the new features and the bug fixes there are several security fixes which might or might not affect your application.
Use the second approach - add the bootstrap.css to your html head and use bootstrap classes manually in your html. Just use standard Wicket. Some bootstrap components like Slider, Progress Bar, Datepicker and Modal we have implemented as components on our own.
This gives you full control and free's you from external libraries which are not updated in time, not compatible with other frameworks/versions and so on.
We are happy with this approach and avoid this way the problem you have.
I am looking forward to using a component library(perhaps richfaces or primefaces) with JSF for developing the frontend of a social application.
I need to know:
1.) how far is it possible to customize the look of each individual component independently besides choosing a single theme for all components. Is it possible to use CSS with these components.
2.) Can I use multiple component libraries (depending on what components I need) in a single project?
3.) Any suggestions on choosing a component library also welcomed!
EDIT
4.) Are there any visual editors for developing UI with these libraries? I currently use netbeans 6.9 IDE.
I know it's possible with RichFaces
Yes, it's possible. Most probably you have to customize at least one of them to get a consistent layout. For some libraries there exist already such themes, e.g. you find some themes for Primefaces with Richfaces look and feel.
We decided to use RichFaces which provides various well documented
components. Look at the examples of
your library candidates and decide
if they might fit your needs.
Richfaces:
http://livedemo.exadel.com/richfaces-demo/richfaces/modalPanel.js
Primefaces:
http://www.primefaces.org/showcase/ui/home.jsf
Apache MyFaces Trinidad:
http://myfaces.apache.org/trinidad/index.html
I love Primefaces as they have a probably the largest and some of the most feature rich components available. It takes a litle tweaking but you could use other component libraries with Primefaces as well.
Be prepared though for a lot of issues. There are a lot of bugs however if you are decently good with javascript and CSS and have above a beginners level understanding of JSF then you should have no problems working around them. Just be prepared to implement a couple of smelly hacks to meet some requirements.
Despite these problems I notice it becoming more and more stable with every release so it will only get better from here.
I use primefaces, and customizing each component is pretty easy and fun. They have samples in their user-guide on how to customize each component (css). Primefaces relies heavily on jQuery(I noticed by looking at the source generated), but also uses other javascript libraries like YUI. Sometimes it could be very Javascript intensive on the client, but so far, it does what is says it do very well.
I am not sure about the multiple components, never tried it, and per my own recommendations, I think primefaces rocks.
AS from netbeans 7.0, primefaces is included in Netbeans, so you don't have to worry about configurations anymore.
See that you got some answer already. I had more or less the same questions as you have. In the end I went for Richfaces, because the following points
Better integrated with the core JSF 2.0 libarary and has more or less the same monoculture.
No payload on bandwidth, when not using any Richfaces component, this will happens if you use Primefaces. Because the jquery and CSS will always load, whenever you using a component or not.
The documentations is bit more comprehensive. But the Primefaces forum is more active and you'll get a better feedback
The bandwidth was the key point for me, so I picked Richfaces. But I like the Primefaces library too, since the verity of components is greater.
Before I delve into JSF 2.0 I want to clarify my understanding of JSF 2.0 by finding answers to the following:
What are the differences between the reference implementation and MyFaces?
Can jsf 2.0 with either reference implementation or MyFaces be deployed on any servlet
container, i.e. tomcat/jetty, or must it be deployed only on a Java EE compliant container?
How difficult is it to create custom tags? For example a pagination link tag, similar to what is available in Grails?
Is it possible to use *Faces (i.e. PrimeFaces, RichFaces, etc) with a javascript library like jquery or yui? Are any conflicts created by doing so?
1: What are the differences between the reference implementation and MyFaces?
They are developed by different teams. Since both are supposed to adhere the JSF 2.0 spec, there ought to be no differences with regard to the base functionality as specified in JSF 2.0 spec. However, with regard to exposed and fixed bugs, there may be differences. My personal preference is Mojarra (the reference implementation).
2: Can jsf 2.0 with either reference implementation or MyFaces be deployed on any servlet container, i.e. tomcat/jetty, or must it be deployed only on a Java EE compliant container?
Yes. JSF 2.0 only requires a minimum of Servlet 2.5 API. So any Servlet 2.5 compatible container or even Java EE 5 applicationserver suffices. You may only need to disable the builtin JSF 1.2 API in a Java EE 5 applicationserver whenever you want to use JSF 2.0. Or, better, just use a Java EE 6 application server (Glassfish 3, JBoss AS 6, etc) since it already ships with JSF 2.0.
3: How difficult is it to create custom tags? For example a pagination link tag, similar to what is available in Grails?
When using Facelets as view technology (by default used in JSF 2.0), this should be relatively simple with a template or a composite component. Since it's basically just XML, no Java code is necessary.
4: Is it possible to use *Faces (i.e. PrimeFaces, RichFaces, etc) with a javascript library like jquery or yui? Are any conflicts created by doing so?
Even more, both PrimeFaces and RichFaces ships with jQuery (UI) builtin and PrimeFaces also YUI. That's also where they get their fancy look'n'feel and/or special effects from. As to conflicts with own jQuery scripts, just use jQuery.noConflict() to suppress it.
When you're ready to dive in JSF 2.0, I can recommend the following tutorials:
My JSF 2.0 tutorial with Eclipse and Glassfish
Mkyong.com JSF 2.0 tutorials/references
Coreservlets.com JSF 2.0 tutorial
Update as per the comment:
However, could you elaborate on why your personal preference is Mojarra (the reference implementation)?
Because I am an avid user of Mojarra. True, it's subjective :)
Objectively said, MyFaces was the better choice during JSF RI 1.1 times. Less bugs and better performance. However, since the new JSF RI dev team during the JSF RI 1.2 times, a lot was improved/fixed. As of now there are no technical reasons to prefer the one over the other. It's at highest the degree of exposed and fixed bugs (maintenance/support).
Related questions:
MyFaces 1.2 causes Tomcat 6 to crash
Memory leaks in MyFaces 2.0
Intermittent ViewExpiredException in MyFaces 2.0
Mojarra or MyFaces?
Disadvantages of JSF 2.0 (a bit of history)
I would like to do some more learning of facelets. Now that Java is a supported Google app engine language, is there anything in the facelets implementation that would prevent use on App Engine?
Edit: This page at google now has a list of various frameworks and their status in regards to App Engine.
The 1.2 version of JSF was not working - because by default it would try to spawn threads. That's not allowed in GAE.
This is fixed in the latest version of JSF 1.2 (build 13), as well as the 2.0 Beta 2 release - and you can download the latest versions from here: http://javaserverfaces.java.net/
You need to add the a context parameter to your web.xml:
com.sun.faces.enableMultiThreadedStartup which defaults to true. This
option must be set to false when deploying to GAE.
I haven't tried it, but I don't imagine it would be any different from using Struts or Spring. As long as you can deploy with all the JARs you need in your WAR it should work.
The only question is whether JPA or JDO are sufficient. If the facelets require any other persistence mechanism you might have a problem.
JMS isn't available either, so features that depend on it can't work.
Isn't the first access limited? First 10,000 get in?
We are discussing whether it's a good idea to switch from plain portlet development on a liferay installation to spring webmvc portlet based development.
We're starting the development of some portlets soon, so now is the time. But the problem I see is that we'd like to use some of the portlet 2.0 features, which won't work with versions older than spring 3.0. (Right?)
Has anyone insight, if it's worth the waiting? (When is 3.0 scheduled anyway?)
Is the current milestone stable enough?
Our first real release will be in the last quarter of the year, so the springsource guys have some time left to get a final out of the door... ;-)
Any ideas?
UPDATE
So, Spring 3 has been released and it supports all JSR286 features we need. (I think it's a pretty complete support for the JSR286 features)
The only drawback I am seeing is the documentation which is not up to speed in regard to the annotations.
We use Spring Portlet MVC 2.5 on Liferay and we have excellent results. Most of JSR-286 functionality(like events) can be reached be extending DispatcherPortlet class.
There is still a lot of bugs open for upcoming 3.0 release, so I would be rather conservative and stay with stable&mature version 2
The spring framework has an excellent track record of code quality. In the past their M releases were of high quality, so I would not be afraid to use it.
Juergen Hoeller gave Jul 2008 as the estimated release date for Spring 3.0:
http://www.springify.com/archives/15
I think they're late. 8)
Matt Raible lamented the fact in Oct 2008, almost six months ago:
http://raibledesigns.com/rd/entry/the_colorado_software_summit_and
I wonder if the new professional versus open source model has affected availability.
They also have the Spring DM, Spring Blaze, and Spring Integration work going on now.
Given their past history of quality releases, I'd bet that they're resisting the urge to release early in order to make certain the code is up to their standards.
I am just getting to know Portlet MVC with Spring 3.0 M4 and came across a modified PetPortlet sample making use of Spring3 (JSR-286) features and annotations. While it is Mavenized and probably not directly deployable on Liferay, it still provides good examples.
Please comment should you happen to come across any others.