Asp.NET Web Development Process

Asp.NET Web Development Process

This document helps define a development process for the entire project life cycle.

1. Requirements Gathering
   
   A “requirement” is simply a statement of what the business needs to accomplish. At a high level, the business case or justification for the project should be defined as a requirement(s). Then by analysis of this high level requirement(s), additional requirements will flow at an increasing level of detail.
   
   The requirements gathering process results in a living document that will continue to change and grow throughout the project life cycle. Requirements will continue to be refined in the analysis phase.
   
   Here are some guidelines for requirements gathering:

   1. The requirement must be from the business perspective. Every requirement should be clear from the client’s perspective and be relevant to their business needs. This is the time to focus on the business side of things. Keep the technical “how” out of the discussion until all the business requirements are clearly defined. This will keep the project focused on what the business needs.

   2. Come prepared to the first requirements gathering meeting with the start of a requirements document. You should have enough in the requirements document, even if it’s 100% assumptions, to help facilitate the gathering process by engaging the client. Even making the wrong assumptions about things are helpful as it will help facilitate feedback and get the client thinking about their needs.

   3. While technical implementation details do not belong in this document, your perspective on the requirements will help you ask the “right” questions. You should use your experience to facilitate the client thinking about the “right” things, and to help uncover business requirements the client would not normally think about. For example; validation and data rules, data security, web site security, privacy, integration with other systems, reporting, exporting, etc are all business requirements.

   4. Follow leads based on the clients’ responses and continue to push until you get concrete answers. The wording should be definite with terms like "must", "will", or "shall". Avoid terms that leave options open like "could" or "may". If concrete answers cannot be determined for a given requirement, flag them and then use the Analysis phase to dig deeper until you get to the bottom of it.

   5. Get customer approvals of all requirements. You will want to fill in blanks on behalf of the business, but if you do, make sure you always get customer approval for your assumptions.

   6. The requirement should be testable. Ask yourself how you would generally go about testing a requirement. Since the system isn't built, you have to make assumptions about user interface and the like. At a very high level, get the test plan outlined with a short statement on how each requirement should be tested. If you find it difficult to come up with a test or a description of how a test should work, evaluate the requirement to see if it should be better written, is too costly to implement, or isn't practical.

   7. Estimating – Use the following formulas for calculating ranges for estimating based on your requirements.

      1. Order of Magnitude (Done during Initiating) - 25% to +75%

      2. Budget Estimate (Done during Planning) -10% to +25%

      3. Definitive Estimate (Done during Planning) - 5% to +10%

2. Analysis
   
   Analysis is the process of refining requirements and defining the processes for the solution. Analysis is still business centric (meaning it’s from the business perspective and makes sense to the client), but the objective is more technical. At the end of the Analysis Phase, you should have enough details about each requirement to “Design” the solution.

   1. Analysis normally takes the form of Use Cases, but can also include:

      1. Demo’s

      2. Wire-frames

      3. Prototypes

   2. A Use Case is a narrative form of a process that is needed to meet each requirement. See Appendix A for a template.

      1. Identify actors. An actor is a user of the system or other system that interacts with this one.

      2. Build Use Cases for each concrete requirement.

      3. Associate Use Cases with an Actor and make sure the Use Case is from the Actor’s perspective.

      4. Define how data will be collected and used.

         1. Will they need to report on this data?

         2. Will 3^rd party systems need to use it?

         3. Is there a need to export this data? To what formats?

         4. What validation rules should be required?

      5. Define where data will come from that is required by the Use Case.

         1. Will someone be entering the data?

         2. Is the data static, or something that needs to change regularly?

         3. Is the data coming from a 3^rd party system?

         4. Is the data dependent on a previous process being completed in this solution?

         5. Use Cases should be complete and approved by the client before entering the “Design” phase.

3. Design
   
   Design is the process of taking solidified Use Cases (and related Requirements), and translating them into a Solution Design. This Solution Design should clearly communicate to a developer how the solution should be written. A Solution Design should contain:

   1. Static Structure – This UML diagram will define all objects in the solution. In lieu of a diagram, the Business Layer can be used to build these object directly, as long as they are documented as to which use case and requirements they are designed to meet. Use Case nouns are potential objects (business and data access objects), and verbs potential operations.

   2. Sequence Diagrams – These UML diagrams should map to a specific Use Case and show how the objects identified in the Static Structure for this Use Case will be used to accomplish the intended outcome.

   3. Prototypes and wire-frames – This should define how the UI should look and function.

