JavaServer Faces from a New Perspective - OIO · JavaServer Faces from a New Perspective JSF 2.2, HTML5, Bean Validation 1.1, EL 3.0, JPA 2.1 Edward Burns

JavaServer Faces from a New Perspective JSF 2.2, HTML5, Bean Validation 1.1, EL 3.0, JPA 2.1 Edward Burns

Copyright © 2013 Oracle 2

Our Plan for Your Time Investment

§ Morning Session: JSF 2.2 New Features Only –  Faces Flows –  HTML5 Friendly Markup

§ Afternoon Session: JSF 2.2 in the context of JavaEE 7 –  Other new features –  HTML5 Primer –  CDI 1.1 –  EL 3.0

-  Resource Library Contracts

-  CDI 1.1 -  Bean Validation 1.1 -  JPA 1.1


The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.


LARGE NEW FEATURES


Faces Flows

§ What is a Faces Flow? –  an application sub-module

§  well defined entry and exit §  input and output parameters §  pre and post handlers

–  An extension to the existing JSF navigation system

§ PDF section 7.5 and 7.5.1


Faces Flows Your first flow

§ EXAMPLE examples/flow/simplestFlow


Faces Flows Two ways to package flows § Directory based, PDF section 11.4.3.3

–  advantages §  Lots of conventions -> easy to get started §  Higher performance (no unzipping required by runtime)

–  disadvantages §  Not as easy to re-use

§  JAR based, PDF section 11.4.3.2 –  advantages

§  Very modular –  disadvantages

§  More re-compiling


Faces Flows Two ways to define flows

§ Flow definitions can be authored in –  XML –  Java


Faces Flows Defining

§ Minimum set of defining characteristics –  id –  start-node!

–  flow-return!§  outcome!





–  how to get in





–  how to get in –  where to go when you get in





–  how to get in –  where to go when you get in –  how to get out






§  where to go when you get out





§ Maximum set of defining characteristics –  11 different configuration elements –  many with sub-elements


§  where to go when you get out


Faces Flows Directory Based Flow Definition

§ Relative to web app root §  /<flowName>/<flowName>-flow.xml §  /WEB-INF/<flowName>/<flowName>-flow.xml

§ Degenerate case: zero length –flow.xml file –  Conventions

§  id is the directory name!§  start-node is <directoryName>.xhtml §  flow-return is <directoryName>

–  outcome is “/” + <directoryName> + “-return”



§ Directory based flow §  /<flowName>/<flowName>-flow.xml §  /WEB-INF/<flowName>/<flowName>-flow.xml

§ Explicit flow definition –  non-zero length flow definition file –  @FlowDefinition CDI producer method


Faces Flows Navigating To, From, and Within § Entering a flow: just like navigating to a new page

–  javax.faces.Command or javax.faces.OutcomeTarget component that lists the flow id as the action or outcome, respectively.

–  If the flow has a defining document id, nest it as an <f:attribute> within. § Exiting a flow

–  via a flow-return node –  via a flow-call node –  abandon the flow

§ Navigating within a flow –  to any of the flow node types


Defining a Flow Part 1

§ What’s in a Flow? § Flow Nodes



§ PDF 7.5.1



§  EXAMPLE from PDF section 7.5.1 examples/flow/basic_faces_flow_call § XML flow § Builder flow



§ defining a flow –  flow id –  flow document id

§  return node §  flow call node §  inbound parameter § outbound parameter



§ When you can have flows in jars § You must be able to disambiguate between two flows with the same id,

but in different jar files. –  answer: use the <name> in faces-config –  <name> came in JSF 2.0 for document ordering.



§ EXAMPLE examples/flow/defining_document_id


Flow Node Types

§ View nodes are special: –  the only nodes that wait for user input

§  return and flow call nodes already covered § method call §  switch


Flow Node Types

§ method call § EXAMPLE examples/flow/basic_method_call


