JSF GUI Development Experience
I have been developing browser GUIs for about 12 years already, among other things, I have experience using servlets, JSP, XML / XSLT, Struts, Tapestry (3,4,5), Wicket, Spring MVC and GWT.
But JSF has bypassed the party so far. The reason for this was that when JSF first appeared, it looked eerily clumsily in its first incarnations - compared to the same Tapestry and Wicket.
Time passed, JSF was not going to die, but appeared already in version 2.1. And I decided to try to use it for one of my experimental projects, for which I spend about 3 months every year - to broaden my horizons and distract from boring consulting (which I earn for children in the remaining 9 months).
')
On bare HTML forms, making GUI in the 21st century is, frankly, indecent. Therefore, I wanted, of course, that there was AJAX and all sorts of such deliciously sexy widgets, which is called right out of the box.
The following three candidates were selected as candidates for consideration based on the results of reading the Internet - RichFaces , PrimeFaces and ICEFaces . The latest available (including beta, RC, etc.) versions of the frameworks were used.
Sadly, the first two frameworks were cut off at the very first (thank Jaah! First), the dumbest test.
What I had to build was a rich application backend. Consequently, we can not do without tabs.
Unfortunately, RichFaces and PrimeFaces do not understand that when rendering a set of tabs like:
it is not necessary to rendit what is in “Second tab”, if the selected tab is “First tab”. RichFaces and PrimeFaces always create a tree of objects, including all the contents of the TabSet, i.e. all non-selected tabs including. It was absolutely unacceptable: there was a lot of data in each tab, including that which comes from the database.
In addition to this regrettable inferiority, from RichFaces and PrimeFaces there and then leaked the need to use JavaScript, which I wanted to avoid.
ICEFaces, surprisingly, not only was responsible for rendering tabs, but also contained components that simply worked, without any JavaScript.
As a result, for approximately 120 hours of operation, it was possible to attach a fairly spreading GUI (12 large and complex forms) to the existing kernel, programming only in the form of a Facelets markup (in some places with CSS), and in Java, i.e. without going into any javascript.
This is how it all looks like:
Skin is one of the defaults, called 'rime', so aesthetes might be unhappy.
An important result: now I know what JSF can be used for (that is, not JSF at all, but specifically ICEFaces) - for backend interfaces that are not very heavily loaded (about hundreds of users), and with a slight distance between the browser and the server.
Overhead to excessive communication with the server is compensated by the possibility of fast programming at a high level. And, in general, everything works. It even works server push (update screens on the event on the server).
The following technologies were used:
- Maven, well, where without him
- ICEFaces, see above.
- MyFaces instead of the standard Mojarra - due to better error diagnosis.
- Spring Core
- Spring Security
- Selenium
- Jetty
I want to say a separate good word about JRebel - a tool for automated deployment of modified code without stopping VM. I have their license for open-source development, but generally speaking JRebel is worth the modest money that comrades from Estonia ask for it. Excellent product, works as stated and saves time.
All development was carried out in IntelliJ IDEA. But I suppose it should work the same way in Eclipse / Netbeans.
Oh yeah, for what I started writing all this ...
Actually, from my project, its essence was distilled and stored on the github in the form
this modest artifact .
It was going to make him Maven archetype, but it became lazy.
In the project, everything stated above is present, and the base login / logout form works for which the Selenium test is also written. Details in github README.
I hope this helps someone to save some time at the start of an important project.
It took me almost two weeks to select and match the components.
But JSF has bypassed the party so far. The reason for this was that when JSF first appeared, it looked eerily clumsily in its first incarnations - compared to the same Tapestry and Wicket.
Time passed, JSF was not going to die, but appeared already in version 2.1. And I decided to try to use it for one of my experimental projects, for which I spend about 3 months every year - to broaden my horizons and distract from boring consulting (which I earn for children in the remaining 9 months).
')
On bare HTML forms, making GUI in the 21st century is, frankly, indecent. Therefore, I wanted, of course, that there was AJAX and all sorts of such deliciously sexy widgets, which is called right out of the box.
The following three candidates were selected as candidates for consideration based on the results of reading the Internet - RichFaces , PrimeFaces and ICEFaces . The latest available (including beta, RC, etc.) versions of the frameworks were used.
Sadly, the first two frameworks were cut off at the very first (thank Jaah! First), the dumbest test.
What I had to build was a rich application backend. Consequently, we can not do without tabs.
Unfortunately, RichFaces and PrimeFaces do not understand that when rendering a set of tabs like:
<panelTabSet>
<panelTab label="First tab">
...
</panelTab>
<panelTab label="Second tab">
...
</panelTab>
...
</panelTabSet>
it is not necessary to rendit what is in “Second tab”, if the selected tab is “First tab”. RichFaces and PrimeFaces always create a tree of objects, including all the contents of the TabSet, i.e. all non-selected tabs including. It was absolutely unacceptable: there was a lot of data in each tab, including that which comes from the database.
In addition to this regrettable inferiority, from RichFaces and PrimeFaces there and then leaked the need to use JavaScript, which I wanted to avoid.
ICEFaces, surprisingly, not only was responsible for rendering tabs, but also contained components that simply worked, without any JavaScript.
As a result, for approximately 120 hours of operation, it was possible to attach a fairly spreading GUI (12 large and complex forms) to the existing kernel, programming only in the form of a Facelets markup (in some places with CSS), and in Java, i.e. without going into any javascript.
This is how it all looks like:
Skin is one of the defaults, called 'rime', so aesthetes might be unhappy.
An important result: now I know what JSF can be used for (that is, not JSF at all, but specifically ICEFaces) - for backend interfaces that are not very heavily loaded (about hundreds of users), and with a slight distance between the browser and the server.
Overhead to excessive communication with the server is compensated by the possibility of fast programming at a high level. And, in general, everything works. It even works server push (update screens on the event on the server).
The following technologies were used:
- Maven, well, where without him
- ICEFaces, see above.
- MyFaces instead of the standard Mojarra - due to better error diagnosis.
- Spring Core
- Spring Security
- Selenium
- Jetty
I want to say a separate good word about JRebel - a tool for automated deployment of modified code without stopping VM. I have their license for open-source development, but generally speaking JRebel is worth the modest money that comrades from Estonia ask for it. Excellent product, works as stated and saves time.
All development was carried out in IntelliJ IDEA. But I suppose it should work the same way in Eclipse / Netbeans.
Oh yeah, for what I started writing all this ...
Actually, from my project, its essence was distilled and stored on the github in the form
this modest artifact .
It was going to make him Maven archetype, but it became lazy.
In the project, everything stated above is present, and the base login / logout form works for which the Selenium test is also written. Details in github README.
I hope this helps someone to save some time at the start of an important project.
It took me almost two weeks to select and match the components.
Source: https://habr.com/ru/post/133980/
All Articles