4. Construction
   
   Construction is the process of taking the culmination of knowledge from the Analysis and Design phases to produce code for the solution. While construction doesn’t require that all of the Analysis and Design be completed for the entire solution before any code is written, it does require that:

   1. All major components of the solution are defined at a high level.

   2. Dependencies and communication requirements between these components are identified.

   3. Requirements and Design artifacts are completed and approved (if necessary) for the component being developed.

Construction standards are strictly followed during the construction phase of the project. While these standards are not the only way to do things, it is necessary to adopt one way for consistency and interoperability during the construction and integration of a solution. Here is a list of these standards:

4. Camel Casing
   
   Camel casing occurs when all words of an identifier are capitalized, except for the first word. The identifiers firstName, productId, and email are all examples of using camel casing.

   1. Use camel casing for private type fields, parameters, and local variables.

5. Pascal Casing
   
   Pascal casing occurs when the first letter of every word in an identifier is capitalized. ProductName, CompanyName, and Email are examples of PascalCasing.

   1. Use Pascal casing everywhere except for when you use camel casing. For example, property names, operations, and tables.

6. Field, Local Variable, and Parameter Naming
   
   Fields are variables declared at the type level. Local variables are declared within methods, property accessors, and indexer accessors. Parameters are part of the declaration of methods, indexers, and delegates and enable code to pass arguments.

   1. Prefix field names with "_". The identifiers _firstName, _companyId, and _email are proper field names.

   2. Don't prefix Local variables and parameters. The identifiers firstName, companyId, and primaryEmailAddress are valid local variables.

7. UI Elements
   
   UI Elements should be explicitly named if it is referenced anywhere on the page or in the code-behind.

   1. UI Elements should be prefixed to show what type of UI element it is: “lbl” for Label, “txt” for TextBox, etc.

   2. They should have “friendly” names that are applicable to how that control is being used.

8. Delegates and Events

   1. Event names can use the VS assigned convention, but be sure the parent control has been named appropriately before the event is created.

   2. Name Delegates with a “Handler” Suffix.
      
      

9. Software Development Methodology
   
   During the construction phase, a Software Development Methodology is used to improve overall quality of the solution, as well as enhance flexibility and maintenance over the lifecycle of the application. This methodology follows best practices of n-tier software design to separate out UI, Business and Data Access layers into separate manageable pieces of the application.

   1. High Cohesion

OO design is highly cohesive when the objects are singular in their purpose and their purpose is well thought out and maintained.

This also means that at a smaller level, your methods should follow the same general rule. Methods should be as simple and concise as possible. It is better to have several smaller methods to carry out a specific operation, then to have one large method that is harder to read and therefore debug.

2. Loosely Coupled
   
   OO design is loosely coupled when the application, and it’s parts, are independent in their nature. Meaning, the application, one of it’s components, or a single object can be modified without have a ripple effect in the rest of the system, or to other systems
   
   The way this is accomplished is by designing for high cohesions at the system, component, object, and method level, and carefully handling the communication at each one of these levels to reduce the dependency at each.

3. Interfaces
   
   Interfaces should be used to provide all up-stream access between layers. Interfaces should also be considered when an object is shared among multiple Managers (UI processes) as an additional layer of abstraction.

4. User Interface Layer
   
   User Interface Layer is the GUI of the application. For ASP.NET applications, this includes the ASPX and ASPX code-behind.

   1. Use .NET UI components – In all instances possible, .NET components should be utilized for the GUI.

   2. Use Object Data Sources – This provides design view readability into the BLL and DAL process without loosing encapsulation.

   3. Use the code-behind – Avoid writing any embedded code with the UI. Instead, utilize the code-behind.

   4. Use Master Pages, Skins, and Themes – This will provide encapsulation of design from the actual ASPX pages. Doing this will provide consistency for the look and feel, as well as ease of managing changes to the design in the future.

   5. Use Cascading Style Sheets – CSS should be the primary layout means for overall UI control and design. Avoid using tables, inline styles and outdated formatting options (I.E. font tags).