Flow Node Types

§  switch § EXAMPLE examples/flow/basic_switch/


Flow Scoped Beans

§ @FlowScoped § #{flowScoped} § EXAMPLE examples/flow/basic_faces_flow_call


Flows and Navigation

§ EXAMPLE examples/flow/nested_flows


Flows and Navigation

§ EXAMPLE examples/flow/initDestroy §  Abandoning all flows

–  Navigating to a view in the web app root will cause all the flow stack to be entirely unwound

–  Navigation via implicit or explicit navigation is allowable


Resource Library Contracts

§ What is a Resource Library Contract? –  Review JSF 2.0 Resource Library concept –  How does contracts extend that concept?



§ Why is it called a contract? –  A contract is an agreement between a producer and consumer –  Using a contract is exactly the same as using a facelets template. You

must know §  template name §  insertion points §  (optionally) CSS, Script, Images


Resource Library Contracts Facelets Review

<ui:define name="headline"> Today's News</ui:define>

<ui:define name="story"> Facelets is now a part of JSF 2.0...</ui:define>

The Facelets Gazette

SiteNavigation

●Events

●Docs

●Forums

About Contact Site Map

_template.html

template clientgreeting.html


Resource Library Contracts Facelets Review The Facelets Gazette

SiteNavigation

●Events

●Docs

●Forums

About Contact Site Map

Template File name _template.html

Insertion points

Resourcescss classes, scripts, images


Resource Library Contracts A Contract is Born

• Declared Templates• Declared Insertion Points• Declared Resources

contractA


Resource Library Contracts Loading Conventions

contractA


contractB


contractC


<web-app-root>/contracts



contractA


contractB


contractC


<web-app-root>/contractscontractD


contractE


contractF


JAR files in WEB-INF/lib



contractA


contractB


contractC




contractE


contractF



Set of available contracts



contractA


contractB


contractC




contractE


contractF




Facelet 1 Facelet 3Facelet 2


Resource Library Contracts Loading Configuration

contractA


contractB


contractC




contractE


contractF




Facelet 1 Facelet 3Facelet 2

faces-config.xml


Resource Library Contracts Loading Configuration

contractA


contractB


contractC




contractE


contractF




Facelet 1<f:view contracts="contractA">

...

Facelet 3Facelet 2

faces-config.xml



§ How to define a contract –  Web app root

§  /contracts §  /WEB-INF/contracts

–  JAR §  META-INF/contracts + javax.faces.contract.xml


Resource Library Contracts Defining a contract

§  EXAMPLE define a simple contract examples/contracts/basic



§ how to refer to resources from within a contract

§ h:output{Script,Stylesheet}, h:graphicImage

mojarra/test/web-profile/multi_templating/basic

§  - #{resource['this:concert.jpg']}



§ EXAMPLE a contract within a jar examples/contracts/basic_contract_jar

44


Resource Library Contracts Choosing contracts

§  convention –  all contracts are exposed to the entire app

§  configuration –  <resource-library-contracts> element in faces-config.xml –  PDF section 2.7 –  PDF section 11.4.2 –  Note: if you go this way, only explicitly declared contracts are available



§  EXAMPLE faces-config syntax examples/contracts/simple



§  EXAMPLE examples/contracts/viewroot


HTML5 Friendly Markup

§ Why do I call it HTML5 “Friendly”? § Because JSF has always been able to support HTML5: just have

HTML5 aware components § The difference with JSF 2.2: it’s easier to do so



§ Before JSF 2.2 –  JSF tags hide complexity of underlying HTML+script+css+images –  JSF “Renderer”:

§  encode: markup to browser §  decode: name=value from browser

<html>… <my:colorPicker value=“#{colorBean.color2}” /> <my:calendar value=“#{calendarBean.date1}” />

</html>

§ Missing feature in browser? Write a JSF component.

§ Let the elegance of HTML shine through



