The Application Server

quicksandwalleyeInternet και Εφαρμογές Web

31 Οκτ 2013 (πριν από 4 χρόνια και 2 μήνες)

84 εμφανίσεις

The Application Server

Introducing Shale as an application
server with a comparison to Struts

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.

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.

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.

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

Bookstore Use Case UML

Bookstore Class UML

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:


<h:inputText id=“username”


value=“#{DatabaseBean.username}”


required=“true” />

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.

Shale Validation


Mask Validation:


<s:commonsValidator type=“mask”


arg=“#{msgs.creditCardNumberPrompt}”


server=“true”


client=“true”>


<s:validatorVar name=“mask” value=“[4
-
6].*”/>


Credit Card Validation:


<s:commonsValidator type=“creditCard”


arg=“#{msgs.creditCardNumberPrompt}”


server=“true”>

Struts Validation


Handled through the validation.xml field


Includes minimal “out
-
of
-
the
-
box” support for
validation types:


<form name= lognonForm>


<field property=“username” depends=“required”>


<arg key=“logonForm.username”/>


</field>


<field property=“password” depends=“required,mask”>


<arg key=“logonForm.password”/>


<var>


<var
-
name>mask</var
-
name>


<var
-
value>^[0
-
9a
-
zA
-
Z]*$</var
-
value>


</var>

JSF’s DataTable Tag


Allows iteration through, and output of, Array
Objects


Automatically creates an HTML table and inserts
the data:



<h:dataTable value=“#{InventoryManagerBean.inventory}”


var=“currentBook”>


<h:column>


<h:outputText value=“#{currentBook.author}”/>


</h:column>


</h:dataTable>

Data Iteration with JSP


Done through the use of the
forEach

tag.


Creation of tables or other display
methodologies must be created by
programmer:


<ul>



<c:forEach items=“${allInventory}” var=“currentBook”>


<li><c:out value=“${currentBook.author}”/></li>


</c:forEach>

</ul>

JSF’s 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.

Action Listener Example


In the JSF:

<h:commandLink value=“#{currentLink.title}”


actionListener=“#{InventoryManagerBean.clickAction}”


type=“submit”/>


In the Java Bean:

public void clickAction(ActionEvent e)

{


if(e.getSource().getClass().getName().equals(“javax.faces.component.html.HtmlCommandLi
nk”))


{


HtmlCommandLink linkExecuted = (HtmlCommandLink)e.getSource();


String currentTitle = (String)linkExecuted.getValue();


}

}

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.

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

Page Navigation Example


A complete navigation rule with two outcomes
can be specified by:


<navigation
-
rule>


<from
-
view
-
id>/bookDescription.jsp</from
-
view
-
id>


<navigation
-
case>


<from
-
outcome>back</from
-
outcome>


<to
-
view
-
id>/inventory.jsp</to
-
view
-
id>


</navigation
-
case>


<navigation
-
case>


<from
-
outcome>purchase</from
-
outcome>


<to
-
view
-
id>/shoppingCart.jsp</to
-
view
-
id>


</navigation
-
case>

<navigation
-
rule>

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

Page Navigation Example


A complete navigation rule with two
outcomes is given by:


<action
-
mapping>


<action name=“back” path=“/inventory.jsp” />


<action name=“purchase” path=“shoppingCart.jsp” />

</action
-
mapping>

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.

Further Page Navigation
Example


In the JSF:

<h:commandButton action=“#{DatabaseBean.nextView}”


value=“Login”


type=“submit” />


In the Java Bean:

public String nextView()

{


String toReturn = new String();



if(passwordPassed == true) toReturn = “next”;


if(passwordPassed == false) toReturn = “fail”;



return toReturn;

}

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.

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.

Shale v. Struts


Shale


Much more planned


Many needed aspects already built
-
in


Struts


More documented


More mature