Development in Java EE 7 with JSF
Does it still matter?
Agenda
Java and web development
Weaknesses (of the past)
A small story
Choosing JSF, things to consider during development
Programming in Java since 2000
In love with back-end code and JavaEE
Web-developmentUsing..servlets
JSP(s)... and script-lets (they forced me to ... :P )
Apache Struts 1.x
JSF 1.x
JSF 2.x
Java and Web Development
Java and Web Development..contd
Java and Web Development
Let's face it, the Java ecosystem was struggling for many years in order to come up with a 'one to rule them all' web framework.
From servlets to JSP(s) to action frameworks (yaay) but always very close 'mentally' to the HTTP paradigm.
Frameworks getting bigger and bigger, more complex, steep learning curve.
Java and Web Development...and me
Well, I totally agree, writing web based applications in the past was not very exciting
And then JSF came, it broke the existing 'action frameworks' paradigm....
And then....
My first encounter with JSF..a long time ago
JSF original Hate
Complex framework
Slow, the JSF life cycle is an overkill!
Non optimal front end support technologies, jsp, facelets etc
Steep learning curve
Far away from the action based frameworks (yaay)
Poor Ajax support
Buggy component libraries
Too many implementations, slow evolving spec
James Gosling..father of Java
'I hate JSF with a passion...'
A small story
A small team of Java developers (3),different experience levels, today- 2014!
Task, re-write a legacy web application (banking, back office)
Legacy app... code written in JPS(s), full stop.
No specifications
We need it fast, ASAP
We need something better, dynamic, easy to maintain, more beautiful, user friendly.
A small story - 2
So which framework and architecture shall we choose?
Shall we skip JSF,while embracing all the other parts of the JavaEE architecture?
Choose something else? GWT? (Vaadin?)
Pure JS framework?Which one?
A small story - 3
If we choose JSF what are our restrictions?
Which application server are we going to use?
What is the existing JSF support on the above app servers?
What component library shall we use?
What about JavaScript and Ajax support?
How much time will it take our small team to learn and code on a different framework / technology?
What technologies we currently master or we are familiar with now?
Choices, choices, choices
The JSF way why? - team
We were a 'pure' Java team, with existing experience on Java EE.
We needed something ASAP, so we needed to leverage our existing skill set.
Minimize coding on Javascript, but being able to leverage Ajax and async functionality in our web app.
I consider JS a maintenance nightmare / a ticking bomb to many codebases.Warning possible flame trigger in the audience let's start everybody!!!
State of the specification?
Currently JSF 2.2 JSR 334 Final
Part of the Java EE 7 spec
JSF 2.0, 2.1, 2.2 simplified many ugly things of the past.
Concrete implementationsMojarra
Apache MyFaces
The spec is evolving, we hope much fasterhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC
Application server support?
This is something you need to watch out!
All the mainstream app servers come bundled with an concrete implementation.
Oracle Weblogic 12cMojarra (JSF 2.1)
Oracle GlassFish 4 (R.I.P?)Mojarra (JSF 2.2 )
IBM WebSphere 8.5.5Apache MyFaces (JSF 2.1)
RedHat WildFly (JBoss)Mojarra (JSF 2.2)
Component libraries?
Lot's of choices!
PrimeFaces (yaay!!!)
OmniFaces
RichFaces
Oracle ADF
Apache Trinitad / Tomahawk/ Tobago
Show cases: http://robertjliguori.blogspot.gr/2014/04/jsf-component-library-showcases.html
What we choose?
We could not change the app server so, the target application was developed towards WebSphere 8.5.5 and Apache My Faces 2.1.
But we could choose the component library, clear winner, PrimeFaces 4 amazing features!
XHTML pages only!
Bootstrapping development?
Standard JavaEE6 multi-module web application
Maven packaging, no special configuration
A few entries on the web.xml, initializing the JSF library.
Package the component library, just primefaces.jar
Define a template for xhtml pages.
No initial problems combining standard JSF xthml tags and specific to the component
Easy and problem free ..start, a first positive surprise!
Learn as you code
Different levels of JSF coding experience.
3 man days of reading through JSF 2.1 specifics.
Lot's of free resources and available booksJSF the complete reference, Ed.Burns
God bless to JSF heroes and dev communityBalusC (http://balusc.blogspot.com/)
StackOverflow, JSF section
Some basic guidelines
Keep the code simple
Make sure everyone understands the basic scopes of Managed Beans
Avoid Session Scoped Beans.
Code using lean and clean entities (dto's)
Code all the 'table' section of pages with lazy loading.
Some basic guidelines - 2
Identify 4-5 core use cases and apply the same principles.
Try to leverage the rich UI built in support of the components rather than doing it your self. No extra JS plz..no extra JS plz..no extra JS plz.
Make use of Client Side Validation (Primefaces) along with server side validation (JSF).
Localization comes cheap :)
During development
We managed to resolve corner cases as we developed concrete examples, fast enough.
We were amazed that most of UI requirements were already covered and implemented by the component libraryLazy data models
Async form posts
Ajax support
Partial form submits
Another positive surprise!!!
During development
JSF code integrated naturally with any pre-existing code we had already developed e.g JPA2 beans, and EJB(s).
A simple and clear separation of layers that is easy to be taught and followed, by junior members.
JSF built in error management and handling, helps you identify easily bugs and resolve problems.
During development
We used CDI, but we felt that there is still room for improvement when you mix different annotations together.
We would be happier if our app server was more flexible on allowing us to experiment with another JSF engine.Some app servers are more flexible.
Total lines of extra Javascript written (less than 10 and not in a jsf component)
Our app can easily migrate from Websphere to another container.
Why you should consider JSF
If you are already a team with core Java skill set and you want to use this skillset asap
JSF 2.x is and it's concrete implementations are far easier to use and grasp comparing to JSF 1.x
Lot's of documentation and support.
All major app servers support it and come pre-bundled with an existing implementation.
Why you should consider JSF
IMHO it is easier in the future to maintain an aging Java code base rather than a JScript one.
Freedom of choice, you can de-couple the choice of which JSF implementation to use and what component library.
Many component libraries offer amazing out of the box functionality for free! No need to re-invent the wheel.Many libraries offer out of the box rendering to mobile clients with no extra coding.
Why you should consider JSF
JSF 2.2 introduces HTML 5 support (html 5 friendly mark up)
Extended support for complex implementation cases e.g Faces Flow
Added more Explicit CSRF support
Do not forger that from JSF 2 and onwards 'partial state saving' when submitting forms and stateless mode are supported.Meaning, yes you can scale to thousands of users,and your session does not have to be hundreds of MB(s)
Is it late?
JSF is around more than 10 years
Some people argue that it's maturity came very late.
I believe that as long as web development in the form we currently know it (for the browser) is relevant, JSF will be a valid choice especially for teams with Java Developers.
Question
Will you reconsider?I did