5. Business Layer
   
   The business layer contains object that encapsulate the domain of business logic for the application.
   
   This domain has two objectives:
   
   1. Abstract the UI from data access and business logic.
   2. Provide communication between the UI and BLL/DAL.
   
   To accomplish the domain’s objectives, we’ve adopted the following standard objects:

   1. Managers – Manager objects are used in the code-behind of the aspx page as well as in the DAL (see Data-Access Layer below). They provide single-point-access for all BLL (explicit) and DAL (implicit) functions the application needs to accomplish from the UIL.

6. Data-Access Layer
   
   The data-access layer provides mechanisms for retrieving and populating data into BLL objects.

   1. Gateways – Gateways are the primary data-access objects. They work in conjunction with a reference to a “Manager” to create business objects and populate them will data.

   2. For BLL access use Interfaces – Because business objects are upstream from the DAL, all interaction with this layer should be handles through interfaces. Additionally, interaction with the BLL should be isolated to using “Managers”.

   3. Use parameters when creating your queries by using the SqlCommand object.

   4. Populate BLL objects – In general, business objects should be used to populate with data.
      
      Here are some exceptions to this rule:

      1. You are doing a data-centric operation (requires no business logic). For example, binding search results to a data grid.

      2. You want to provide a generic data transport. For example, when using web services datasets can provide a very agnostic data transport mechanism. Datasets can also easily translate to XML.

   5. Read – This would involve any “Select” type operation.

      1. Use Views – This will provide a layer of abstraction for the underlying table structure.

      2. Utilize the “Managers” to create needed BLL objects and perform other business related functions.

      3. Create methods specifically for populating BLL objects from data readers.

      4. Only send in what is necessary from the BLL to retrieve the data. This typically means a primary key.

      5. Return populated BLL objects to the “Manager”.

   6. Create – This would include any “Insert” type operation.

      1. Send in the BLL object containing the data for the insert operation. Remember, this must be referenced as an interface.

      2. Use transactions when inserting into multiple tables at once.

      3. Return the updated BLL object to the “Manager”.

   7. Delete – In general, deletes take two forms:
      
      A Soft delete – This flags a record as deleted, but doesn’t actually delete the record.
      
      A Hard delete – This actually deletes a record from the database.

      1. Both “Hard” and “Soft” deletes should be written into the DAL, typically only utilizing the “Soft” delete from the UIL.

      2. Use transactions when deleting from more then one table.

      3. Only send in what is necessary from the BLL to retrieve the data. This typically means a primary key.

   8. Update – This would be any “Update” type operation.

      1. Send in the BLL object containing the data to use for the update operation. Remember, this should be referenced as an interface.

      2. Use transactions when updating more then one table.

      3. Return the updated object to the “Manager”.

5. Test
   
   Testing is the process of ensuring quality of the solution. The solutions quality is measured by how well it handles defined requirements, and how well it performs in that capacity.
   
   Testing preparation starts at the Analysis phase by analyzing requirements to determine how to test for each. Then, as construction for each requirement takes place, testing is done to ensure that the constructed artifact does in fact meet the requirements it was designed to. Testing is continued throughout deployment to ensure quality at the solution level.
   
   Testing procedures:

   1. Unit Testing – This is the process of testing highly specialized parts of the system to make sure they handle their specific requirements correctly before they are integrated into larger components.

   2. Component Testing – Component Testing will ensure that as highly specialized artifacts are brought together to build larger components of the overall system, they will continue to perform their specialized requirements and work together to accomplish a larger set of required functionality.

   3. Integration Testing – Integration Testing is the process of testing component as they are integrated together to compose a functional piece of the solution. Testing is done to ensure the component meets requirements as defined for the component and that the integrated set of components meets overall business requirements for the solution as a whole.

   4. Regression Testing – Regression Testing is the process of testing peripheral functionality (functionality outside of what was explicitly changed or added) to ensure changes did not have negative impact to any part of the system.

   5. Usability Testing – Usability Testing will ensures that working parts of the solution have acceptable usability based on business requirements.

   6. Acceptance Testing – As a final step of the testing process, clients/end users will have an opportunity to test working parts of the solution to make sure it meets their expectations as was defined during the Requirements and Analysis phases of the project.

