Resources and Training

This section includes a list of resources to refer to when learning about a particular technology used in the UXT UI stack.  It includes:

First check with your supervisor before beginning training.  Below are just few potential options and recommendations.

It is recommend that training follow…

  1. Start with self-paced study & sample project
  2. Training is most beneficial when it will coincide with an actual project that uses the technology
  3. Follow-up with professional training to get a full / clear understanding of technology, tips, tricks and best practices.

HTML

An understanding of XHTML is a good foundation for developing web based applications.  Here are some resources.

  • W3Schools is a great resource for learning XHTML
  • The browser maker Opera, in association with the Yahoo Developer Network, offers courses in standards-based Web development aimed at universities, schools and other institutions. The courses consist of several dozen chapters, downloadable for free.

DOCTYPE and validation

At UC San Diego, ITAG-UXT strives to have markup that passes XHTML 1.1 Strictrecommendations. This is declared in the DOCTYPE, which is the first line of every webpage:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
  • Doctypes affect the way devices render web pages.
  • If a correct and full doctype is present in a document, many web browsers will switch to standards mode, which means that they will follow the CSS specification closer.
  • Documents with correct and full doctypes will also render quicker because the browser doesn't have to interpret and try to compensate for invalid HTML.

Most browsers run in two modes: quirks mode for the old rules and strict mode for the standard. Mozilla, Safari, Opera, Mac/Explorer, Windows/Explorer 6 implemented these two modes. Windows/Explorer 5 and older browsers like Netscape 4, are permanently locked in quirks mode.

There are some very important reasons to use strict, or standards compliant mode. For example, Windows/Explorer 6 will use the correct box model when in strict mode, but the incorrect box model when in quirks mode. Also, many modern browsers will not allow fonts to be inherited when in quirks mode.

Max Design

In an effort to have every webpage be XHTML 1.1 Strict, ITAG-UXT recommends using the W3C's Markup Validation Service that can check the validity of your HTML markup and give specific warnings and errors to help make your page adhere to the recommendation.

Tips for avoiding common validation errors

Below are some helpful proactive tips that can help you avoid getting validation errors:

Use ID Attribute In Place Of Named Anchors

Use "id=" instead of "a name=" for in-page anchors.

Correct

<p><a href="#dogs">Jump to the part of this page that talks about dogs</a>.</p><h4 id="dogs">Dogs</h4><p>Dogs are neat</p>

Incorrect

<p><a href="#dogs">Jump to the part of this page that talks about dogs</a>.</p><h4><a name="dogs"></a>Dogs</h4><p>Dogs are neat</p>

Use Double Quotes For Attributes

Correct

<p><a href="#dogs">Jump to the part of this page that talks about dogs</a>.</p><h4 id="dogs">Dogs</h4><p>Dogs are neat</p>

Incorrect

<p><a href='#dogs'>Jump to the part of this page that talks about dogs</a>.</p>

No Dangling Elements

Correct

<p>Jump to the part of this page that talks about dogs.</p><p>Dogs are neat.</p>

Incorrect

Jump to the part of this page that talks about dogs.<p>Dogs are neat.<p>

Use Lowercase Tags

All html should be written using lower-case letters.  This applies to both tags and attributes.

Correct

<p><a href="#dogs">Jump to the part of this page that talks about dogs</a></p><h4 id="dogs">Dogs</h4><p>Dogs are neat</p>

Incorrect

<P><a HREF="#dogs">Jump to the part of this page that talks about dogs</a></P><h4 id="DOGS">Dogs</h4><p>Dogs are neat</p>

Get Rid of Font Tags

Font tags are not valid HTML. Our goal is to remove them from all content pages.

Legitimate Uses of the Break Tag

It is OK to use Break elements, but only where you would be using a hard return to break to the NEXT line. Not multiple breaks to break up paragraphs or lists.

Address

<p>Joe and Jill Jackson<br />
123 Main Street<br />
Anytown, KS 12345 </p>

Name and Title

<blockquote><p>"Risk! Risk anything! Care no more for the opinions of others, for those voices."</p><p class="cwp-source">Katherine Mansfield<br />New Zealand short story author (1888 - 1923)</p></blockquote>

Semantic markup

