The Application Server

1
The Application Server

• Introducing Shale as an application server with a
  comparison to Struts

2
Shale as the Predecessor to Struts

• Struts has maintained a commitment to backwards
  compatibility
• This commitment is, unfortunately, a blessing and
  a curse
• The Good Allows code written for the first
  release of struts can be reused for the last
  release.
• The Bad Struts must often pass up newer
  developments to ensure backward compatibility.

3
What does Shale do Differently?

• Shale is fundamentally based on JavaServer Faces
  (JSF)
• Shale further allows JSF to go beyond a use as a
  simple UI component.
• Includes integration links for other frameworks
  and framework components
• Includes out of the box API links for programs
  such as Spring and JUnit.

4
What does JSF do Differently?

• JSF allows all aspects of the user interface to
  be handled in one place
• JSF natively handles
• Input Validation
• State Management
• Page Navigation
• Event Handling
• JSF was designed with flexibility and platform
  independence in mind
• Allows users to define custom component classes
  for any processing imaginable.

5
The Example Bookstore Application

• This application resembles a very basic online
  bookstore
• Allows
• Browsing of Inventory
• Viewing of Book Descriptions
• Book Purchases
• Accumulation of a Shopping Cart of Books
• All information is pulled from a Database

6
Bookstore Use Case UML
7
Bookstore Class UML
8
Input Validation in Shale

• Input fields are marked as required on creation
  of the component.
• This means that the field must be filled out in
  order for the information to be submitted to the
  server
• lthinputText idusername
• valueDatabaseBea
  n.username
• requiredtrue /gt

9
Further Shale Input Validation

• Shale is integrated with the Apache Commons
  Validation.
• Provides out of the box validations for
• Credit Card
• Date
• Email
• ISBN
• URL
• All validations are provided in both server-side
  and client-side forms.

10
Shale Validation

• Mask Validation ltscommonsValidator
  typemask
  argmsgs.creditCardNumberPrompt
  servertrue
  clienttruegt
  ltsvalidatorVar namemask value4-6./gt
• Credit Card Validation ltscommonsValidator
  typecreditCard
  argmsgs.creditCardNumberPrompt
  servertruegt

11
Struts Validation

• Handled through the validation.xml field
• Includes minimal out-of-the-box support for
  validation types ltform name lognonFormgt
  ltfield propertyusername dependsrequiredgt
  ltarg keylogonForm.username/gt lt/fieldgt
  ltfield propertypassword dependsrequired,ma
  skgt ltarg keylogonForm.password/gt
  ltvargt ltvar-namegtmasklt/var-namegt
  ltvar-valuegt0-9a-zA-Zlt/var-valuegt lt/vargt

12
JSFs DataTable Tag

• Allows iteration through, and output of, Array
  Objects
• Automatically creates an HTML table and inserts
  the data lthdataTable valueInventoryMan
  agerBean.inventory
  varcurrentBookgt lthcolumngt
  lthoutputText valuecurrentBook.autho
  r/gt lt/hcolumngt
  lt/hdataTablegt

13
Data Iteration with JSP

• Done through the use of the forEach tag.
• Creation of tables or other display methodologies
  must be created by programmerltulgt
  ltcforEach itemsallInventory
  varcurrentBookgt ltligtltcout
  valuecurrentBook.author/gtlt/ligt
  lt/cforEachgtlt/ulgt

14
JSFs Actions Listeners

• JSF provides action listeners that can be invoked
  when command objects are activated.
• This allows control to be passed to a javaBean
  for processing of the user interaction.

15
Action Listener Example

• In the JSFlthcommandLink valuecurrentLink.ti
  tle
  actionListenerInventoryManagerBean.clickAction
  typesubmit/gt
• In the Java Beanpublic void clickAction(ActionEv
  ent e) if(e.getSource().getClass().getName()
  .equals(javax.faces.component.html.HtmlCommandLin
  k)) HtmlCommandLink linkExecuted
  (HtmlCommandLink)e.getSource()
  String currentTitle (String)linkExecuted.getValu
  e()

16
Action Listening in Struts

• Generally handled by changing the dispatch on
  object interaction.
• This allows specific processing to happen on
  different dispatch settings
• The action is not invoked on object interaction
  but rather once the current page has yielded
  control to the next page.

17
Page Navigation in Shale

• Page navigation is handled through the
  faces-config.xml file and navigation-rules.
• A navigation rule specifies
• The page to which the rule applies
• The pages that are reachable from the current page

18
Page Navigation Example

• A complete navigation rule with two outcomes can
  be specified byltnavigation-rulegt
  ltfrom-view-idgt/bookDescription.jsplt/from-view-idgt
  ltnavigation-casegt ltfrom-outcomegtbacklt/fro
  m-outcomegt ltto-view-idgt/inventory.jsplt/to-vi
  ew-idgt lt/navigation-casegt
  ltnavigation-casegt ltfrom-outcomegtpurchaselt/fr
  om-outcomegt ltto-view-idgt/shoppingCart.jsplt/t
  o-view-idgt lt/navigation-casegtltnavigation-rulegt

19
Page Navigation in Struts

• Greatly resembles the navigation present in
  Shale.
• Handled in the struts-config.xml file.
• Allows specification of action mappings which
• Specify a beginning action path
• Declare a forward to the next page in sequence

20
Page Navigation Example

• A complete navigation rule with two outcomes is
  given byltaction-mappinggt ltaction
  nameback path/inventory.jsp /gt ltaction
  namepurchase pathshoppingCart.jsp
  /gtlt/action-mappinggt

21
Further Page Navigation in Shale

• Shale further allows functions to be called as
  part of the action associated with command
  objects.
• This allows the outcome navigation of a page to
  be determined functionally rather than hard-coded
  predetermined navigation.

22
Further Page Navigation Example

• In the JSFlthcommandButton actionDatabaseBea
  n.nextView
  valueLogin
  typesubmit /gt
• In the Java Beanpublic String nextView()
  String toReturn new String()
  if(passwordPassed true) toReturn next
  if(passwordPassed false) toReturn fail
  return toReturn

23
The Shale View Controller

• Shale requires that each JSF page be backed by a
  View Controller.
• The View Controller contains functions that are
  invoked whenever the page they are tied to is
  displayed.

24
The Shale View Controller

• Contains four functions that are invoked in order
  on page view and navigation away from
• init() - Invoked first when the page is
  displayed, allows for setup of values to be used
  in page processing.
• prerender() - Invoked before rendering of the
  page HTML, allows for changes to be made to
  display functionality.
• preprocess() - Called before any embedded
  functional invocations are made.
• destroy() - Called on navigation away from the
  page, allows for final processing to take place
  over any page values.

25
Shale v. Struts

• Shale
• Much more planned
• Many needed aspects already built-in
• Struts
• More documented
• More mature