There are often odd cases when in a Flash Application you find that by design you want to call a function but only have the name of the function as a String. This could be caused by various reasons one being that the name is stored in a database as part of some settings. To accomplish this conversion we make use of the Function object.

How to Convert a String to a Function

var functionName:String = "toString";
 
// obtain the function handler
var namedFunction:Function = this[fName];
 
// execute the function and pass any desired arguments
nameFunction( arg1, arg2, ... );
, ,

Apache Tiles is a Java Framework used for the templating of Web Applications. Tiles allows developers to define fragments of pages that are combined to create the whole page based on page definitions. The Tiles framework is often used in conjunction with the Apache Struts Model View Controller (MVC) framework. Below are two solutions on how to nest tile elements.

The Problem

During processing Apache Tiles creates a Tiles Context for each level of tile where the attributes defined are only accessible to that context and not any nested tiles. What this means is that you need to pass attributes defined at the top level down to  the nested or inner tiles.  To illustrate lets assume our web application has 4 main elements:

Header
Menu
Body
Footer

Now lets assume that in for some pages our Body is created by Nesting 2 tiles in it so that instead the page consists of:

Header
Menu
Body Part 1 Body Part 2
Footer

What this would mean is that we would have a layout file that is similiar to:

<tiles:insert attribute="header" />
<tiles:insert attribute="menu" />
<tiles:insert attribute="body"/>
<tiles:insert attribute="footer" />

And that our body page for the 2 elements could be represented as:

<table>
  <tr>
    <td><tiles:insert attribute="part1"/></td>
    <td><tiles:insert attribute="part2"/></td>
  </tr>
</table>

Now how do we get those attributes passed to that nested tile.

Solution #1 Defining Nested Tiles in the Tiles Definition

In this solution we define the inner body tile in the definition page and use that definition as the body for the page. So that we end up with a default layout, a page layout, and the body part definitions in our tiles-defs.xml file. A sample is shown below.

<definition name="gLayout" template="/WEB-INF/tiles/gLayout.jsp">
  <put name="header" value="/WEB-INF/tiles/header.jsp" />
  <put name="menu" value="/WEB-INF/tiles/menu.jsp" />
  <put name="footer" value="/WEB-INF/tiles/footer.jsp" />
</definition>
 
<!-- define the inner tile -->
<definition name="page.body" template="/WEB-INF/tiles/body.jsp">
  <put name="part1" value="/WEB-INF/page/part1.jsp" />
  <put name="part2" value="/WEB-INF/page/part2.jsp" />
</definition>
 
<!-- define the page by referencing the nested tile -->
<definition name="editpage" extends="gLayout">
  <put name="body" value="page.body"  type="definition"/>
</definition>

Using this method allows you to easily nest tiles and their attributes without having to worry about tiles context and passing attributes to inner nested tiles. The main drawback to this method is that your tiles definitions file can become extremely large depending on your web application.

Solution # 2 Have the Layout file pass attributes to internal tiles

In this approach we update the layout file to pass attributes from its tiles context into the nested tile.  So that the nested tile does not need to be defined in the tiles definition but instead the page definitions will specify the attributes that are utilized as shown below.

tiles-defs.xml

<definition name="gLayout" template="/WEB-INF/tiles/gLayout.jsp">
  <put name="header" value="/WEB-INF/tiles/header.jsp" />
  <put name="menu" value="/WEB-INF/tiles/menu.jsp" />
  <put name="footer" value="/WEB-INF/tiles/footer.jsp" />
</definition>
 
<!-- define the page by referencing the nested tile -->
<definition name="editpage" extends="gLayout">
  <put name="body" value="/WEB-INF/page/body.jsp" />
  <put name="part1" value="/WEB-INF/page/part1.jsp" />
  <put name="part2" value="/WEB-INF/page/part2.jsp" />
</definition>

gLayout.jsp

<tiles:insert attribute="header" />
<tiles:insert attribute="menu" />
<tiles:insert attribute="body">
  <tiles:put attribute="part1" beanName="part1" />
  <tiles:put attribute="part2" beanName="part2" />
</tiles:insert>
<tiles:insert attribute="footer" />

We now have successfully passed the attributes defined in the tiles definitions into our nested tile by use of the layout file. Although this approach will minimize the size of your tiles definitions file your layout file will need to be expanded to contain all possible attributes that could be utilized by nested tiles, increasing its size.

Resources

, , ,

JavaServer Pages Standard Tag Library or JSTL for short is a library that contains a set of core functionality including iterations and conditionals.  The tag I find myself most often using is the forEach tag to output a collection of data in a consistent format. By use of the optional status object and the if tag you can even put logic in that executes only if the item being iterated is first or last in the collection.