§ With JSF 2.2 –  Pure HTML+script+css+images in the JSF page –  JSF Renderer handles decode from browser

§  Leverage the strength of the JSF lifecycle §  Leverage the expressiveness of HTML5

<html>… <input type=“color” jsf:value=“#{colorBean.color2}”/> <input type=“date” jsf:value=“#{calendarBean.date1}” />

</html>

§ New feature in browser? Use “pass through elements”

§ Let the elegance of HTML shine through



§ Pass Through Elements § Pass Through Attributes § HTML5 Doctype now the default



§ Pass through elements § EXAMPLE examples/html5_friendly/passthrough § TagDecorator javadoc



§ Pass through attributes § EXAMPLE examples/html5_friendly/basic


LUNCH


MEDIUM AND SMALL NEW FEATURES


ViewActions

§ <f:viewAction> tag § EXAMPLE

examples/viewAction/simple


CSRF Protection

§ PDF section 2.2.1 § EXAMPLE examples/csrf/csrf


Programmatic Composite Component Creation

§ EXAMPLE examples/component/programmaticCompositeComponent


File Upload

§ EXAMPLE examples/fileUpload/basic


CDI – History Lesson §  JSF 1.0 had managed beans

–  Declared in XML –  Fully capable inversion of control –  No proxies –  Essentially the same time Spring came around

§ CDI 1.0 entered JavaEE at version 6 –  Declared using annotations –  Fully capable inversion of control and much more –  100% dependent on proxies –  Can functionally replace Spring in most cases

60


CDI 1.1

§ Contexts and Dependency Injection –  CDI is what to do when your scopes need to span across several parts of a

heterogeneous computing environment. –  JavaEE’s answer to Spring: Context Aware Dependency Injection –  Event system –  Aspects of Aspect Oriented Programming

§  Interceptors §  Decorators

61


CDI 1.1 New Features

§ Smooth out the rough edges §  Interceptor Ordering § Global enablement § @Initialized @Destroyed events for scopes § Non contextual-injection

62


CDI 1.1

§ EXAMPLE examples/cdi/initDestroy

63


Bean Validation – History Lesson

§  Just as JSF had managed beans and inversion of control years before CDI, JSF also had validation years before Bean Validation

§ Task for JSF 2.0 was to seamlessly integrate Bean Validation into JSF § Biggest hurdle: conceptual mismatch

–  When does validation occur? §  JSF: before values are in the model §  Bean Validation: after values are in the model (but before they are

persisted via JPA)

64


Bean Validation – History Lesson

§ Answer: define a standard JSF validator !javax.faces.Bean!

§  Its validate() method calls the a validateValue() method added to the Bean Validator API at the request of JSF.

§ This allows the JSF validation reporting system to take action, while allowing Bean Validation be effective as well.

65


Bean Validation

§ Write once, validate anywhere § Defines validation behavior for use in all tiers of Java EE (and SE) § Works well with JSF, JPA, and even Servlet

66


Bean Validation 1.1

§ EXAMPLES examples/beanValidation/methodValidation examples/beanValidation/beanValidatorCdi

67


Bean Validation 1.1: New Features

§ Approaches Programing By Contract (PBC) –  Validates incoming parameters and outgoing

return value

§ Can inject with CDI into Validator implementations

§ Better message interpolation

68


Expression Language 3.0

§ The glue that holds this all together § Allows loose coupling

69


Expression Language 3.0: New Features

§ Lambda Expressions § Standalone Use

70


JPA 2.1

§ The standard Object/Relational mapping framework for the Java Platform

71


JPA 2.1: New Features

§ Query Language Enhancements § Type Converters § Entity Graphs

72


The preceding is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.

Documents

JavaServer Faces from a New Perspective - OIO · JavaServer Faces from a New Perspective JSF 2.2, HTML5, Bean Validation 1.1, EL 3.0, JPA 2.1 Edward Burns