6. Deploy
   
   Deployment is the process of moving tested functional parts of the solution resulting from the Construction phase into a different environment. This environment can be integration with overall solution in a development environment, moving the solution to a test or production environment, or integrating the solution with a 3^rd party system. Before this can happen the following must be true:

   1. The artifact has been tested to make sure it meets the requirements as defined by the business.

   2. The artifact has been tested to ensure that is performs these operations well; without error and with proper usability.

   3. The artifact has been tested to ensure interoperability with the rest of the solution and any dependent systems (Regression Testing).

Appendix A – Use Cases Guidance/Template

The following table describes the elements you should add to your Use Case diagrams:

Section Title	Description
UC Name	ID of Use Case – i.e. 1.2.3. Can use Tag in Visio.
Actor	Person or System performing Use Case tasks. Represented as part of Use Case diagram.
Requirement	ID from requirements documentation. – i.e. 1.2.3. Provides tracability. Can use Tag in Visio.
Pre-condition	Pertinent facts that must be true about the system prior to beginning tasks.
Tasks	Flow of work that actor engages in to accomplish Use Case. Represents the "normal" flow. Alterations of the flow should go in Task Exceptions. For any significant alterations, or any task sequences that differ significantly from the normal flow or are hard to describe in a sequence diagram, create a new Use Case and rename present Use Case to be more specific. If you encounter the same task sequence across two or more Use Cases, break the subset of tasks into their own Use Case and reference the new Use Case with an Extends or Uses association.
Task Exceptions	Paths that alter the normal task flow should be documented as Task Exceptions. If the exception is significant, consider creating a new Use Case and renaming the present Use Case to something more specific.
Post-condition	Pertinent facts that must be true about the system after completion.
Notes	Create a note for anything that doesn't fit in other categories. i.e. assumptions, business rules, and constraints.

Use the following item as a template. Documentation is provided separately, in the table above, so you can easily copy and paste this template:

UC Name:

Actor:

Requirement:

Pre-condition:

Tasks:

Task Exceptions:

Post-condition:

Notes:

jQuery - The Basics

jQuery - The Basics

This is a basic tutorial, designed to help you get started using jQuery. If you don't have a test page setup yet, start by creating a new HTML page with the following contents:

  <html>
  <head>
    <script type="text/javascript" src="path/to/jquery.js"></script>
    <script type="text/javascript">
      // Your code goes here
    </script>
  </head>
  <body>
    <a href="http://jquery.com/">jQuery</a>
  </body>
  </html>

Edit the src attribute in the script tag to point to your copy of jquery.js. For example, if jquery.js is in the same directory as your HTML file, you can use:

 <script type="text/javascript" src="jquery.js"></script>

You can download your own copy of jQuery from the Downloading jQuery page.

[edit]

Launching Code on Document Ready

The first thing that most Javascript programmers end up doing is adding some code to their program, similar to this:

 window.onload = function(){ alert("a") }

Inside of which is the code that you want to run right when the page is loaded. Problematically, however, the Javascript code isn't run until all images are finished downloading (this includes banner ads). The reason for using window.onload in the first place is due to the fact that the HTML 'document' isn't finished loading yet, when you first try to run your code.

To circumvent both problems, jQuery has a simple statement that you can use, known as the ready event:

 $(document).ready(function(){
   // Your code here
 });

This code checks the document and waits until it's ready to be manipulated - which is just what we want. So take the above snippet and stick it into the script area on your test page. The remaining jQuery examples will need to be placed inside this callback function, so they are executed when the document is ready to be worked on.

[edit]

Making Something Happen on Click

The first thing we're going to try is having something happen whenever a link is clicked. In the ready function (from the example above), add the following:

 $("a").click(function(){
   alert("Thanks for visiting!");
 });

Save your HTML file and reload the test page in your browser. Clicking the link on the page should make a browser's alert pop-up, before leaving to go to the main jQuery page.

For click and most other events, you can prevent the default behaviour - here, following the link to jquery.com - by returning false from the event handler:

 $("a").click(function(){
   alert("Thanks for visiting!");
   return false;
 });

[edit]

Adding a Class

Another thing that is a common task is the addition (or removal) of classes from elements, for example:

 $("a").addClass("test");

if you were to add some style information into the header of your script, like this:

 <style type="text/css">a.test { font-weight: bold; }
 </style>

and then added the above addClass call - all your A elements would now be bold. To remove the class, you'd use removeClass

[edit]

Special Effects

In jQuery, a couple handy effects are provided, to really make your web site stand out. To put this to the test, change the click that you added earlier to this:

 $("a").click(function(){
   $(this).hide("slow");
   return false;
 });