Getting Started

To utilize JSTL you first need to download the appropriate jar file and import it into you project in the web library. Once in your project you need to import the tag definition into your page using the following code.

<%@ taglib prefix="c" uri="http://java/sun.com/jsp/jstl/core %>

Basic ForEach Tag Usage

Once the tag library is imported we can use it by specifying 2 attributes var and items. VAR is used to denote the reference that the current item being iterated in the collection can be accessed by, while ITEMS specifies the collection to be iterated upon. Lets assume me have a collection of User objects that each have a firstName, lastName, and email property.  We could iterate over them with the following code.

<c:forEach var="user" items="${users}">
</c:forEach>

The above code is functional but doesn’t output any data lets expand upon it by having it export rows of a table with the three properties each in their own cell.

<table>
  <tr>
    <th>First Name</th>
    <th>Last Name</th>
    <th>Email</th>
  </tr>
  <c:forEach var="user" items="${users}">
    <tr>
      <td>${user.firstName}</td>
      <td>${user.lastName}</td>
      <td>${user.email}</td></tr>
  </c:forEach>
</table>

Advanced Usage: The varStatus Attribute

In addition to iteration over the collection the ForEach tag provides a status object that can be used to obtain information about where you are in the collection.

<c:forEach var "user" items="${users}" varStatus="status">
</c:forEach>
  • first and last property
    The status object contain a first and last property that returns a boolean set to true or false if the current item being iterated over is the first or last object in the collection. You can utilize the if tag to have code execute if it is one of these conditions.

    <c:if test="${status.last}">
      // code
    </c:if>
  • index property
    The index property gives you the current index of the object within the collection this value can be used to output different classes on odd and even rows for example, in addition to other uses.

    <table>
      <tr>
        <th>First Name</th>
        <th>Last Name</th>
        <th>Email</th>
      </tr>
      <c:forEach var="user" items="${users}" varStatus="status">
        <tr class="${status.index % 2 == 0 ? 'even' : 'odd'}">
          <td>${user.firstName}</td>
          <td>${user.lastName}</td>
          <td>${user.email}</td>
        </tr>
      </c:forEach>
    </table>

Resources

, ,

A Cursor is a database structure that allows for the traversal of the records in a result set. In Sybase T-SQL a cursor functions by the following steps:

  1. Declare the Cursor:
    To use a cursor you first must declare it by providing a name and the SELECT query that will provide the result set it will be traversing through.  The Syntax for declaring the Cursor is as follows:

    DECLARE cursor_name CURSOR
    FOR  SELECT ....
  2. Open the Cursor:
    Once the Cursor is declared we must open the cursor to utilize it:

    OPEN cursor_name
  3. Fetch Rows:
    Now that the Cursor is ready we use the FETCH command to return a result row.  When fetching a row we need to fetch it into variables defined prior to the Fetch. To provide the user with if the query was successful the @@sqlstatus variable is available, where 0 means success, 1 = error, and 2 is no more data. We can use the @@sqlstatus variable in a WHILE condition to traverse the entire result set.

    FETCH cursor_name INTO @var1, @var2, ...
    WHILE ( @@sqlstatus = 0 )
    BEGIN
      // do something WITH the DATA
      FETCH cursor_name INTO @var1, @var2, ...
    END
  4. Close the Cursor:
    After traversal of the result set we close the cursor by use of the CLOSE command:

    CLOSE cursor_name
  5. Deallocate the Cursor:
    Last we deallocate the cursor so that Cursor is removed from memory and can not be opened again:

    DEALLOCATE CURSOR cursor_name

Optimization

Be advised that when using SELECT statements that JOIN multiple tables or have sub-queries that performance can be affected. To optimize it is good practice to perform such selects into a temporary table and that the cursor is set up to select data from that temp table.

Resources

, , ,

SQL Queries can often be written in multiple ways to obtain the same end result set. Tables for instance can be joined in the FROM clause or the WHERE clause of a SQL Statement. In the FROM Clause we can utilize LEFT, RIGHT, INNER keywords to denote if both sides of the statement needs to be present to return the results or if only 1 side needs to be.  These same joins can be accomplished in the WHERE clause by use of the *= and =*.  Where *= is equivalent to LEFT JOIN and =* is the same as RIGHT JOIN.

Example FROM clause LEFT JOIN

FROM USER u 
  LEFT JOIN ROLE r ON u.ROLE_ID = r.ID

Example WHERE clause LEFT JOIN

FROM USER u,
  ROLE r
WHERE u.ROLE_ID *= r.ID
, , ,