JSF Component Behaviors

JSF Component Behaviors Andy Schwartz | Oracle Corporation

Agenda
History
Behavior API: Basics
A Simple Sample Behavior
Behavior API: Advanced Topics
Auto Suggest Sample Behavior
Future

History

First
First, there was Ajax.
And it was good.
But it required JavaScript code.

Sample: Ajax JavaScript API
<h:outputScript name="jsf.js" library="javax.faces"/>
<h:commandButton value="Do something Ajaxy"
onclick="jsf.ajax.request(this, event,
{render: 'out'}); return false;"/>
<h:outputText id=”out” value=”Update me!”/>

Ajax JavaScript API
The Good
Standard
Flexible
The Bad
Verbose
Error-prone

Time for a declarative Ajax API

Declarative Ajax, Take 1
New Components?

Sample: New Components? <h:commandButton value=“Not Ajax”/> <a:commandButton value=“Ajax!”/>

New Components?
The Good
Simple
Familiar
The Bad
Component explosion
Next feature: more components?

New Attributes?

Sample: New Attributes? <h:commandButton ajax=“true”/>

New Attributes?
The Good
Simple
No new components
The Bad
Attribute explosion
Next feature: more attributes?

Attached Objects?
Remember those?

What Are Attached Objects?
Attached objects enhance components with functionality not anticipated by the original component author.

Some Existing Attached Objects
Converters
f:convertNumber
f:convertDateTime
Validators
f:validateLength
f:validateBean
f:validateRegex

Ajax Attached Object?  <h:inputText> <f:convertNumber/> </h:inputText>  <h:commandButton> <f:ajax/> </h:commandButton>

Ajax Attached Object
Yes!

Ajax Attached Object
The Good
Easy to use
Familiar pattern
No attribute explosion
No component explosion
Some precedent exists
Think a4j:support as attached object instead of component
The Bad
More verbose than component/attribute alternatives
Somebody needs to design the API!

Behavior API: Basics

API Requirements
Loose Coupling
Surprise?

Loose Coupling
Components should not contain Ajax-specific code
Objects contribute scripts to component markup
Components know where to insert attached scripts
Objects may be attached to arbitrary components
Objects may implement arbitrary behaviors
Not limited to Ajax

Two New Contracts
ClientBehavior
ClientBehaviorHolder

ClientBehavior Contract
String getScript(ClientBehaviorContext)

ClientBehavior Scripts
What can a ClientBehavior script do?

Say Hello // Some people *always* start with “Hello, World!” public String getScript(ClientBehaviorContext c) { return “alert(‘Hello, World!’)”; }

Ajax // Slightly more interesting public String getScript(ClientBehaviorContext c) { return “jsf.ajax.request(this, event)”; }

What Else?
Client-side validation
DOM manipulation
Tooltips, hover content
Disclosures
Logging
Confirmation
Key handling
Auto-suggest

Who Calls getScript()?
Components/Renderers call getScript() during rendering and insert scripts into the generated markup.

Standard ClientBehaviors
Just one for now
Java API: AjaxBehavior
Tag API: <f:ajax>

Attaching ClientBehaviors
Remember EditableValueHolder?

ClientBehaviorHolder Contract void addClientBehavior( String eventName, ClientBehavior behavior)

What Events?
Components define available events/attach points
Behavior events can correspond to DOM events
Events can also be “logical” (component-level)
Some obvious events:
h:commandButton: click
h:inputText: change
Some less obvious events
h:commandButton: focus, blur
h:inputText: keyup, keydown, keypress
h:panelGroup: mouseover, mouseout
foo: bar

ClientBehaviorHolder Contract Collection<String> getEventNames();

Usage <h:commandButton> <f:ajax event=“focus”/> </h:commandButton> <h:inputText> <f:ajax event=“keypress”/> </h:inputText> <h:panelGroup> <foo:showHoverContent event=“mouseover”/> </h:panelGroup>

Logical Events
Some components expose logical events
Command: action (not DOM click)
Input: valueChange (not DOM change)
Client-side event abstraction over DOM
Hides arbitrary DOM implementations
Matches server-side abstraction
Helpful in wrapping scenarios

Logical Events  <f:ajax event="click"> <h:panelGroup> <h:commandButton/> <h:inputText/> <h:commandButton/> </h:panelGroup> </f:ajax>

Logical Events  <f:ajax event="action"> <h:panelGroup> <h:commandButton/> <h:inputText/> <h:commandButton/> </h:panelGroup> </f:ajax>

Default Events
What happens if you do not specify an event?

ClientBehaviorHolder Contract String getDefaultEventName();

Default Event Usage <h:commandButton>  <f:ajax/> </h:commandButton> <h:inputText>  <f:ajax/> </h:inputText> <h:panelGroup>  <f:ajax/> </h:panelGroup>

More Event Fun: Chaining <h:commandButton> <foo:confirm/> <f:ajax/> </h:commandButton>

More Event Fun: Multiple Events <h:commandButton> <f:ajax/> <foo:showHoverContent event=“mouseover”/> <foo:hideHoverContent event=“mouseout”/> </h:commandButton>

Standard ClientBehaviorHolders
All standard components implement ClientBehaviorHolder.

A Simple Sample Behavior

Our Simple Sample Behavior
Confirm Behavior

Step 1: Implement the Behavior
Extend ClientBehaviorBase
Implement getScript()