Now, if you click any link, it should make itself slowly disappear.

[edit]

Chainability (The Magic of jQuery)

jQuery uses an interesting concept to make its code short and simple. For those familiar with object-oriented programming, this concept should be rather straightforward.

In a nutshell: Every method within jQuery returns the query object itself, allowing you to 'chain' upon it, for example:

 $("a").addClass("test").show().html("foo");

Each of those individual methods (addClass, show, and html) return the jQuery object, allowing you to continue applying methods to the current set of elements.

You can take this even further, by adding or removing elements from the selection, modifying those elements and then reverting to the old selection, for example:

 $("a")
   .filter(".clickme")
     .click(function(){
       alert("You are now leaving the site.");
     })
   .end()
   .filter(".hideme")
     .click(function(){
       $(this).hide();
       return false;
     })
   .end();

Which would work against the following HTML:

 <a href="http://google.com/" class="clickme">I give a message when you leave</a>
 <a href="http://yahoo.com/" class="hideme">Click me to hide!</a>
 <a href="http://microsoft.com/">I'm a normal link</a>

Methods that modify the jQuery selection, and that can be undone with end(), are the following:

• add(),
• children(),
• eq(),
• filter(),
• find(),
• gt(),
• lt(),
• next(),
• not(),
• parent(),
• parents() and
• siblings().

Please check the Traversing API documentation for details of these methods.

[edit]

Callbacks, Functions, and 'this'

A callback is a function that is passed as an argument to another function and is executed after its parent function has completed. The special thing about a callback is that functions that appear after the "parent" can execute before the callback executes.

Another important thing to know is how to properly pass the callback. This is where I have often forgotten the proper syntax.

[edit]

Callback without arguments

For a callback with no arguments you pass it like this:

 $.get('myhtmlpage.html', myCallBack);

Note that the second parameter here is simply the function name (but not as a string and without parentheses). Functions in Javascript are 'First class citizens' and so can be passed around like variable references and executed at a later time.

[edit]

Callback with arguments

"What do you do if you have arguments that you want to pass?", you might ask yourself.

[edit]

Wrong

The Wrong Way (will not work!)

 $.get('myhtmlpage.html', myCallBack(param1, param2));

This will not work because it calls myCallBack(param1, param2) then passes the return value as the second parameter to $.get().

[edit]

Right

