JSF 2.0, Myth and Reality - GeeCON

5 downloads 218 Views 932KB Size Report
. JSF 2.0, Myth and Reality. Ed Burns. JavaEE UI Architect twitter: @edburns http://xri.net/=edburns #geecon ...
1

twitter: @edburns http://xri.net/=edburns #geecon



JSF 2.0, Myth and Reality Ed Burns JavaEE UI Architect

My Plan for Your Time Investment • Myth • Biggest complaints about JSF • Context for these complaints • Current Reality • Busting the Myths • Zero Deployment Time • Composite Components • Followup • How to get started with JSF 2.0

3

Myth

4

The Biggest Complaints About JSF • Too Much Configuration • Counterproductive, not DRY • Impossible to Debug • Over-engineered • Slow and Wasteful • Hard to Learn • Conclusion: Don't bother with JSF, use {Wicket,

Tapestry, Stripes, etc} instead.

5

Complaint: Too Much Configuration • Validity: Pre JSF 2.0: Yes • Historical context • JSF 1.0: designed for J2EE 1.4, JDK 1.4! • No Generics • No Annotations • JSF 1.2: Designed for J2EE 1.5, JDK 1.5 • Yes Generics • Some annotations: @Resource • Convention over configuration: yes, we could have done this, but it was not the fashion at the time. • Lots of XML was all the rage back then: witness: Spring 2

6

Complaint: Counterproductive • Validity: Pre JSF 2.0: Yes • Historical Context • Violation of Don't Repeat Yourself: Yes • Intellectual heritage from Struts • There was a lot of “keep all these named entries in synch” • Beans • Converters • Validators

7

Complaint: Impossible to debug • Validity: Pre JSF 2.0: Yes • Historical Context • Lame excuse: Because JSF is a standard, we felt that error messages were best left as an implementation detail. • But who cares about that: users just want things to work. • Non standard technologies don't bother to separate interface from implementation • They can get more precise about error messages

8

Complaint: Over-engineered • Validity: Subjective • Historical Context • A guiding principal for the design of JavaEE standards is flexibility • Being too prescriptive stifles innovation and shortens the relevance lifetime of a technology • Being flexible is one remedy for ignorance, “We don't know all the answers, let's leave ourselves an escape hatch.”

9

Complaint: Slow and Wasteful • Validity: Pre JSF 2.0: Not quite • Historical Context • Because pre-JSF 2.0 keeps a lot of state, it's possible to easily get yourself into situations where memory use becomes a problem. • Several presentations have been given at JavaOne and other conferences comparing the performance of JSF with that of other web frameworks: They all came up around the same.

10

Complaint: Hard to Learn • Validity: Subjective • Historical Context • If you know another web framework, and are productive with it, you might have to adjust your approach to get the most from JSF. • Because web frameworks are so popular, lots of people have this problem.

11

Conclusion • All these complaints are valid, so I should use

{Tapestry, Wicket, Stripes, ZK, MochaUI etc.} instead of JSF.

12

Conclusion of complaints • All these complaints are valid, so I should use

{Tapestry, Wicket, Stripes, ZK, MochaUI etc.} instead of JSF. • Not quite. • Pre JSF 2.0: these complaints need to be weighed against the benefits: • Decent encapsulation model • Vibrant component market • Large user community • Post JSF 2.0: these complaints, and many more, have been addressed • and the benefits persist and grow larger 13

JSF Experiences: Garmin • Pioneer and

world leader in consumer GPS devices • Using JSF since 1.1 • Loves the localization

http://my.garmin.com/

14

JSF Experiences: Garmin

• Are there other technologies you are

considering to replace JSF?

15

JSF Experiences: Garmin

• What is your favorite feature in JSF?

16

Conclusion of complaints • All these complaints are valid, so I should use

{Tapestry, Wicket, Stripes, ZK, MochaUI etc.} instead of JSF. • Evolution vs. Revolution • Innovation happens everywhere

17

Conclusion of complaints • All these complaints are valid, so I should use

{Tapestry, Wicket, Stripes, ZK, MochaUI etc.} instead of JSF. • Evolution vs. Revolution • Innovation happens everywhere • Except in a standards effort. Standards are for codifying best practices to put them in the hands of more users.

18

JSF Experiences: Garmin

• How important is it that JSF is a

standard?

19

Reality

20

