I received the follwing document by Makis Deftereos - the person behind a software product "Icupis" that manages information and processes within the intensive care unit of hospitals.
Icupis - pdf
So: pay attention when staying e.g. in the university hospital of Heraklion (Greece): you may see CaptainCasa screens!
Thanks a lot, Makis, for sending us the information!
Dienstag, 30. April 2013
Mittwoch, 6. März 2013
CaptainCasa FX Client - Beta Phase started
The JavaFX based client of our rich client framework is now included in the normal installation package - marked as "Beta" of course. After installation you have the option to either use the Swing based client - ...or to use the JavaFX based client.
Both do the same, rendering screens - the layout of screens coming from a central JSF based server. So the rendering result is very similar. OK, with JavaFX it looks smarter - and animations are much nicer... ;-)
We currently concentrate on a Windows based delivery - just to save resources on our side. We will prepare explicit installation scenarios for Linux and MacOS later on. (For the brave ones: there is a zip package containing "everything you need", but some shell scripts to start the FX client are missing...)
A couple of improvements and bug fixing was done in the meantime...:
Images now can be mirrored and sheared just by adding some prefix in front of the image-URL:
This is a general feature of all images, regardless if it's shown in a button or if it's the background for a pane.
It's possible to now to add mapped-areas to an image definition. Each mapped area contains an id and some tooltip information. The user sees the mapped areas on top of the image when moving with the mouse over the corresponding area. Clicks are sent back to the server processing.
The screenshot is showing a gaphics (PNG) which was created by a JFreeChart based reporting on server side. JFreeChart has an interface to collect map-information, which is quite nice. ...OK, we know: JavaFX has some graphics library on its own to produce charts like the one above...! But still, most reporting systems are on server side, producing image output as PNG or whatever file.
Hot-Key definitions were added. Either hot-keys are added directly to cetrain components (e.g. Button) or the arey added to popup menu defintions. There's a flexible way to define which popup menu is valid for which area - so you can define one hot key to be used in different ways on different parts of the screen. (If you want so ...).
The slider and progressbar components are available now as well.
...all in all: everything quite fine from the JavaFX client development...! The beta phase is planned to be finished somewhere mid of Q2/2013.
Both do the same, rendering screens - the layout of screens coming from a central JSF based server. So the rendering result is very similar. OK, with JavaFX it looks smarter - and animations are much nicer... ;-)
We currently concentrate on a Windows based delivery - just to save resources on our side. We will prepare explicit installation scenarios for Linux and MacOS later on. (For the brave ones: there is a zip package containing "everything you need", but some shell scripts to start the FX client are missing...)
A couple of improvements and bug fixing was done in the meantime...:
Images now can be mirrored and sheared just by adding some prefix in front of the image-URL:
It's possible to now to add mapped-areas to an image definition. Each mapped area contains an id and some tooltip information. The user sees the mapped areas on top of the image when moving with the mouse over the corresponding area. Clicks are sent back to the server processing.
The screenshot is showing a gaphics (PNG) which was created by a JFreeChart based reporting on server side. JFreeChart has an interface to collect map-information, which is quite nice. ...OK, we know: JavaFX has some graphics library on its own to produce charts like the one above...! But still, most reporting systems are on server side, producing image output as PNG or whatever file.
Hot-Key definitions were added. Either hot-keys are added directly to cetrain components (e.g. Button) or the arey added to popup menu defintions. There's a flexible way to define which popup menu is valid for which area - so you can define one hot key to be used in different ways on different parts of the screen. (If you want so ...).
The slider and progressbar components are available now as well.
...all in all: everything quite fine from the JavaFX client development...! The beta phase is planned to be finished somewhere mid of Q2/2013.
Mittwoch, 13. Februar 2013
FX Client Update
Quite a lot functions were added to out FX client in the recent days. You can test the client by going to http://www.captaincasa.com/fxclient.html
Remember: the client is a thin client written in JavaFX, being fed by a JSF based server application running centrally. Please view more information here: http://www.CaptainCasa.com .
The Calendar Field is available, both as stand alone calendar and as popup calendar:
Touch screen support is available. When clicking into corresponding fields a context-specific touch dialog is popping up, allowing direct user input via virtual keyboard.
The schedule control is alive again - supporting all features like drag and drop of items. Both schedule orientation are supported, horizontal and vertical. This is the horizontal example:
The paint area component is available, now using JavaFX based animation, which makes it much nicer than the pseudo-navigation that we have to use with our Swing client.
Also have a look into the client's new scrolling through grids. In order to minimize the round-trips to the server, there is a certain "pseudo scrolling" which makes the use much nicer.
Last but not least: we did some test, using the client on a Linux machine - and were very satisfied with results. Basically we did not find any severe problem yet, so compatibility between Windows-JavaFX and Linux-JavaFX is really good! This is the screen shot showing the client running on Ubuntu 12:
Remember: the client is a thin client written in JavaFX, being fed by a JSF based server application running centrally. Please view more information here: http://www.CaptainCasa.com .
The Calendar Field is available, both as stand alone calendar and as popup calendar:
Touch screen support is available. When clicking into corresponding fields a context-specific touch dialog is popping up, allowing direct user input via virtual keyboard.
The schedule control is alive again - supporting all features like drag and drop of items. Both schedule orientation are supported, horizontal and vertical. This is the horizontal example:
The paint area component is available, now using JavaFX based animation, which makes it much nicer than the pseudo-navigation that we have to use with our Swing client.
Also have a look into the client's new scrolling through grids. In order to minimize the round-trips to the server, there is a certain "pseudo scrolling" which makes the use much nicer.
Last but not least: we did some test, using the client on a Linux machine - and were very satisfied with results. Basically we did not find any severe problem yet, so compatibility between Windows-JavaFX and Linux-JavaFX is really good! This is the screen shot showing the client running on Ubuntu 12:
Freitag, 25. Januar 2013
"Why we use JavaFX" - Paper
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...
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...
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!
Abonnieren
Posts (Atom)