ConfirmBehavior public class ConfirmBehavior extends ClientBehaviorBase { @Override public String getScript( ClientBehaviorContext behaviorContext) { return "return confirm('Are you sure?')"; } }

Step 2: Register the Behavior
Two ways to do this
Old School: faces-config.xml
New School: annotations
Both call Application.addBehavior(String, Class)
Associates Behavior class with a behavior id.
Enables Application.createBehavior(String)

Register Behavior: Old School <faces-config> <behavior> <behavior-id>jsf2foo.behavior.Confirm</behavior-id> <behavior-class> org.jsf2foo.behavior.confirm.ConfirmBehavior </behavior-class> </behavior> </faces-config>

Register Behavior: New School @FacesBehavior("jsf2foo.behavior.Confirm”) public class ConfirmBehavior …

Step 3: Define the Tag
Registering Behavior enables Application.createBehavior(String)
Still need a tag to expose to page authors
Facelets tags are defined in taglib.xml file
taglib.xml files live in WEB-INF or META-INF

Jsf2foo.taglib.xml <facelet-taglib> <namespace>http://jsf2foo.org/behavior</namespace> <tag> <tag-name>confirm</tag-name> <behavior> <behavior-id>jsf2foo.behavior.Confirm</behavior-id> </behavior> </tag> </facelet-taglib>

Step 4: Ready To Go
The Behavior is now available for use under namespace specified in the taglib.xml file

ConfirmBehavior Usage <html … xmlns:j2f="http://jsf2foo.org/behavior"> … <h:commandButton value="Submit"> <j2f:confirm/> </h:commandButton>

What Gets Rendered? <input type="submit" value="Submit" onclick="return confirm('Are you sure?')" />

Behavior API: Advanced Topics

ClientBehaviorContext
Provides context for getScript()
FacesContext
Component
Event name
Parameters
Source id

ClientBehaviorHints
Enum returned by ClientBehavior.getHints()
Provides hints to component/renderer
Currently only one hint: SUBMITTING

ClientBehavior Decoding
ClientBehaviors also participate in decoding
ClientBehavior.decode()
Allows scripts to communicate back to server
What can ClientBehaviors do in decode?
Queue an event
Send a response

Server-Side Events
ClientBehaviors can queue events
Events are queued on parent component
Leverage existing FacesEvent lifecycle
BehaviorEvent extends FacesEvent
BehaviorListener extends FacesListener

AjaxBehavior Event Sample  <h:commandButton actionListener="#{foo.doIt}"> <f:ajax/> </h:commandButton>  <h:panelGroup> <foo:showHoverContent event=“mouseover” listener="#{foo.hover}"/> </h:panelGroup>

Behavior API
So far we've been focusing on ClientBehavior API
There is more to the story: Behavior API
ClientBehavior extends Behavior
Base class for other possible non-client Behaviors
Phased behavior
Behavior defines event handling contract
broadcast(BehaviorEvent)

ClientBehaviorRenderer
ClientBehaviors can delegate to RenderKit-specific ClientBehaviorRenderers
Similar to UIComponent/Renderer split
Allows RenderKit-specific script generation and decoding
Allows frameworks to plug in framework-specific functionality without replacing ClientBehavior implementations.

Auto Suggest Behavior

Goals/Assumptions
Provide Google Auto Suggest-like functionality
Behavior attached to arbitrary input components
Assumption: Access to specific client events
Assumption: DOM input element

Contract
We need an API for retrieving suggestions.

Contract: Suggester public interface Suggester { public Collection<String> suggest(String prefix); }

Contract
We need a tag API.

Contract: Tag  <h:inputText id="search"> <j2f:suggest suggester="#{suggester}"/> </h:inputText>  <tr:inputText id="search"> <j2f:suggest suggester="#{suggester}"/> </tr:inputText>

Event Handling Behavior
Key events: Retrieve suggestions, show list
Up/down arrow: Navigate suggestions list
Enter: Accept suggestion
Escape: Hide suggestions list
Blur: Hide suggestions list

Handler Implementation
Typically the default BehaviorHandler is sufficient
We have special requirements
Single Behavior instance, multiple events
Solution: Need a custom BehaviorHandler

SuggestBehavior: getScript()
Typically ClientBehaviors generate a single script
We have special requirements
SuggestBehavior generates event-specific scripts
Solution: ClientBehaviorContext.getEventName()

Requesting Suggestions
Key up activity triggers suggestions list
Suggestions retrieved from server
Target the SuggestBehavior instance
Solution: Use jsf.ajax.request to implement fetch

Selecting a Suggestion
Handle key up for arrow key navigation
Enter key accepts current selection
However, enter key also submits form
Solution: cancel default enter key behavior

Resource Dependencies
SuggestBehavior requires JavaScript, CSS
Dependencies should be transparent to application
Solution: Use new ResourceHandler mechanism

What's Left?
State saving
Error handling
Request collapsing
Autocomplete

Future

Ideas
Targeted postback paylaods
Ajax over GET
Out of band Ajax
Improved Ajax queueing/event collapsing
Pre-execute behavior processing
Alternate behavior contracts
Fallback behavior
Attached object value expression support
Attached object state saving
Initialization/DOM modifiers

JSF Component Behaviors

by Andy Schwartz

Accessibility

Categories

Upload Details

Usage Rights

2 Embeds 32

Statistics

JSF Component Behaviors Presentation Transcript

http://www.slideshare.net	31
http://polo.ceit.metu.edu.tr	1