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