JavaFX 2 does not provide validation support (masks, input filtering and so on...). It is difficult to adopt a technology that does not offer basic functionalities. I am trying to implement my own validators, but that is a big pain.
Are there any news in JavaFX 8 about validation? I was trying to find new features, but I don't know where to search, it is difficult to find exactly what will be the changes in JavaFX 8. I need to know about it, because I was considering JavaFX for a new application.
Answer
No, JavaFX 8 will not implement high level validation support.
Opinion
I think it unlikely that comprehensive validation support will ever be in the JavaFX core libraries (this is just my personal opinion).
JavaFX provides a base library upon which other libraries can be implemented. JavaFX 2.2 provides enough support that you could write validation libraries on top of JavaFX (and people have done so).
There are some reasons why you might not want validation support in JavaFX core libraries:
As JavaFX is part of Java SE and the open-jfx project, it must follow the Java release process, which can be quite slow at times for various reasons. 3rd party projects don't have such restrictions.
Things in JavaFX implement just one way of doing things generally, whereas you might wish to have multiple frameworks built on JavaFX, each for different purposes, then choose between the framework which best meets your needs.
Some advanced validation frameworks might make use of things such as Beans Validation, which are currently only part of the Java EE specification. JavaFX is written to work with just Java SE, so the core framework can't make use of anything from Java EE, even though that might be desirable for validation.
Generally, validation is not something done in isolation, but is often part of a wider framework (such as a form filling framework or a complete application platform).
3rd Party Validation Libraries
Some sample 3rd party libraries which perform validation for JavaFX fields are:
JideFX
FXForm2
I was trying to find new features, but I don't know where to search, it is difficult to find exactly what will be the changes in JavaFX 8.
I am sure, when Java 8 is officially released in a couple of weeks, it will come with an announcement summarizing new JavaFX features.
You can find out what all of the new features for JavaFX 8 are by filtering the JavaFX issue tracker on fixed features for Java 8. Here is a link to the result of a JavaFX 8 fixed feature query. Note, the linked query reports only larger features, not minor tweaks.
Related
There are plenty of good addons, developed for vaadin 7 and vaadin 8 non compatible with flow. Searching for solution i found - vaadin docs on MPR (multiplatform runtime) - where LegacyWrapper class is available which provides integration for legacy components into flow engine. The MPR is available for Prime (paid) subscription users only, so does the LegacyWrapper class as well.
Could anybody please give any hints how to make a simple wrapper implementation for using legacy components into flow layouts. I believe, supposed CustomLegacyWrapper class should inherit from vaadin.flow.component and contain (as a composition, maybe?) vaadin.ui.AbstractComponent. How the baseline solution might look like?
Thanks in advance.
I've got an answer to my question on the vaadin forum from one of the contributors that there is no simple workaround for my purpose, integration of old components into flow engine is one of multiplatform features and its not possible to implement it in easy way.
I am working on enterprise-level business applications, and now is the time to start thinking about the non-desktop experience.
We have a common component code-base that is using dojo, and are trying to get as much code re-use as possible.
I am really struggling to determine if I should re-use the same code base, or have separate code bases for desktop and mobile.
A big factor in my decision making is the viabliity of dojox/mobile.
It seems pretty cool, and uses the dojo infrastructure which is a huge win, but the fact that it is in dojox scares me a little.
Some questions:
Is dojox/mobile something that can be relied on long term?
Is it a smart idea to try to swap out dijit components for dojox/mobile components depending on what has.js can tell me?
Will dojox/mobile be a part of dojo2.0?
I would add that in Dojo 2.0 the plan is to converge as much as possible the desktop (dijit) and the mobile (dojox/mobile) widgets which should help in your use-case. See: http://mail.dojotoolkit.org/pipermail/dojo-contributors/2013-June/029041.html
You can rely on dojox/mobile. DojoX will indeed disappear from the Dojo Toolkit in 2.0, but most matured (and probably maintained) modules will be pushed to the dijit/dojo library. I quote the reference guide:
In the future (Dojo 2.0), the DojoX package and namespace will
removed. Sub-Packages and modules will be either integrated into the
Dojo Core, Dijit or separated as their own stand-alone package. For
the 1.X code stream though, in order to ensure backwards
compatibility, all these packages are contained within the dojox
namespace and package.
If we look at the explanation of Mature, we can read the following:
This package or module is considered mature and is being actively
developed and maintained by committers within the Dojo Toolkit. It is
expected that it will persist into the foreseeable future.
Source
And if you look at the link above, you will notice that dojox/mobile is categorized as mature.
Another reason you can rely on it is that IBM (which can be considered a pretty big company and committer to the Dojo toolkit) also relies on dojox/mobile for their mobile product called IBM Worklight. If they rely on it, then there's no reason you couldn't.
I don't think it will be easy to start from the same code base and swap out dijits for dojox/mobile components. Usually mobile app development requires an entire different strategy than web applications. You will probably have to split certain things into multiple views and some dijits may not have a mobile alternative.
You can probably re-use most of your utilities and business logic, but I think you will have to start from scratch again if you want to write your view(s). But I'm not really an advanced mobile developer.
My scenario: trying to port a small part of an application created by our company from native code (ObjC for iOS / Java for Android) to C-Sharp. The project will interact with our webservices. Goal of this project is figuring out how feasible it is to port our whole app to Mono.
To create URLs, I'd like to use String.Format(). I thought it'd be a wise idea to put this 'service layer' inside a Portable Class Library (PCL) since I don't expect this code to change across platforms. Sadly, it seems the String library is not available for PCLs.
So my question is the following:
I think the main advantage of PCLs over "normal" libraries is that they shouldn't need a recompile for different platforms. Is this assumption correct?
This experience makes me think that for the moment PCLs are rather limited. Should I try to stick with PCLs and work around these kinds of issues, or might it be better to stick with a "normal" library for now? --- I'll assume the "normal" library has more functionality exposed.
You can use PCLs currently across many platforms, but it does require some small hacks to your setup.
These hacks are listed in http://slodge.blogspot.co.uk/2012/12/cross-platform-winrt-monodroid.html
Once you've got those working then the functionality available is quite broad - and it definitely includes things like String.Format
For the situations where the PCL profile is not broad enough, then you can use several techniques for extending them - see http://blogs.msdn.com/b/dsplaisted/archive/2012/08/27/how-to-make-portable-class-libraries-work-for-you.aspx . The technique I generally use is to use MvvmCross Plugins - which are basically PCL interfaces with platform specific implementations. But these plugins are generally at the level of 'make bluetooth work' rather than at the level of String.Format
I do lots of PCL work across WinRT, WP, WPF, MonoTouch and Mono for Android - see http://slodge.blogspot.co.uk/p/mvvmcross-quicklist.html for lots of links to PCL work.
It's true that Xamarin have recommended not using PCLs for a couple of years, but that situation has now changed and the official support for PCLs is under way - see http://slodge.blogspot.co.uk/2013/02/the-future-is-portable.html
From a development perspective - especially from the point of view of using refactoring and testing tools - I don't hesitate to recommend you use PCLs now... especially for operations at the String.Format level. However, each project is unique... so it's not always the right answer.
One important note: right now it's better to not reuse the PCL binary files across to the MonoTouch platform - for now, build your portable libraries against the specific MonoTouch library platform. See http://slodge.blogspot.co.uk/2013/01/almost-portable-binaries.html?m=1
Perhaps you want to look at the efforts other who have got PCLs working to a considerable degree with monotouch and monodroid.
For example see http://www.slideshare.net/cirrious/mvvm-cross-going-portable . You'll also find instructions on how to setup PCL support for MVVMCross here http://slodge.blogspot.co.uk/2012/09/mvvmcross-vnext-portable-class.html .
Xamarin has recently committed to providing far greater PCL support rather than some of the workarounds that people have been having to make, but it is worth the effort.
I'm currently reading the book Growing Object-Oriented Software Guided by Tests which gives a decent introduction into test driven development.
One drawback is that the code developed through the book is based on Swing. For my next project I'd like to use Java FX 2 and I'm wondering if there are any GUI testing frameworks out there for it? The book introduces windowlicker, which allows testing Swing applications only.
There's yet another new testing library for JavaFX called TestFX.
There is a library named JemmyFX. Jemmy itself is a set of libraries and tools to test UI applications (mostly Java-based: Swing, AWT, SWT; but it's being extended to native right now). JemmyFX covers JavaFX for that matter.
JemmyFX can be downloaded as a part of the test branch of OpenJFX 2 (open-sourced part of JavaFX).
For JavaFX 8, the test branch includes support for new controls and other fixes.
There's a new test robot called MarvinFX:
MarvinFX has the goal to easily test JavaFX controls and scenes with a special attention on properties.
This other post shows how to use assertions and rules with MarvinFX.
Another library (which I have not used or tested) is TestComplete.
Automaton is another testing library for JavafX and Swing GUIs born out of the same team that did TestFX
easy tests for Swing and JavaFX applications
written for testers. Only basic coding skills required.
According to Eclipse site, the modern testing tools for JavaFX in the year 2015 are Squish and Jubula . But Squish is commercial. And Jubula is partly free - JavaFX belongs to that free part. And in the Eclipse Mars version already exists the testing distribution. Uses Jubula for UI testing.
Jubula is now totally free, and does indeed support JavaFX.
I am evaluating Rich Internet application solutions to use in next project. I have heard of following solutions -
Adobe Flex
extJS
Jboss Richfaces
IceFaces
Oracle ADF
JavaFX
Silverlight
GWT
I want to know if there are more solutions available.
I would appreciate if you can provide any valuable feedback on the above solutions.
IT Mill Toolkit is a "server-driven" framework built on top of GWT.
Comment: coming from a heavy PHP and Java-hostile background, I found Toolkit to be very pleasing to use pretty quickly. Being able to write nothing but (the strongly typed, nicely OO-oriented) Java is nice, considering the fact that what you change in the code is pretty instantially reflected on what you see in the browser.
It's a bit tricky to set up, but IT Mill has an Eclipse plugin that supposedly helps with that. The only thing is that the plugin itself is a tad unintuitive to use :)
0.02€
Reply to comment: The biggest difference between GWT and IMT is that GWT operates entirely inside the browser (a hostile/exploitable environment with e.g. FireBug), while IMT uses GWT only to render the server-side state. So, while you can edit any values you want in the browser with both GWT and IMT, GWT will happily accept the user-edited variable values, IMT keeps track on the values server-side, and doesn't allow any discrepancies between the client and server.
Another big difference is that GWT widgets need to be compiled every time you do any changes to them with the relatively time consuming GWT cross-compiler (compiles Java to JavaScript). IMT, on the other hand, needs only to be redeployed to the servlet container, and the changes are there, because the GWT widgets inside IMT don't need to be recompiled. With Tomcat, it's virtually instantaneous (i.e. as soon as Tomcat notices that Eclipse has recompiled the classes on the fly).
#the_drow: Not being familiar with Dijit, here's an answer: Dojo is javascript only, meaning it's client side only. Vaadin (née IT Mill Toolkit) lives partly in the server side too (calls itself "server driven"), so you can't hack the client side just by changing JavaScript variable values. There's a chart that compares Vaadin with other comparable products. Dojo isn't included, but JQuery is, which is vaguely similar to Dojo
i had an experience with Spring Webflow + Rich Faces with mixed results - time to get the results on screen is really short, but it's pain to fine tune the presentation part.
ie if you are building some tech oriented/backend
/standard GUIs - it's ok, if you are going to build a frontend used by millions web2.0-ers you end up messing with presentation part css/javascript big time.
After evaluating and reading various RIA solutions, I have finally selected GWT and GWT-Ext. I see these benefits for me and my team -
We are used to Eclipse so this is an advantage.
Ability to use Java Debugger in Eclipse is extremely helpful.
GWT Hosted mode in eclipse, so no compile and deploy required on every change.
Big developer community
Lots of ready to use components
Prior Java knowledge helpful
Similar to swing and the team have worked on Swing in earlier project.
Look and feel is also good
Maven support is also available.
Can write Junit test cases.
No other language knowledge required apart from Java.
Easy RPC configuration based on annotations.