Complaint: Too Much Configuration • Configuration you needed before 2.0 • web.xml • to map the faces servlet • faces-config.xml • to declare managed beans • to declare navigation rules • JSF 2.0: “Pay as you go” complexity tax

21

Complaint: Too Much Configuration DEMO: JSF without XML

22

Complaint: Counterproductive • Lots of DRY violations before JSF 2.0 • servlet and servlet-name • managed-bean-name, EL Expression, managed-bean-class • navigation-rule, page name • validator id, validator class • converter id, converter class

23

Complaint: Counterproductive DEMO: No DRY Violations

24

Complaint: Impossible to debug • Source of this complaint: • The absence of Facelets • The lack of the ProjectStage parameter

25

Complaint: Impossible to Debug DEMO: Development aids

26

Complaint: Over-engineered Class or interface

Class or interface

ActionListener

PhaseListener

ApplicationFactory

PropertyResolver

Converter

RenderKit

ELResolver

RenderKitFactory

ExceptionHandlerFactory

StateManager

ExternalContextFactory

VariableResolver

FacesContextFactory

Validator

LifecycleFactory

ViewDeclarationLanguageFactory

NavigationHandler

ViewHandler = artifact can be decorated

27

Complaint: Slow and Wasteful • Source of this complaint: saved too much state • Solution: DRY in action

28

Complaint: Slow and Wasteful Partial State Saving • Default for pages written with Facelets for JSF 2.0 • Of interest to Java custom component authors • All standard components implement this feature - your

• • • •

composite components will automatically take advantage of it. Per-view state size up to 5X smaller than before PartialStateHolder behavioral interface, extends existing StateHolder. Inspired by Trinidad state saving StateHelper, from UIComponent, does most of the work: replace ivars with keys within StateHelper. 29

Complaint: Slow and Wasteful Partial State Saving: Simplifies Custom Components

public class MyInput extends UIComponentBase { private enum Keys { name } public String getName() { return getStateHelper().get(name); } public void setName(String nameParam) { getStateHelper().put(name, nameParam); } }

30

Complaint: Hard to Learn • Source of Complaint: misunderstanding of how to

teach JSF • A better approach is to acknowledge that JSF is designed for several audiences, each needing to know more than the next

31

Complaint: Hard to Learn 1. Teach from Application Developer Viewpoint

2. Teach from UIComponent Developer Viewpoin 3. Teach from Framework Extender Viewpoint

32

Complaint: Hard to Learn 1. Teach from Application Developer Viewpoint – – – – – –

Traverse sample application: scrumtoys View and Controller Layer: navigation, ajax Model Layer: Managed Beans, JSR-303 Validation Review: JSF Lifecycle Persistence Layer: JPA I18N

2. Teach from UIComponent Developer Viewpoin 3. Teach from Framework Extender Viewpoint

33

Complaint: Hard to Learn 1. Teach from Application Developer Viewpoint 2. Teach from UIComponent Developer Viewpoint – – – – –

Composite Components, including JSR-276 Metadata Resource Libraries Ajax Integration Scripting to save time Component annotations

3. Teach from Framework Extender Viewpoint

34

Complaint: Hard to Learn 1. Teach from Application Developer Viewpoint 2. Teach from UIComponent Developer Viewpoint 3. Teach from Framework Extender Viewpoint – Patterns that enable extension – Survey of extension points – Sample extensions

35

The importance of Zero Deployment Time • Mihaly Csikszentmihalyi, flow state

“being completely involved in an activity for its own sake. The ego falls away. Time flies. Every action, movement, and thought follows inevitably from the previous one, like playing jazz. Your whole being is involved, and you're using your skills to the utmost.”

36

Zero Deployment Time DEMO: Mojarra Groovy

37

Composite Components This feature ties these ease of use concepts all together • This...

38

Composite Components This feature ties these ease of use concepts all together • Becomes this

39

Composite Components DEMO

40

Composite Components

http://blogs.sun.com/arungupta/entry/totd_135_jsf2_custom_components

41

Followup

42

Getting started with JSF2 GlassFish Server Open Source Edition http://glassfish.org/ • command line

mvn archetype:create • Finally have legal permission to publish Mojarra jars to maven central repository • This will include archetypes

• IDE

File->New Project

43

For More Information

http://search.oracle.com

or oracle.com

44

For More Information

http://search.oracle.com GlassFish

or oracle.com

45

For More Information

http://search.oracle.com GlassFish

http://www.oracle.com/technology/products/glassfish/

46

47