JPA
Entity instances are in one of four states: new, managed, detached, or removed.
Tuesday, November 30, 2010
Tuesday, November 9, 2010
tuesday, 9th of november
Bindu's list
1.Training
===========================
15 nov - 20 nov
---------------------------
add, edit, delete, list app
jsf 2, jpa, spring, oracle, junit
and
V12 Coding Guidelines
Package Structure
Data Access Layer
Service Layer
23 nov - 28 nov
------------------------
only UI stuff
2. MTT
========================
15 nov - 20 nov
------------------------
general flow and UI schemas,
write final version for document
23 nov - 28 nov
------------------------
Implement Add, Edit , Delete for a simple object
1.Training
===========================
15 nov - 20 nov
---------------------------
add, edit, delete, list app
jsf 2, jpa, spring, oracle, junit
and
V12 Coding Guidelines
Package Structure
Data Access Layer
Service Layer
23 nov - 28 nov
------------------------
only UI stuff
2. MTT
========================
15 nov - 20 nov
------------------------
general flow and UI schemas,
write final version for document
23 nov - 28 nov
------------------------
Implement Add, Edit , Delete for a simple object
Friday, November 5, 2010
Friday, 05 nov
chapter 9 - the virtual trainer application
-------------------------------------------
the @ManagedBean annotation may never appear on an abstract
class.
Michael Jouravlev, in his influential August 2004 article on theserverside.com, describes the
POST REDIRECT GET (PRG) pattern as follows:
Never show pages in response to POST
Always load pages using GET
Navigate from POST to GET using REDIRECT
Composite Components
com.jsfcompref.trainer.Messages
bundle
-------------------------------------------
the @ManagedBean annotation may never appear on an abstract
class.
Michael Jouravlev, in his influential August 2004 article on theserverside.com, describes the
POST REDIRECT GET (PRG) pattern as follows:
Never show pages in response to POST
Always load pages using GET
Navigate from POST to GET using REDIRECT
Composite Components
bundle
Thursday, November 4, 2010
Thursday, 04 nov
chapter 9 - The JSF Event Model
---------------------------
There are two broad categories of events in JSF, application events and lifecycle events.
James Blunt - Stay the night
if you want to address like this something
#{something} u can put it in the requestMap
requestMap.put("something", message);
ActionSource2 components -> action event -> action listener
ValueHolder components -> value change event -> value change listener
EventObject --> FacesEvent --> ActionEvent or ValueChangeEvent
There are also: phase events and phase listeners
system events (validation about to occur on this component or this component
is about to be rendered)
Application Events - action event, value change
Lifecycle events - phase events, system events
• The Lifecycle instance may have zero or more PhaseListeners attached to it.
• A UIViewRoot instance may have from zero to two PhaseListeners attached to it.
• Every UIComponent instance may have zero or more SystemEventListeners
attached to it.
• Every instance of a component in the javax.faces.component.html package may
have zero or more ClientBehaviors attached to it, and to each of those may be
attached zero or more BehaviorListener interfaces. (The behavior system will be
explained completely in Chapter 12.)
• Every UIInput instance may have zero or more ValueChangeListeners attached to it.
• Every UICommand may have zero or more ActionListeners attached to it.
ActionEvent - At the completion of the Invoke Application
phase unless the immediate flag is true;
then it is processed at the end of the Apply
Request Value phase.
ValueChangeEvent - At the completion of the Process
Validations phase unless the immediate
flag is true; then it is processed at the end
of the Apply Request Value phase.
Pressing A Button
To record the button click event, the Faces lifecycle instantiates an ActionEvent
object and passes it as an argument to the UICommand’s queueEvent( ) method.
For action events, it is also possible to just
write either an action method or an action listener method.
The key point to remember with an action method is
that it relies on the built-in default ActionListener to invoke it and then pass this value to the NavigationHandler in order to determine if a navigation is needed.
public void addConfirmedUserListenerAction(ActionEvent ae) {
// This method would call a database or other service
// and add the confirmed user information.
System.out.println("Adding new user…");
}
For example, you may want to provide a Cancel button that calls a
method before validating the field values. To short-circuit the processing of the action event, one simply sets the UI component’s immediate attribute to true.
Changing The Value In An Input And Submitting
unlike the action event in which the event is processed during the
Invoke Application phase, value change events are processed in the Process Validations phase.
Writing Custom Action and Value Change Listeners
type="com.jsfcompref.MyActionListener">
type="com.jsfcompref.MyValueChangeListener"/>
Avoid having both value-bound and component-bound properties in a single
managed bean class.
By placing immediate="true" on every component that should participate in the partial validation, and by not having this attribute on the rest of the components, validation is bypassed for those components that do not have the attribute.
@ListenerFor(systemEventClass=PreValidateEvent.class)
public class MyInput extends UIInput {
...
public void processEvent(ComponentSystemEvent event)
throws AbortProcessingException {
super.processEvent(event);
// do any pre-validate stuff here
}
}
@ListenersFor({
@ListenerFor(systemEventClass=PostAddToViewEvent.class)
@ListenerFor(systemEventClass=PostConstructViewMapEvent.class)
})
public class MyInput extends UIInput {
...
returns void and takes a ComponentSystemEvent" />
---------------------------
There are two broad categories of events in JSF, application events and lifecycle events.
James Blunt - Stay the night
if you want to address like this something
#{something} u can put it in the requestMap
requestMap.put("something", message);
ActionSource2 components -> action event -> action listener
ValueHolder components -> value change event -> value change listener
EventObject --> FacesEvent --> ActionEvent or ValueChangeEvent
There are also: phase events and phase listeners
system events (validation about to occur on this component or this component
is about to be rendered)
Application Events - action event, value change
Lifecycle events - phase events, system events
• The Lifecycle instance may have zero or more PhaseListeners attached to it.
• A UIViewRoot instance may have from zero to two PhaseListeners attached to it.
• Every UIComponent instance may have zero or more SystemEventListeners
attached to it.
• Every instance of a component in the javax.faces.component.html package may
have zero or more ClientBehaviors attached to it, and to each of those may be
attached zero or more BehaviorListener interfaces. (The behavior system will be
explained completely in Chapter 12.)
• Every UIInput instance may have zero or more ValueChangeListeners attached to it.
• Every UICommand may have zero or more ActionListeners attached to it.
ActionEvent - At the completion of the Invoke Application
phase unless the immediate flag is true;
then it is processed at the end of the Apply
Request Value phase.
ValueChangeEvent - At the completion of the Process
Validations phase unless the immediate
flag is true; then it is processed at the end
of the Apply Request Value phase.
Pressing A Button
To record the button click event, the Faces lifecycle instantiates an ActionEvent
object and passes it as an argument to the UICommand’s queueEvent( ) method.
For action events, it is also possible to just
write either an action method or an action listener method.
The key point to remember with an action method is
that it relies on the built-in default ActionListener to invoke it and then pass this value to the NavigationHandler in order to determine if a navigation is needed.
public void addConfirmedUserListenerAction(ActionEvent ae) {
// This method would call a database or other service
// and add the confirmed user information.
System.out.println("Adding new user…");
}
For example, you may want to provide a Cancel button that calls a
method before validating the field values. To short-circuit the processing of the action event, one simply sets the UI component’s immediate attribute to true.
Changing The Value In An Input And Submitting
unlike the action event in which the event is processed during the
Invoke Application phase, value change events are processed in the Process Validations phase.
Writing Custom Action and Value Change Listeners
Avoid having both value-bound and component-bound properties in a single
managed bean class.
By placing immediate="true" on every component that should participate in the partial validation, and by not having this attribute on the rest of the components, validation is bypassed for those components that do not have the attribute.
@ListenerFor(systemEventClass=PreValidateEvent.class)
public class MyInput extends UIInput {
...
public void processEvent(ComponentSystemEvent event)
throws AbortProcessingException {
super.processEvent(event);
// do any pre-validate stuff here
}
}
@ListenersFor({
@ListenerFor(systemEventClass=PostAddToViewEvent.class)
@ListenerFor(systemEventClass=PostConstructViewMapEvent.class)
})
public class MyInput extends UIInput {
...
returns void and takes a ComponentSystemEvent" />
Wednesday, November 3, 2010
wednesday, 03 nov
chapter 7 - the user interface component model
ActionSource2
ValueHolder
PartialStateHolder
NamingContainer
you have a component, a renderer and a tag handler
chapter 8 - converting and validating data
------------------------------------------
first conversion then validation
convertor
public Object getAsObject(FacesContext context,
UIComponent component,
String value)
public String getAsString(FacesContext context,
UIComponent component,
Object value)
u can have only one convertor max
if it's immediate - then the validation is done in apply request values phase
u have implicit conversion(when u have value binding) and explicit
conversion (when u specify a convertor by class of by convertor id)
u can also add programmatically a convertor
// Create the Converters, one by type, the other by Class.
intConverter =
context.getApplication( ).createConverter("javax.faces.Integer");
floatConverter =
context.getApplication( ).createConverter(Float.class);
// Install the converters.
component1.setConverter(intConverter);
component2.setConverter(floatConverter);
if you register a convertor by class
then it can be used for implicit conversion
validator interface
public void validate(FacesContext context,
UIComponent component,
Object value)
before validating the component is marked as invalid
validators are registered only by validator-id
u can make jsf not validate empty fields
javax.faces.VALIDATE_EMPTY_FIELDS
false
As an alternative to the required attribute, it is possible to nest an
element within any input component to achieve the same effect.
It’s very important to note that, when nesting, any validators, or settings on validators,
that happen inside of the nesting take precedence over whatever validators or settings are
specified on the wrapping validator(s).
standard validators have a property disabled which can an el expression as value
so u can add a validator by
validator attribute
special tag (standard or by f:validator and providing validator id)
programmatically
The markup tags all result in a call to addValidator( ) on the underlying
component instance, and the required attribute results in a call to setRequired(true) on the
component.
Bean Validation
@ManagedBean
@SessionScoped
public class UserBean {
protected String sex;
@NotEmpty(message="You must supply an email address")
@Email
protected String email;
!!! The FacesContext is an object per request
FacesMessage - severity, summary and detail
FacesContext contains two lists of messages
- associated with a component
- not associated with a component
different variants of the getMessages( ) method on
FacesContext. The variant that takes no arguments returns an Iterator of all messages, associated with a component or not. The variant that takes a clientId gets only messages associated with the component of that clientId, or, if the clientId is null, gets only messages that are not associated with a specific clientId.
The FacesContext is the place where you obtain the UIViewRoot for the current view
There are exactly three times in the request processing lifecycle when the standard
components will create a FacesMessage instance and add it to the FacesContext: when
conversion fails, when validation fails, or when the converted and validated data cannot be pushed to the model during the Update Model Values phase.
com.jsfcompref.Messages
en
de
You can also override the message using the requiredMessage, converterMessage, or
validatorMessage property of UIInput. This is exposed as a tag attribute on all of the tags that expose UIInput components to the page author.
@Email(message="Silly user, your email is invalid")
private String email;
@Email(domain=".org")
private String email;
The entry in the ValidationMessages_en.properties file is shown next:
validator.email=Invalid email address. Must end in {domain}.
chapter 9 - The JSF Event Model
---------------------------
There are two broad categories of events in JSF, application events and lifecycle events.
James Blunt - Stay the night
ActionSource2
ValueHolder
PartialStateHolder
NamingContainer
you have a component, a renderer and a tag handler
chapter 8 - converting and validating data
------------------------------------------
first conversion then validation
convertor
public Object getAsObject(FacesContext context,
UIComponent component,
String value)
public String getAsString(FacesContext context,
UIComponent component,
Object value)
u can have only one convertor max
if it's immediate - then the validation is done in apply request values phase
u have implicit conversion(when u have value binding) and explicit
conversion (when u specify a convertor by class of by convertor id)
u can also add programmatically a convertor
// Create the Converters, one by type, the other by Class.
intConverter =
context.getApplication( ).createConverter("javax.faces.Integer");
floatConverter =
context.getApplication( ).createConverter(Float.class);
// Install the converters.
component1.setConverter(intConverter);
component2.setConverter(floatConverter);
if you register a convertor by class
then it can be used for implicit conversion
validator interface
public void validate(FacesContext context,
UIComponent component,
Object value)
before validating the component is marked as invalid
validators are registered only by validator-id
u can make jsf not validate empty fields
As an alternative to the required attribute, it is possible to nest an
element within any input component to achieve the same effect.
It’s very important to note that, when nesting, any validators, or settings on validators,
that happen inside of the nesting take precedence over whatever validators or settings are
specified on the wrapping validator(s).
standard validators have a property disabled which can an el expression as value
so u can add a validator by
validator attribute
special tag (standard or by f:validator and providing validator id)
programmatically
The markup tags all result in a call to addValidator( ) on the underlying
component instance, and the required attribute results in a call to setRequired(true) on the
component.
Bean Validation
@ManagedBean
@SessionScoped
public class UserBean {
protected String sex;
@NotEmpty(message="You must supply an email address")
protected String email;
!!! The FacesContext is an object per request
FacesMessage - severity, summary and detail
FacesContext contains two lists of messages
- associated with a component
- not associated with a component
different variants of the getMessages( ) method on
FacesContext. The variant that takes no arguments returns an Iterator of all messages, associated with a component or not. The variant that takes a clientId gets only messages associated with the component of that clientId, or, if the clientId is null, gets only messages that are not associated with a specific clientId.
The FacesContext is the place where you obtain the UIViewRoot for the current view
There are exactly three times in the request processing lifecycle when the standard
components will create a FacesMessage instance and add it to the FacesContext: when
conversion fails, when validation fails, or when the converted and validated data cannot be pushed to the model during the Update Model Values phase.
You can also override the message using the requiredMessage, converterMessage, or
validatorMessage property of UIInput. This is exposed as a tag attribute on all of the tags that expose UIInput components to the page author.
@Email(message="Silly user, your email is invalid")
private String email;
@Email(domain=".org")
private String email;
The entry in the ValidationMessages_en.properties file is shown next:
validator.email=Invalid email address. Must end in {domain}.
chapter 9 - The JSF Event Model
---------------------------
There are two broad categories of events in JSF, application events and lifecycle events.
James Blunt - Stay the night
Tuesday, November 2, 2010
Tuesday, 02 nov
chapter 6 - the navigation model
--------------------------------
action attribute
h:commandButton
h:commandLink
outcome attribute
h:button
h:link
in MVC the Faces Servlet acts as the controller
an event triggered by a component which implements ActionSource interface
-> navigation event -> NavigationHandler
component that implements ActionSource2 interface means that this
component is the source of an ActionEvent
apply request values - triggering an ActionEvent
invoke application - the default ActionListener.processAction is called
which calls the action method and generates an outcome
after that NavigationHandler.handleNavigation is called if outcome not null
which does FacesContext.setViewRoot(new UIViewRoot())
if outcome null or not a valid outcome - user remains on the same page
this usually results in RequestDispatcher.forward() being called
<if>#{model.booleanValue}</if>
redirect means that you generate another request
<navigation-case>
<from-action>#{Login.loginAction}</from-action>
<from-outcome>success</from-outcome>
<to-view-id>/success.xhtml</to-view-id>
<redirect/>
</navigation-case>
h:button and h:link do GET
h:commandButton and h:commandLink do POST
h:commandButton value="HTTP POST with Redirect" action="page02?facesredirect=true"
---------------------------------------
<f:metadata>
<f:viewParam name="fname" value="#{userBean.firstName}" />
<f:viewParam name="lname" value="#{userBean.lastName}" />
<f:viewParam name="sex" value="#{userBean.sex}" />
<f:viewParam name="dob" value="#{userBean.dob}">
<f:convertDateTime pattern="MM-dd-yy" />
</f:viewParam>
<f:viewParam name="email" value="#{userBean.email}" />
<f:viewParam name="sLevel" value="#{userBean.serviceLevel}" />
</f:metadata>
<navigation-rule>
<from-view-id>whatever the from view id is</from-view-id>
<navigation-case>
<from-outcome>whatever the outcome value is</from-outcome>
<to-view-id>whatever the to view id is</to-view-id>
<redirect>
...the view-param elements are optional
<view-param>
<name>any string is fine here</name>
<value>any string or value expression is fine here</value>
</view-param>
...additional view-param elements may be defined
</redirect>
</navigation-case>
</navigation-rule>
<error-page>
<exception-type>javax.faces.application.ViewExpiredException
</exception-type>
<location>/faces/sessionExpired.xhtml</location>
</error-page>
<error-page>
<exception-type>com.jsfcompref.BadUserException
</exception-type>
<location>/faces/badUser.xhtml</location>
</error-page>
The UI component tree is fully managed by the ViewHandler between requests. However, it is
the role of the StateManager to preserve the UI component tree in between subsequent
requests. It saves the complete status of the component tree using one of several different statesaving
methods specified as a context parameter (javax.faces.STATE_SAVING_METHOD) in
the Web application’s web.xml file. The different state-saving parameters are server and client.
------------------------
chapter 7 - the user interface component model
ActionSource2
ValueHolder
PartialStateHolder
NamingContainer
--------------------------------
action attribute
h:commandButton
h:commandLink
outcome attribute
h:button
h:link
in MVC the Faces Servlet acts as the controller
an event triggered by a component which implements ActionSource interface
-> navigation event -> NavigationHandler
component that implements ActionSource2 interface means that this
component is the source of an ActionEvent
apply request values - triggering an ActionEvent
invoke application - the default ActionListener.processAction is called
which calls the action method and generates an outcome
after that NavigationHandler.handleNavigation is called if outcome not null
which does FacesContext.setViewRoot(new UIViewRoot())
if outcome null or not a valid outcome - user remains on the same page
this usually results in RequestDispatcher.forward() being called
<if>#{model.booleanValue}</if>
redirect means that you generate another request
<navigation-case>
<from-action>#{Login.loginAction}</from-action>
<from-outcome>success</from-outcome>
<to-view-id>/success.xhtml</to-view-id>
<redirect/>
</navigation-case>
h:button and h:link do GET
h:commandButton and h:commandLink do POST
h:commandButton value="HTTP POST with Redirect" action="page02?facesredirect=true"
---------------------------------------
<f:metadata>
<f:viewParam name="fname" value="#{userBean.firstName}" />
<f:viewParam name="lname" value="#{userBean.lastName}" />
<f:viewParam name="sex" value="#{userBean.sex}" />
<f:viewParam name="dob" value="#{userBean.dob}">
<f:convertDateTime pattern="MM-dd-yy" />
</f:viewParam>
<f:viewParam name="email" value="#{userBean.email}" />
<f:viewParam name="sLevel" value="#{userBean.serviceLevel}" />
</f:metadata>
<navigation-rule>
<from-view-id>whatever the from view id is</from-view-id>
<navigation-case>
<from-outcome>whatever the outcome value is</from-outcome>
<to-view-id>whatever the to view id is</to-view-id>
<redirect>
...the view-param elements are optional
<view-param>
<name>any string is fine here</name>
<value>any string or value expression is fine here</value>
</view-param>
...additional view-param elements may be defined
</redirect>
</navigation-case>
</navigation-rule>
<error-page>
<exception-type>javax.faces.application.ViewExpiredException
</exception-type>
<location>/faces/sessionExpired.xhtml</location>
</error-page>
<error-page>
<exception-type>com.jsfcompref.BadUserException
</exception-type>
<location>/faces/badUser.xhtml</location>
</error-page>
The UI component tree is fully managed by the ViewHandler between requests. However, it is
the role of the StateManager to preserve the UI component tree in between subsequent
requests. It saves the complete status of the component tree using one of several different statesaving
methods specified as a context parameter (javax.faces.STATE_SAVING_METHOD) in
the Web application’s web.xml file. The different state-saving parameters are server and client.
------------------------
chapter 7 - the user interface component model
ActionSource2
ValueHolder
PartialStateHolder
NamingContainer
Subscribe to:
Posts (Atom)