The Right Way ( note the use of function(){ preceding myCallBack() )

 $.get('myhtmlpage.html', function(){
   myCallBack(param1, param2);
 });

So, by passing in an anonymous function (the part with...

 function(){ 
   myCallBack(param1, param2);
 }

...which itself calls your function with arguments), you're done.

This method works because it passes the anonymous function as the second parameter to $.get() without executing it first.

[edit]

More Reading

jQuery users have developed a number of helpful tutorials to help guide you, the new jQuery user, through the process of learning how to best use this library. Again, if we could not describe properly the features of the jQuery-library... simply let us know about it.

From here, you should probably begin looking at the rest of the Documentation - it's very comprehensive and covers all aspects of jQuery. If you have any questions, please feel free to send a message to the mailing list.

Name Code	Number Code	Glyph	Description
‘		‘	left single quote
’		’	right single quote
‚		‚	single low-9 quote
“		“	left double quote
”		”	right double quote
„		„	double low-9 quote
†		†	dagger
‡		‡	double dagger
‰		‰	per mill sign
‹		‹	single left-pointing angle quote
›		›	single right-pointing angle quote
♠		♠	black spade suit
♣		♣	black club suit
♥		♥	black heart suit
♦		♦	black diamond suit
	★	★	black star
	☆	☆	white star
‾		‾	overline, = spacing overscore
←		←	leftward arrow
↑		↑	upward arrow
→		→	rightward arrow
↓		↓	downward arrow
™		™	trademark sign
Name Code	Number Code	Glyph	Description
	�-		unused
				horizontal tab
	
		line feed
			unused
	 		space
	!	!	exclamation mark
"	"	"	double quotation mark
	#	#	number sign
	$	$	dollar sign
	%	%	percent sign
&	&	&	ampersand
	'	'	apostrophe
	(	(	left parenthesis
	)	)	right parenthesis
	*	*	asterisk
	+	+	plus sign
	,	,	comma
	-	-	hyphen
	.	.	period
Name Code	Number Code	Glyph	Description
⁄	/	/	slash
	0-9		digits 0-9 (see numbers & letters)
	:	:	colon
	&#59;	;	semicolon
&lt;	&#60;	<	less-than sign
	&#61;	=	equals sign
&gt;	&#62;	>	greater-than sign
	&#63;	?	question mark
	&#64;	@	at sign
	&#65;-&#90;		uppercase letters A-Z (see numbers & letters)
	&#91;	[	left square bracket
	&#92;	\	backslash
	&#93;	]	right square bracket
	&#94;	^	caret
	&#95;	_	horizontal bar (underscore)
	&#96;	`	grave accent
	&#97;-&#122;		lowercase letters a-z (see numbers & letters)
	&#123;	{	left curly brace
	&#124;	|	vertical bar
Name Code	Number Code	Glyph	Description
	&#125;	}	right curly brace
	&#126;	~	tilde
	&#127;-&#149;		unused
&ndash;	&#150;	–	en dash
&mdash;	&#151;	—	em dash
	&#152;-&#159;		unused
&nbsp;	&#160;		nonbreaking space
&iexcl;	&#161;	¡	inverted exclamation
&cent;	&#162;	¢	cent sign
&pound;	&#163;	£	pound sterling
&curren;	&#164;	¤	general currency sign
&yen;	&#165;	¥	yen sign
&brvbar; or &brkbar;	&#166;	¦	broken vertical bar
&sect;	&#167;	§	section sign
&uml; or &die;	&#168;	¨	umlaut
&copy;	&#169;	©	copyright
&ordf;	&#170;	ª	feminine ordinal
&laquo;	&#171;	«	left angle quote
&not;	&#172;	¬	not sign
&shy;	&#173;	­	soft hyphen
&reg;	&#174;	®	registered trademark
&macr; or &hibar;	&#175;	¯	macron accent
Name Code	Number Code	Glyph	Description
&deg;	&#176;	°	degree sign
&plusmn;	&#177;	±	plus or minus
&sup2;	&#178;	²	superscript two
&sup3;	&#179;	³	superscript three
&acute;	&#180;	´	acute accent
&micro;	&#181;	µ	micro sign
&para;	&#182;	¶	paragraph sign
&middot;	&#183;	·	middle dot
&cedil;	&#184;	¸	cedilla
&sup1;	&#185;	¹	superscript one
&ordm;	&#186;	º	masculine ordinal
&raquo;	&#187;	»	right angle quote
&frac14;	&#188;	¼	one-fourth
&frac12;	&#189;	½	one-half
&frac34;	&#190;	¾	three-fourths
&iquest;	&#191;	¿	inverted question mark
&Agrave;	&#192;	À	uppercase A, grave accent
&Aacute;	&#193;	Á	uppercase A, acute accent
&Acirc;	&#194;	Â	uppercase A, circumflex accent
Name Code	Number Code	Glyph	Description
&Atilde;	&#195;	Ã	uppercase A, tilde
&Auml;	&#196;	Ä	uppercase A, umlaut
&Aring;	&#197;	Å	uppercase A, ring
&AElig;	&#198;	Æ	uppercase AE
&Ccedil;	&#199;	Ç	uppercase C, cedilla
&Egrave;	&#200;	È	uppercase E, grave accent
&Eacute;	&#201;	É	uppercase E, acute accent
&Ecirc;	&#202;	Ê	uppercase E, circumflex accent
&Euml;	&#203;	Ë	uppercase E, umlaut
&Igrave;	&#204;	Ì	uppercase I, grave accent
&Iacute;	&#205;	Í	uppercase I, acute accent
&Icirc;	&#206;	Î	uppercase I, circumflex accent
&Iuml;	&#207;	Ï	uppercase I, umlaut
&ETH;	&#208;	Ð	uppercase Eth, Icelandic
&Ntilde;	&#209;	Ñ	uppercase N, tilde
&Ograve;	&#210;	Ò	uppercase O, grave accent
&Oacute;	&#211;	Ó	uppercase O, acute accent
&Ocirc;	&#212;	Ô	uppercase O, circumflex accent
&Otilde;	&#213;	Õ	uppercase O, tilde
Name Code	Number Code	Glyph	Description
&Ouml;	&#214;	Ö	uppercase O, umlaut
&times;	&#215;	×	multiplication sign
&Oslash;	&#216;	Ø	uppercase O, slash
&Ugrave;	&#217;	Ù	uppercase U, grave accent
&Uacute;	&#218;	Ú	uppercase U, acute accent
&Ucirc;	&#219;	Û	uppercase U, circumflex accent
&Uuml;	&#220;	Ü	uppercase U, umlaut
&Yacute;	&#221;	Ý	uppercase Y, acute accent
&THORN;	&#222;	Þ	uppercase THORN, Icelandic
&szlig;	&#223;	ß	lowercase sharps, German
&agrave;	&#224;	à	lowercase a, grave accent
&aacute;	&#225;	á	lowercase a, acute accent
&acirc;	&#226;	â	lowercase a, circumflex accent
&atilde;	&#227;	ã	lowercase a, tilde
&auml;	&#228;	ä	lowercase a, umlaut
&aring;	&#229;	å	lowercase a, ring
&aelig;	&#230;	æ	lowercase ae
&ccedil;	&#231;	ç	lowercase c, cedilla
&egrave;	&#232;	è	lowercase e, grave accent
Name Code	Number Code	Glyph	Description
&eacute;	&#233;	é	lowercase e, acute accent
&ecirc;	&#234;	ê	lowercase e, circumflex accent
&euml;	&#235;	ë	lowercase e, umlaut
&igrave;	&#236;	ì	lowercase i, grave accent
&iacute;	&#237;	í	lowercase i, acute accent
&icirc;	&#238;	î	lowercase i, circumflex accent
&iuml;	&#239;	ï	lowercase i, umlaut
&eth;	&#240;	ð	lowercase eth, Icelandic
&ntilde;	&#241;	ñ	lowercase n, tilde
&ograve;	&#242;	ò	lowercase o, grave accent
&oacute;	&#243;	ó	lowercase o, acute accent
&ocirc;	&#244;	ô	lowercase o, circumflex accent
&otilde;	&#245;	õ	lowercase o, tilde
&ouml;	&#246;	ö	lowercase o, umlaut
&divide;	&#247;	÷	division sign
&oslash;	&#248;	ø	lowercase o, slash
&ugrave;	&#249;	ù	lowercase u, grave accent
&uacute;	&#250;	ú	lowercase u, acute accent
&ucirc;	&#251;	û	lowercase u, circumflex accent
Name Code	Number Code	Glyph	Description
&uuml;	&#252;	ü	lowercase u, umlaut
&yacute;	&#253;	ý	lowercase y, acute accent
&thorn;	&#254;	þ	lowercase thorn, Icelandic
&yuml;	&#255;	ÿ	lowercase y, umlaut
Name Code	Number Code	Glyph	Description
	&#48;	0	0
	&#49;	1	1
	&#50;	2	2
	&#51;	3	3
	&#52;	4	4
	&#53;	5	5
	&#54;	6	6
	&#55;	7	7
	&#56;	8	8
	&#57;	9	9
	&#65;	A	A
	&#66;	B	B
	&#67;	C	C
	&#68;	D	D
	&#69;	E	E
	&#70;	F	F
	&#71;	G	G
	&#72;	H	H
	&#73;	I	I
	&#74;	J	J
	&#75;	K	K
	&#76;	L	L
	&#77;	M	M
	&#78;	N	N
	&#79;	O	O
	&#80;	P	P
	&#81;	Q	Q
	&#82;	R	R
	&#83;	S	S
	&#84;	T	T
	&#85;	U	U
	&#86;	V	V
	&#87;	W	W
	&#88;	X	X
	&#89;	Y	Y
	&#90;	Z	Z
	&#97;	a	a
	&#98;	b	b
	&#99;	c	c
	&#100;	d	d
	&#101;	e	e
	&#102;	f	f
	&#103;	g	g
	&#104;	h	h
	&#105;	i	i
	&#106;	j	j
	&#107;	k	k
	&#108;	l	l
	&#109;	m	m
	&#110;	n	n
	&#111;	o	o
	&#112;	p	p
	&#113;	q	q
	&#114;	r	r
	&#115;	s	s
	&#116;	t	t
	&#117;	u	u
	&#118;	v	v
	&#119;	w	w
	&#120;	x	x
	&#121;	y	y
	&#122;	z	z