Web Application

A web application is a software application that's accessed using a web browser over a network. In most cases, that network is the Internet, but it could also be a corporate intranet. A framework can be viewed as the foundation of a web application. It takes care of many of the low-level details that can become repetitive and boring to code, allowing the developer to focus on building the application's functionality.

Agile Development

More traditional approaches to software development (such as iterative development and the waterfall model) usually attempt to sketch out a long-running and rather static plan for an application's goals and needs using predictive methods. These development models usually approach applications from the bottom-up (that is, by working on the data first). In contrast, Agile development methods use an adaptive approach. Small teams (typically consisting of fewer than ten developers) iteratively complete small units of the project. Before starting an iteration, the team re-evaluates the priorities for the application that's being built (these priorities may have shifted during the previous iteration, so they may need adjustment). Agile developers also architect their applications from the top-down, starting with the design (which may be as simple as a sketch of the interface on a sheet of paper). When an application is built using Agile methods, it's less likely to veer out of control during the development cycle, due to the ongoing efforts of the team to adjust priorities. By spending less time creating functional specifications and long-running schedules, developers using Agile methodologies can really jump-start an application's development.

Development Framework

A framework gives the developer classes that implement common functions used in every web application, including:

• database abstraction
• templating (reusing presentational code throughout the application)
• management of user sessions
• generation of "clean" URLs

A framework also defines the architecture of an application - something that can be useful for those who constantly fret over which file is best stored in which directory. In a sense, a framework is an application that has been started already - and a well-designed one at that.

MVC

Model-View-Controller is a software architecture (also referred to as a design pattern) that separates an application into the following three distinct components:

• data model and business logic classes that talk to the databse. Find, create and save models, not to write SQL.
• graphical user interface objects and presentation logic (view) display the output, usually HTML
• user interface and application logic (controller) take user input (like a URL) and decide what to do (show a page, order an item, post a comment). Initial business logic find the right models or change data.

It's a simple concept: separate the data, logic, and display layers of a program. Split functionality cleanly, just like having separate HTML, CSS and Javascript files prevents code from mushing together. When a browser requests a web page from an MVC architected application, it's talking exclusively to the controller. The controller gathers the required data from one or more models and renders the response to the request through a view.

This separation of components:

• improves scalability (the ability for an application to grow): if an application begins experiencing performance issues because database access is slow, for example, upgrade the hardware running the database without other components being affected;
• makes maintenance easier: because the components have a low dependency on each other, making changes to one (to fix bugs or change functionality) does not affect another;
• promotes reuse: a model may be reused by multiple views, and vice versa;
• It makes the application distributable: a distinct separation of code between components means that each of them could potentially reside on a separate machine, if necessary.

The MVC pattern is key to building a readable, maintainable and easily-updateable web app.

DRY

Don't Repeat Yourself. To change the behavior of an application that's based on the DRY principle, there is no need to modify application code in more than one authoritative location. Instead of copying and pasting code with a similar or even identical functionality, develop the application in such a way that this functionality is stored once, in a central location, and is referenced from each portion of the application that needs to use it. This way, if the original behavior needs to change, only make modifications in one location, rather than in various places throughout the application (some of which may easily be overlooked).

URL

There are three kinds of characters in URLs:

Unreserved: alphanum - _ . ! ~ * ' ( ) are not escaped by browsers and can be used as is.

Reserved: ; / ? : @ & = + $ , delimit URL parts and must be escaped.

Excluded: control characters space < > # % ", { } | \ ^ [ ] ` must be escaped as well.

Microformats

hCard

This meta data profile defines some 'class' attribute values (class names) and their meanings. All values are defined according to the semantics defined in the hCard specification and thus in RFC 2426.

vcard

A container for the rest of the class names defined in this XMDP profile.

fn

Formated Name

n

Implied Name Optimization.

family-name

Last Name

given-name

First Name

additional-name

Middle Name

honorific-prefix

Honorific Prefix

honorific-suffix

Honorific Suffix

nickname

Nickname

photo

Typically used with an <img> tag. Use the 'src' attribute for URI values. Use the 'data:' URI scheme for binary values.

bday

Typically used with an <abbr> tag with the <title> attribute for the Birthday Date value, and a human readable Birthday Date inside the element.

adr

Address

post-office-box

P.O. Box

extended-address

Extended Address

street-address

Street Address

locality

City/Town

region

State/Province

postal-code

ZIP/Postal Code

country-name

Country

type

Address Type

value

distinguish actual *value* of a property from any other cruft that may be in the element representing the property

label

Formatted Address Label

tel

Telephone Number (home, msg, work, pref, voice, fax, cell, video, pager, bbs, modem, car, isdn, pcs)

email

Email Address

mailer

Type of electronic mail software used by the individual

tz

Typically used with an <abbr> tag with the 'title' attribute for the Time Zone value, and a human readable Time Zone inside the element.

geo

Geographical Location

latitude

Latitude

longitude

Longitude

title

Title

role

Role

logo

Typically used with an <img> tag. Use the 'src' attribute for URI values. Use the 'data:' URI scheme for binary values.

agent

If the value is a vCard, then use a nest hCard. For simplicity in that case, the same element that has the class name of "agent" should use the class name of "vcard".

org

Organization

organization-name

Implied Organization Name Optimization.

organization-unit

Organization Unit

category

Category

note

Note

rev

Typically used with an <abbr> tag with the 'title' attribute for the Revision Date value, and a human readable Revision Date inside the element.

sort-string

Sort String

sound

Typically used with either an <a> or <object> tag. Use the 'data:' URI scheme for binary values.

uid

UID

url

Typically used with an <a> tag.

class

Class

key

Typically used with an <abbr> tag with the 'title' attribute for the Key value, and a human readable Key equivalent inside the element.

hCalendar

This meta data profile defines some 'class' attribute values (class names) and their meanings. All values are defined according to the semantics defined in the hCalendar specification and thus in RFC 2445.

vcalendar

A container for one or more events (vevent). This property is optional; if there is only one event then omit it.

vevent

A container for one event.

dtstart

Date/time of the start of the event.

dtend

Date/time of the end of the event.

duration

Length of the event.

summary

Short synopsis, title, or name of the event.

uid

A globally unique identifier for the event; typically a URL is used.

dtstamp

Date/time of when the document containing information about the event was created.

method

Function of the event object. Values for this property are: PUBLISH, REQUEST, REPLY, ADD, CANCEL, REFRESH, COUNTER, or DECLINECOUNTER. For example, a value of REQUEST indicates that a request is being made for the event to occur.

category

Category of the event object. Note: this property may be repeated (an event may belong in several categories). Common values are: MEETING, APPOINTMENT, CONFERENCE, EXPO.

location

Tells where the event is to be held. May be represented by nested hCard record, adr record, geo record, or combination thereof.

url

A URL to a page that contains the definitive/preferred information about an event; UID and URL are typically the same.

description

A more detailed synopsis of the event than that provided by summary.

last-modified

Date/time the information about the event was updated.

status

Status of the calendar event. Values are: TENTATIVE, CONFIRMED, CANCELLED.

class

Access classification of the event information; Values are: PUBLIC, PRIVATE, CONFIDENTIAL.

attendee

An individual invited to attend the event; An event container may contain more than one attendee record; May be represented by nested hCard record.

contact

Contact information associated with the event; May be represented by nested hCard record.

organizer

The organizer associated with the event; May be represented by nested hCard record. See section 4.8.4.3 of RFC 2445.

Emoticons