1
Development in Java EE 7 with JSF
Does it still matter?
2
Agenda
● Java and web development
● Weaknesses (of the past)
● A small story
● Choosing JSF, things to consider during
d...
3
● Programming in Java since 2000
● In love with back-end code and JavaEE
● Web-development
– Using..servlets
– JSP(s)......
4
Java and Web Development
5
Java and Web Development..contd
6
Java and Web Development
● Let's face it, the Java ecosystem was struggling
for many years in order to come up with a 'o...
7
Java and Web Development...and
me
● Well, I totally agree, writing web based
applications in the past was not very excit...
8
My first encounter with JSF..a long
time ago
9
JSF original Hate
● Complex framework
● Slow, the JSF life cycle is an overkill!
● Non optimal front end support technol...
10
James Gosling..father of Java
'I hate JSF with a passion...'
11
A small story
● A small team of Java developers (3),different
experience levels, today- 2014!
● Task, re-write a legacy...
12
A small story - 2
● So which framework and architecture shall we
choose?
● Shall we skip JSF,while embracing all the ot...
13
A small story - 3
● If we choose JSF what are our restrictions?
● Which application server are we going to use?
● What ...
14
Choices, choices, choices
15
The JSF way – why? - team
● We were a 'pure' Java team, with existing experience on
Java EE.
● We needed something ASAP...
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 simpli...
17
Application server support?
● This is something you need to watch out!
● All the mainstream app servers come bundled wi...
18
Component libraries?
● Lot's of choices!
● PrimeFaces (yaay!!!)
● OmniFaces
● RichFaces
● Oracle ADF
● Apache Trinitad ...
19
What we choose?
● We could not change the app server so, the
target application was developed towards
WebSphere 8.5.5 a...
20
Bootstrapping development?
● Standard JavaEE6 multi-module web application
● Maven packaging, no special configuration
...
21
Learn as you code
● Different levels of JSF coding experience.
● 3 man days of reading through JSF 2.1 specifics.
● Lot...
22
Some basic guidelines
● Keep the code simple
● Make sure everyone understands the basic
scopes of Managed Beans
● Avoid...
23
Some basic guidelines - 2
● Identify 4-5 core use cases and apply the same
principles.
● Try to leverage the rich UI bu...
24
During development
● We managed to resolve corner cases as we developed
concrete examples, fast enough.
● We were amaze...
25
During development
● JSF code integrated naturally with any pre-
existing code we had already developed e.g
JPA2 beans,...
26
During development
● We used CDI, but we felt that there is still room for
improvement when you mix different annotatio...
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...
28
Why you should consider JSF
● IMHO it is easier in the future to maintain an aging Java code
base rather than a JScript...
29
Why you should consider JSF
● JSF 2.2 introduces HTML 5 support (html 5 friendly mark up)
● Extended support for comple...
30
Is it late?
● JSF is around more than 10 years
● Some people argue that it's maturity came very
late.
● I believe that ...
31
Question
Will you reconsider?
– I did
32
<h:outputText value="Thanks for
your time..."/>
Upcoming SlideShare
Loading in …5
×

Web development in JavaEE7 with JSF, does it still matter?

2,517 views

Published on

Is worth re-considering JSF for a future project? What changes with JSF2 and what you should look out.

Published in: Technology, Education

Web development in JavaEE7 with JSF, does it still matter?

  1. 1. 1 Development in Java EE 7 with JSF Does it still matter?
  2. 2. 2 Agenda ● Java and web development ● Weaknesses (of the past) ● A small story ● Choosing JSF, things to consider during development
  3. 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
  4. 4. 4 Java and Web Development
  5. 5. 5 Java and Web Development..contd
  6. 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. 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....
  8. 8. 8 My first encounter with JSF..a long time ago
  9. 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
  10. 10. 10 James Gosling..father of Java 'I hate JSF with a passion...'
  11. 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. 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. 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?
  14. 14. 14 Choices, choices, choices
  15. 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. 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. 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)
  18. 18. 18 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
  19. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.
  31. 31. 31 Question Will you reconsider? – I did
  32. 32. 32 <h:outputText value="Thanks for your time..."/>

×