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.
Related
I am trying to connect to a broker that is using FIX 5.0
I would like to leverage quickfixj for ease and speed of implementation.
Is this going to work? I am assuming 5.0 extends (so to speak) the features of prior versions, but I do not want to get too far along and wind up causing more issues than it is worth to use quickfix.
I ask this because the current website says that quickFixJ is okay for versions of fix between 4.0 and 4.4.
Will this still work with 5.0?
Many financial institutions use quickfix and it is quite likely that if QuickFix has an issue with version 5.0 the other end has the same issue as it's pretty standard. BTW You can change the implementation fairly easily, if for example you want to improve the performance. (which is ok, but not great)
quickfixj is generating its classes out of the standard fix dictionaries, so there is no limitation in terms of the framework and from my experience it is very accurate, new releases from 1.5.3 to 1.6 seems to have some issues between 4.x and 5.x compatibility but in general it is quite straight in managing a mix of versions and custom fields, it boils down to the version of reference between the counterparties which applies to every message but essentially on the message level all versions can be woven in / customised
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.
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.
Currently working on a Spring 2.5 web application, looks as if the business has at least a 5+ year plan for it's usage.
There isn't anything in terms of a technology roadmap in place for the app.
Spring 2.5.6 is stable, and working smoothly. Staying with it won't be a mistake.
Spring 3 gives additional features and support for newer JavaEE specifications. I wouldn't say it gives something extraordinary.
I agree with #Bozho's answer. One significant new Spring core feature that isn't mentioned in the page linked is the Expression Language feature, which allows you to do a variety of things in XML wiring files that previously had to be implemented as custom code.
SpringSecurity in 3.0 is a mixed bag. On the one hand, there are new features and improvements to existing ones. On the other hand, they have broken source code compatibility in a lot of areas. People who cannot do everything with the SpringSecurity namespaces and the standard classes may be in for some head scratching, recoding, and in some cases pain.
Spring Roo generates spring 3 based applications. Not immediately applicable to existing apps, but it's great to be able to compare roo's best-practice output, and if you were 3.x based then you could copy roo config / code output into your existing application to get functionality for free.
Given an application using Spring 2.5, when migrating to Spring 3.0 what are the likely areas that will be pain points, i.e. things that the development team will have to spend time on to get things working. Assume the team would not try to take advantage of new Spring features as part of the upgrade, but just get the application to the state where it works as it did on 2.5. Taking advantage of 3.0 features would be the next steps to consider.
Edit: I have revised the question to focus on the pain points of the upgrade, which is what I'm really after.
Probably the biggest change in Spring 3.0 is that it now requires J2SE 5.0.
One of the Spring developers reply for a compatibility question in this blog entry.
Spring 3.0 aims to be 99% backwards
compatible with Spring 2.5. The core
APIs and SPIs will remain stable in
order to keep existing extensions (and
of course also existing application
code) working. Introducing generics
and varargs, as we've done in M1 and
M2, should still preserve binary
compatibility. That said, we generally
recommend rebuilding your applications
for Spring 3.0, in order to catch
potential API issues early. This will
also allow you to get the maximum
benefit from Spring 3.0's Java 5 API
refinements.
If you're lucky, then nothing will need changing, it should all just work. The Spring guys are very careful to retain backwards compatibility.
The biggest reason I can think of for it not working is if you're using code that was deprecated in 2.5, and marked for removal in 3.0 You can find that list here.