The following recommendations are not required for any validation or accessibility areas, but do help make the content of the page have better structure and semantics:

Use strong instead of bold

When the visual effect of bolding is used, 99% of the time it is used to draw the eye to the text, not because it is semantically/ gramatically bolded text. Instead, use the strong element. It will have the same visual effect and be semantically correct.

<p>Summer camp was <b>awesome</b>!</p>
<p>Summer camp was <strong>awesome</strong>!</p>

Use em instead of italic

When the visual effect of italics is used, 99% of the time it is used to add emphasis to the text, not because it is semantically/ gramatically italicized (i.e. book titles should be italicized). Instead, use the em element. It will have the same visual effect and be semantically correct.

<p>Students should <i>never</i> skip class.</p>
<p>Students should <em>never</em> skip class.</p>

Use tables for tabular data

Tables are meant to markup tabular data, like a spreadsheet. Using tables for layout quickly becomes a maintenance nightmare, and has serious accessibility implications.

Avoid using the break element

When you use the break element, you are trying to design the page by force. A well trained team of designers has already spent day and night sweating over every last pixel. Users everywhere have tested the design and agreed upon it. You're deviation from this standard alienates your design from all of the other campus wide designs.

If you absolutely must have additional white space, use in-line styling (but we don't recommend it).

<p>This is a paragraph.</p><br /><p>This is a paragraph far below.</p>
<p>This is a paragraph.</p><p style="margin-top:20px;">This is a paragraph far below.</p>

Pretty please

Just do this because you love us, m'kay?

Avoid in-line and in-page styling

Excessive use of in-line and/ or in-page styling adds a great deal of maintenance overhead especially for migrating from one design to another.

Use double quotes on attribute values

Why? Because someone, somewhere should lay this out as a recommendation and this seems like the best place.

<p class='subhead'>This is a paragraph.</p>
<p class="subhead">This is a paragraph.</p>

Browser Support

In order to insure that the majority of users have a consistent experience, UX&T will test all released designs and components against an array of browsers and operating systems.  However, any glue code written by developers will have to be tested by the developers.

Cascading Style Sheets

CSS is a style sheet language that describes the semantics of looks and formatting of a document written in a markup language.  Typically, it is used to style web pages written in HTML.  The main goal is to separate the document's content from the document presentation such as layout, color, and font.

Tutorials

External style sheet (in the head section)

The most common approach is to externalize the styles in a separate file.  The <link> tag goes inside the head section will define where the css file is.

<head>
<link rel="stylesheet" type="text/css" href="mystyle.css" media="all" />
</head>

The required attributes are: rel, type, href, and media.

Internal style sheet (in the body section)

UXT does not recommend this approach.  If the style will be re-used, it should be in an external style sheet.  If the style will only be used once, it should be an inline style.

Inline style (inside an HTML element)

Use this when the style is only used once.  For example, applying style to a p element where the color is blue.

<p style="color:#0000ff;">Warning!</p>

JavaScript

JavaScript is an object-oriented scripting language used to enable programmatic access to objects within the Document Object Model (DOM) of any webpage. It can provide feature-rich interactions and behaviors for end users.  UXT supports and encourages the use of two third-party JavaScript libraries when developing applications: jQuery and The Yahoo User Interface Library (YUI).

JavaScript Primer

If you are new to JavaScript, we've put together a list of good resources that will introduce you to the basics of JavaScript.  A good foundational understanding of JavaScript will help you better understand other JavaScript libraries.

Here are some great links to help you get started in understanding JavaScript:

  • JavaScript Tutorial - Put together by the folks at W3Schools, this is a great step-by-step introduction to JavaScript.  Almost like a curriculum.
  • JavaScript - The WikiPedia entry for JavaScript has a great history and insight into the background of JavaScript.
  • Learning Advanced JavaScript - A slideshow that walks you through understanding a complex JavaScript function. Written by John Resig, the author of jQuery.

jQuery

jQuery is a JavaScript Library that handles HTML document traversing, DOM manipulation, and animation. Unlike YUI, jQuery does not offer out-of-the-box solutions, but rather provides a good library for developing code. UXT uses jQuery to build glue code that communicates between widget/widget or widget/server.

  • jQuery - Official documentation, tutorials, examples from the jQuery library
  • jQueryUI - Official documentation, tutorials, examples from the jQuery UI library
  • jQuery DataTables - jQuery data table plugin that includes client side pagination, sorting and search.
  • jQueryCycle - jQuery Cycle Plugin (used on Blink homepage and throughout the CWO redesign)
  • jQuery Validation Documentation - jQuery Validation Plugin Documentation1
  • jQuery Validation - jQery Validation Plugin Website1

1 Note that while client side is convenient to the user, it can never substitute server side validation.  Never trust data from client and always have server side validation.

UCSD affiliates can also read the jQuery Cookbook online at Safari Books Online.

General

A good article on best practices to speed up your website.

Java Server Pages (JSP)

This is a working draft -- please contact Allan Kim (jak009@ucsd.edu) with corrections, suggestions, etc.

Tips:

  • A JSP page is source code that is compiled into a servlet by the container -- not interpreted code like ASP, PHP, etc. You can use this to your advantage if you understand the JSP lifecycle and the particular quirks of your application server.
  • Most containers will, by default, recompile a JSP when the underlying file has been modified. This does not extend to any includes referenced within that JSP file -- in order to ensure a full recompilation you must touch both the parent file and all includes.
  • In the Spring MVC framework, the controller will create a new RequestDispatcher to retrieve the view JSP. Therefore if you need to use any properties of the original client request (parameters, referrer, etc.), those must be passed explicitly as part of the model.
  • The current production environment supports the Servlet 2.3 / JSP 1.2 standard. Most recent books discuss the Servlet 2.4 / JSP 2.0 standard, and will discuss features that are currently unavailable to us. Don't worry if the resources listed below seem obsolete or out-of-date ... we had to seek out ancient references to find the most relevant materials.
  • The current production environment supports JSP Standard Tag Library 1.0 (JSTL) implementations only. Most books, documentation, etc. refer to JSTL 1.1 or later -- be careful when trying out code samples from the Web.

Resources:


JSP Tag Libraries

Warning: Most recent books, documentation, etc. refers to the JSP 2.0 specification. Until ACT upgrades we have to conform to the JSP 1.2 spec. To avoid skull-cracking frustration take care to use appropriate references, sample code, etc.

JSP custom tag libraries (taglibs) are a convenient way to embed reusable code in your JSP pages.

JSP 1.2 taglibs are deployed as a JAR file and a tag library descriptor (TLD) file. Most of the time the TLD file is rolled into the JAR file, but in a few cases it must be dropped into WEB-INF manually. Reference the TLD file with a JSP "taglib" directive. For example, the following code snippet is included by default:

<%@ taglib prefix="c" uri="http://java.sun.com/jstl/core"%>
<%@ taglib prefix="fmt" uri="http://java.sun.com/jstl/fmt"%>
<%@ taglib prefix="spring" uri="http://www.springframework.org/tags"%>
<%@ taglib prefix="form" uri="http://www.springframework.org/tags/form"%>

The most important taglibs for ACT development are:

JSTL is actually a package of four separate taglibs: core (output, conditionals), format, XML, and SQL. Of these the core and format taglibs will be the most useful for us. The Spring Forms taglib provides custom tags for HTML form elements, value binding, and error handling. The SiteMesh decorator taglib provides functionality for building application decorators and templates.


JSTL: JSP Standard Tag Library

Warning: Most recent books, documentation, etc. refer to JSTL 1.2 and the JSP 2.x specification. Until ACT upgrades we have to conform to the JSTL 1.0 and the JSP 1.2 spec. To avoid skull-cracking frustration take care to use appropriate references, sample code, etc.

JSTL is actually a package of four separate taglibs: core (output, conditionals), format, XML, and SQL. Of these the core and format taglibs will be the most useful for us. JSTL also introduces the very useful "EL" expression language to access and manipulate application data.

Using JSTL

The core and format taglibs are imported in WEB-INF/jsp/include-taglib.jsp:

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

Cheat sheet

Spring JSP views make heavy use of the JSTL "core" (c:) taglib.

To output a single value from the data model use the "c:out" tag. Say, for example, you passed to your data model the name-value pair "myvalue" => "42" and you need to output this in your JSP view.

<p>The answer is: <c:out value="${myvalue}" /></p>

How does this work? The "c:out" tag parses the EL expression "${myvalue}" by looking for an attribute "myvalue" in page scope, request scope, session scope, or application scope, in that order. (See Javadoc for PageContext.findAttribute() for more details.) Spring stores the name-value pairs in the data model in request scope. The tag handler then simply outputs the string value of the expression to the enclosing JspWriter.

<p>The answer is: 42</p>

What about complex values? You can use JSTL to iterate through the members of a collection, array, or even values in a comma-delimited string:

<ul>
<c:forEach var="line" items="${queryResults}">
<li><c:out value="${line}" /></li>
</c:forEach>
</ul>

In this case the "c:forEach" tag evaluates "${queryResults}" and iterates through its values, storing each value in a page-scoped variable called "line". The "c:out" tag evaluates and outputs "${line}" with each iteration.

This JSP snippet will output something like:

<ul>
<li>Curly</li>
<li>Larry</li>
<li>Moe</li>
</ul>

Likewise session, application, etc. variables can be accessed through implicit variables. Refer to the JSTL 1.0 spec (see below) for more examples and details.

More resources

Here are some resources for more information about JSTL 1.0:

Spring MVC

Before we go into Spring MVC, if you are not familiar with Spring Core, please visit the following websites.  Note that these website are somewhat dated, but the concept still applies today.

YouTube tutorial and introduction

A simple Spring MVC tutorial using pre-annotation configuration:

Spring Source's step-by-step tutorial:

Spring's @MVC (annotation) has simplified a lot of configuration.

Finally, a verbose document of Spring MVC from SpringSource:

Spring/JPA self-paced sites:

Learning SiteMesh

The open-source SiteMesh project provides a web-page layout and decoration framework to achieve a consistent look and feel across multiple web applications.

The new sitemesh.org wiki hosts some tutorials and information. More complete documentation on SiteMesh 2 is available through the Wayback Machine, including the very useful installation and configurationbuilding decorators, andtag reference documents. Source code is available through Github.

For a more detailed look at SiteMesh, you can review a presentation given by Mike Cannon-Brookes for The Server Side Symposium.  It provides a nice overview of what is SiteMesh, how it works and some advanced techniques.

SiteMesh Cheat Sheet

Need to create or tweak a decorator? Look in your skeleton webapp at:

/WEB-INF/decorators.xml

This file contains mappings between URL patterns and decorators. For example:

<decorators>
    <excludes>
        <pattern>/error.jsp</pattern>
        <pattern>/fund-list.json*</pattern>
    </excludes>
    <decorator name="default" webapp="/decorators" page="/decorators/1/financial.jsp">
        <pattern>/*</pattern>
    </decorator>
</decorators>

maps all requests to the "default" decorator by default, except for /error.jsp and/fund-list.json* (i.e. /fund-list.json?id=foobar).

SiteMesh seems to require a default /* pattern. If you need to restrict SiteMesh to one specific path, it may be easier to handle this by changing filter mapping in web.xml. Remember to reload your webapp after making changes to decorators.xml as SiteMesh won't reliably pick up changes to exclusion patterns on the fly.

The decorator JSPs themselves are in the

/decorators

web application. For example:

<%@ taglib uri="http://www.opensymphony.com/sitemesh/decorator"
    prefix="decorator" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type" />
<title><decorator:title /></title>
<%@ include file="/includes/head-elements.jsp" %>    
<decorator:head />
</head>

<body>
<div id="tdr_login">
  <!-- Start page controls -->                            
  <span class="tdr_login_content"> </span>                        
  <!-- End page controls -->
</div>
...

As you can see the decorators are pretty basic JSP, with the exception of the SiteMesh tag libraries. See the resources above for more information if/when you get into trouble. Good luck!

XML Toolkit

The following software has been provided free of charge for educational use:

  • Liquid XML Studio is a comprehensive XML Development environment, comprising a set of editors and XML tools designed for developing XML solutions.

Developer Discussion List

The ACT Developer discussion list is used to recieve input, questions, and notifications and is distributed to the members of the Tech Leads group.

Lunchtime Developer Workshops

The ACT Lunchtime Developer workshops are held bi-weekly to share all aspects of technology used at ACT.