2. 2
Agenda
● Java and web development
● Weaknesses (of the past)
● A small story
● Choosing JSF, things to consider during
development
3. 3
● Programming in Java since 2000
● In love with back-end code and JavaEE
● Web-development
– Using..servlets
– JSP(s)... and script-lets (they forced me to ... :P )
– Apache Struts 1.x
– JSF 1.x
– JSF 2.x
6. 6
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.
7. 7
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....
9. 9
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
11. 11
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.
12. 12
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?
13. 13
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?
15. 15
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!!!
16. 16
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 implementations
– Mojarra
– Apache MyFaces
● The spec is evolving, we hope much faster
– https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC
17. 17
Application server support?
● This is something you need to watch out!
● All the mainstream app servers come bundled with an concrete
implementation.
● Oracle Weblogic 12c
– Mojarra (JSF 2.1)
● Oracle GlassFish 4 (R.I.P?)
– Mojarra (JSF 2.2 )
● IBM WebSphere 8.5.5
– Apache MyFaces (JSF 2.1)
● RedHat WildFly (JBoss)
– Mojarra (JSF 2.2)
19. 19
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!
20. 20
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!
21. 21
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 books
– JSF the complete reference, Ed.Burns
● God bless to JSF heroes and dev community
– BalusC (http://balusc.blogspot.com/)
– StackOverflow, JSF section
22. 22
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.
23. 23
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 :)
24. 24
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
library
– Lazy data models
– Async form posts
– Ajax support
– Partial form submits
– Another positive surprise!!!
25. 25
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.
26. 26
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.
27. 27
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.
28. 28
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.
29. 29
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)
30. 30
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.