I often get asked why we use JavaFX for the core of our UI processing - and why we don't use HTML5.
I now wrote a paper about this, which is too long to be added into this post, so here is the link: http://www.captaincasa.com/pdf/20130124_JavaFXPositioning.pdf
Maybe you are in the same situation sometimes as well, and maybe some items of the paper may help you in some discussions.
Of course the paper is written from my point of view, which is influenced by having to do with quite complex business applications in the area of financials, controlling, logistics, human resources, manufacturing execution etc. - And: sorry, I am not a native English speaker...
Freitag, 25. Januar 2013
Dienstag, 22. Januar 2013
FX Client Update
We made a new version of our FX client available ("News" on http://www.CaptainCasa.com). The following features are now implemented:
...we now have a real HTML editor - which is part of the standard control set of JavaFX. This was always some lack in the Swing client: the missing of a simple, but working!, HTML editor
...all FILEUPLOAD* and FILEDOWNLOAD* components are available again. Nice: in JavaFX the original file dialogs of the operating system are used for choosing a file - no more home written Swing-Dialogs here anymore!
Unfortunately there is one annoying missing feature: the full file name cannot be proposed into the file selection dialog, but only a directory name can be proposed. This feature is coming with JavaFX 3.
...LONGPOLLING, which is an invisible component, is working
...the grid does not support all internal features yet (e.g. selection without going back to the server), but it re-gains feature by feature! Below you see a rather complex grid - in which a grid is arranged within a grid cell itself. If this has any practical relevance...? I am not too sure...
So, development is going on quite busily. We also made the first checks for memory leaks (and of course found some issues...) - and really feel so good in a Java based client environment: start Visual VM, start the client, observe it and profile it - and get clear results about instances which are not removed properly...!
...we now have a real HTML editor - which is part of the standard control set of JavaFX. This was always some lack in the Swing client: the missing of a simple, but working!, HTML editor
...all FILEUPLOAD* and FILEDOWNLOAD* components are available again. Nice: in JavaFX the original file dialogs of the operating system are used for choosing a file - no more home written Swing-Dialogs here anymore!
Unfortunately there is one annoying missing feature: the full file name cannot be proposed into the file selection dialog, but only a directory name can be proposed. This feature is coming with JavaFX 3.
...LONGPOLLING, which is an invisible component, is working
...the grid does not support all internal features yet (e.g. selection without going back to the server), but it re-gains feature by feature! Below you see a rather complex grid - in which a grid is arranged within a grid cell itself. If this has any practical relevance...? I am not too sure...
So, development is going on quite busily. We also made the first checks for memory leaks (and of course found some issues...) - and really feel so good in a Java based client environment: start Visual VM, start the client, observe it and profile it - and get clear results about instances which are not removed properly...!
Mittwoch, 16. Januar 2013
Update of FX Enterprise Client demo
The FX Enterprise Client is under busy development! We now published a new version as demo: please follow this link.
A couple of improvements were added. Just to name some:
...grid headers are fully functional (sorting, rearranging columns, resizing columns)
...radio buttons/groups were added
...different type of menus were added
...the generic value help now works
...and the annoying bug that the UI sometimes had problems to accept double-clicks is fixed.
We currently deliver the demo only as installable .exe file. The reason behind is:
A couple of improvements were added. Just to name some:
...grid headers are fully functional (sorting, rearranging columns, resizing columns)
We currently deliver the demo only as installable .exe file. The reason behind is:
- well, first we "love" this way of distributing the system without any pre conditions on client side (...other than it should be some Windows client ;-)...) - it's really getting into the direction of installing an "app" rather than doing a "heavy installation"
- native bundles can only be built on the corresponding platform - we would love to build a MacOS version as well, but (so far) do not have any Mac in our rooms. It would be something verrry nice to be able to build all bundles for all platforms on one device only, but I can definitely understand that there are some problems involved...
- with Windows bundles you have the choice between ".exe" and ".msi". In principal we would prefer ".msi", but we have not managed yet to build an installer that does NOT require admin rights.
Montag, 14. Januar 2013
Java and Browser-Security
A lot of negative trouble around Java was going on during the past days - once again the issue "security" was the reason behind.
Oracle now delivered a security update on version Java 7 which on the one hand solves the problem itself (known: as zero-day-gap) and on the other hand by default increases the default security level of Java in the browser to level "high". This means the user explicitly gets asked before executing Java on his/her local machine within the context of the browser.
Not allowing the automatic execution of Java in the browser is a good move! - The user needs to be asked before any Java code for what purpose ever is executed in the browser context. There must not be any automatic execution of Java without the user explicitly agreeing!
Starting Java in the browser means that some powerful execution runtime is started - having the possibility to by intention or by error access the user's client infrastructure on a quite low level. So the user needs to be warned, and the user needs to check if he/she can build up the corresponding level of trust - or not.
When starting Java from the browser, then the same must happen, what today happens during App-installations e.g. on Android devices: before installing and starting the user sees who's behind the app, so he/she can check if this is someone to trust or not. This is the main information for building up trust! - Of course the user also sees a list of system resources the app needs to access, but this is already a quite too technical layer for most users...
The pattern "explicitly check and trust, then execute" will be something that will be very common in the future client environments - regardless if it's a Java program, an App ...or e.g. even a JavaScript program. JavaScript will have more and more access to local client resources, of course hidden by some sandbox mechanism. But: if the sandbox fails because of errors, then the same level of vulnerability is present than just is/was present with the Java environment.
From my expectations the usage of Java in the client will be more and more comparable to starting an app. Java in the front end is an "app environment", it's not a "page environment". So security always will be an issue when starting an app - but it's now the level of trust between the user and the app provider, and it's not the level of trust between the user and some anonymous platform anymore.
Luckily it seems that JavaFX with its creation of native installation bundles is exactly going this direction!
Oracle now delivered a security update on version Java 7 which on the one hand solves the problem itself (known: as zero-day-gap) and on the other hand by default increases the default security level of Java in the browser to level "high". This means the user explicitly gets asked before executing Java on his/her local machine within the context of the browser.
Not allowing the automatic execution of Java in the browser is a good move! - The user needs to be asked before any Java code for what purpose ever is executed in the browser context. There must not be any automatic execution of Java without the user explicitly agreeing!
Starting Java in the browser means that some powerful execution runtime is started - having the possibility to by intention or by error access the user's client infrastructure on a quite low level. So the user needs to be warned, and the user needs to check if he/she can build up the corresponding level of trust - or not.
When starting Java from the browser, then the same must happen, what today happens during App-installations e.g. on Android devices: before installing and starting the user sees who's behind the app, so he/she can check if this is someone to trust or not. This is the main information for building up trust! - Of course the user also sees a list of system resources the app needs to access, but this is already a quite too technical layer for most users...
The pattern "explicitly check and trust, then execute" will be something that will be very common in the future client environments - regardless if it's a Java program, an App ...or e.g. even a JavaScript program. JavaScript will have more and more access to local client resources, of course hidden by some sandbox mechanism. But: if the sandbox fails because of errors, then the same level of vulnerability is present than just is/was present with the Java environment.
From my expectations the usage of Java in the client will be more and more comparable to starting an app. Java in the front end is an "app environment", it's not a "page environment". So security always will be an issue when starting an app - but it's now the level of trust between the user and the app provider, and it's not the level of trust between the user and some anonymous platform anymore.
Luckily it seems that JavaFX with its creation of native installation bundles is exactly going this direction!
Mittwoch, 9. Januar 2013
CaptainCasa sponsors JavaFX Day at this year's JAX Conference
This year's JAX conference (Apr 22-26) will have one day that is dedicated to JavaFX. Take a look at http://www.jax.de to read more details.
Speakers are:
Karsten Lentzsch,
Adam Bien,
Kai Tödter,
Gary Grunwald
...and myself (Björn Müller)
CaptainCasa is the sponsor of this JavaFX day.
Of course CaptainCasa will be present as exhibitor with a booth as well.
Speakers are:
Karsten Lentzsch,
Adam Bien,
Kai Tödter,
Gary Grunwald
...and myself (Björn Müller)
CaptainCasa is the sponsor of this JavaFX day.
Of course CaptainCasa will be present as exhibitor with a booth as well.
Montag, 7. Januar 2013
Welcome!
This blog will regularly update you about our view on User Interface framework issues.
CaptainCasa Enterprise Client is a Java based UI framework that is designed to fit the needs of Business Applications: many and complex screens, high robustness and performance demands, long (better: looooong) application life cycles and high efficiency from development to roll out.
For this reason the heart of CaptainCasa Enterprise Client is a Java based UI Client, communicating to a JSF based backend processing.
The current product version's core client is a Java Swing based UI Client. An FX version is just in development - and especially our FX progress is something we want to talk about in this blog.
CaptainCasa Enterprise Client is a Java based UI framework that is designed to fit the needs of Business Applications: many and complex screens, high robustness and performance demands, long (better: looooong) application life cycles and high efficiency from development to roll out.
For this reason the heart of CaptainCasa Enterprise Client is a Java based UI Client, communicating to a JSF based backend processing.
The current product version's core client is a Java Swing based UI Client. An FX version is just in development - and especially our FX progress is something we want to talk about in this blog.
Abonnieren
Posts (Atom)