Using Multiple JavaScript Onload Functions
JavaScript is one of the most popular programming languages in use on the World Wide Web. It can create interactive pages through the use of menus, forms and calendars. It can also be used to track a visitor's history on your site, play games and many other things.
When scripts are written they're used to accomplish a given task, e.g., create a rotating picture gallery, or to validate a form. This means that for each different type of usage, a separate script is necessary. Often, a script is called using an onload function.
Loading the Page
When a Web page is loaded, the code on the page — whether HTML, CSS, PHP, or some other type — is generally processed from the top down. As the browser comes upon a section of code, it's executed and the intended action is (hopefully) performed. Let's say you have the following script in the head section of a Web page:
1 function func1() {
2 alert("This is the first.");
3 }
4
5 window.onload=func1;
view plain | print | ?
function func1() { alert("This is the first."); } window.onload=func1;
When the page is loaded, the browser will stop at the script above and execute it. An alert window will pop up and the page will stop loading until the alert window is closed. Often, this isn't an issue, but if the script needs to access elements on the page that aren't yet loaded (i.e., below the current code), you will encounter problems. To resolve these, here are a few solutions.
Move it to the Bottom
One method is to place the script at the bottom of the Web page, just above the closing </body> tag. This does, however, present a few problems. First, there is a period of time that those elements which are you seeking to change with the script will be clearly seen by the visitor. Then, once the script is executed, they will "magically" change. With a fast loading page and a script that executes quickly, this might not be a problem, but if the original elements can be seen by the visitor, and are then changes, the visitor may perceive it to be some type of a hack or bug on the page, and leave the site immediately. Obviously, that's not good.
Secondly, either the script, or a link to it, will need to be included in the actual HTML body code. That's not unobtrusive JavaScript. It's best if you can keep everything separate. You'll find it's easier to work on any aspect of the page, and the page itself will load faster.
The onload Function
The window object in JavaScript has an event handler called onload. When this event handler is used, the entire page and all of its related files and components are loaded before the function listed in the onload event handler is executed, hence the term "on load."
As shown in the script above, it's easy to use, but what if you have more than one function you want to call using an onload event handler?
You would think you could just stack them like this:
1 window.onload=func1;
2 window.onload=func2;
3 window.onload=func3;
view plain | print | ?
window.onload=func1; window.onload=func2; window.onload=func3;
Unfortunately, it's not that simple. After the first onload event handler is executed, it will be replaced when the second onload event handler is executed. That, in turn, will be replaced immediately just as soon as the third onload event handler is executed. There are workarounds for this, though.
Let's Put Them in a Chain
One method that has been used quite a bit is the linking of multiple events. It places several function calls in a chain, using one onload event handler. The method would look like this:
<body onload="func1(); func2();">
<body onload="func1(); func2();">
Still, once again we run into the unobtrusive problem. In addition, you will need to add this to the <body> tag of every page that needs to use the called functions. That could be quite tedious for a large Web site, especially when changes or additions are needed.
Within Another Function
Another method is the following script:
1 function start() {
2 func1();
3 func2();
4 }
5
6 window.onload = start;
view plain | print | ?
function start() { func1(); func2(); } window.onload = start;
While this is good, there's one method that's even better.
The addLoadEvent Function
1 function addLoadEvent(func) {
2 var oldonload = window.onload;
3 if (typeof window.onload != 'function') {
4 window.onload = func;
5 } else {
6 window.onload = function() {
7 if (oldonload) {
8 oldonload();
9 }
10 func();
11 }
12 }
13 }
14
15 addLoadEvent(nameOfSomeFunctionToRunOnPageLoad);
16 addLoadEvent(function() {
17 /* more code to run on page load */
18 });
view plain | print | ?
function addLoadEvent(func) { var oldonload = window.onload; if (typeof window.onload != 'function') { window.onload = func; } else { window.onload = function() { if (oldonload) { oldonload(); } func(); } } } addLoadEvent(nameOfSomeFunctionToRunOnPageLoad); addLoadEvent(function() { /* more code to run on page load */ });
This function was written by Simon Willison. It has several advantages. For one, it's really unobtrusive. It can be placed in a file with your other scripts or in a separate file. (If it's in a separate file, just be sure to call it after the other files, so the functions will be available.)
Also, it works even if the onload event handler has been previously assigned. Simon explains it like this:
"The way this works is relatively simple: if window.onload has not already been assigned a function, the function passed to addLoadEvent is simply assigned to window.onload. If window.onload has already been set, a brand new function is created which first calls the original onload handler, then calls the new handler afterwards."
Isn't that beautiful? So, if you already have a script that uses the onload event handler, you don't need to dig it out and change it, unless you want to. It also allows for extra code. Here's an example that calls two functions and adds a third, independent addLoadEvent:
1 function func1() {
2 alert("This is the first.");
3 }
4
5 function func2() {
6 alert("This is the second.");
7 }
8
9
10 function addLoadEvent(func) {
11 var oldonload = window.onload;
12 if (typeof window.onload != 'function') {
13 window.onload = func;
14 } else {
15 window.onload = function() {
16 if (oldonload) {
17 oldonload();
18 }
19 func();
20 }
21 }
22 }
23
24 addLoadEvent(func1);
25 addLoadEvent(func2);
26
27 addLoadEvent(function() {
28 document.body.style.backgroundColor = '#EFDF95';
29 })
After calling func1 and func2, a function is created that changes the background color of the Web page. Each of these is executed in the order shown. Try it yourself and see how it works!
Conclusion
Sometimes, figuring out which approach to use in coding takes a bit of trial and error. Other times it's advantageous to search the Web and see what others have done. The addLoadEvent function should work just fine in this situation. We use it over at the JavaScript Source for all of our scripts requiring the onload event handler.
Sunday, November 2, 2008
Sunday, October 26, 2008
SQL Server Database Coding Standards
Naming
Tables: Rules: Pascal notation; end with an ‘s’
Examples: Products, Customers
Group related table names1
Stored Procs: Rules: sp<App Name>_[<Group Name >_]<Action><table/logical instance>
Examples: spOrders_GetNewOrders, spProducts_UpdateProduct
Triggers: Rules: TR_<TableName>_<action>
Examples: TR_Orders_UpdateProducts
Notes: The use of triggers is discouraged
Indexes: Rules: IX_<TableName>_<columns separated by _>
Examples: IX_Products_ProductID
Primary Keys: Rules: PK_<TableName>
Examples: PK_Products
Foreign Keys: Rules: FK_<TableName1>_<TableName2>
Example: FK_Products_Orderss
Defaults: Rules: DF_<TableName>_<ColumnName>
Example: DF_Products_Quantity
Columns: If a column references another table’s column, name it <table name>ID
Example: The Customers table has an ID column
The Orders table should have a CustomerID column
General Rules: Do not use spaces in the name of database objects
Do not use SQL keywords as the name of database objects
In cases where this is necessary, surround the
object name with brackets, such as [Year]
Do not prefix stored procedures with ‘sp_’2
Prefix table names with the owner name3
Structure
• Each table must have a primary key
o In most cases it should be an IDENTITY column named ID
• Normalize data to third normal form
o Do not compromise on performance to reach third normal form. Sometimes, a little de-
normalization results in better performance.
• Do not use TEXT as a data type; use the maximum allowed characters of VARCHAR instead
• In VARCHAR data columns, do not default to NULL; use an empty string instead
• Columns with default values should not allow NULLs
• As much as possible, create stored procedures on the same database as the main tables they
will be accessing
Formatting
• Use upper case for all SQL keywords
o SELECT, INSERT, UPDATE, WHERE, AND, OR, LIKE, etc.
• Indent code to improve readability
• Comment code blocks that are not easily understandable
o Use single-line comment markers(--)
o Reserve multi-line comments (/*.. ..*/) for blocking out sections of code
• Use single quote characters to delimit strings.
o Nest single quotes to express a single quote or apostrophe within a string
For example, SET @sExample = 'SQL''s Authority'
• Use parentheses to increase readability
o WHERE (color=’red’ AND (size = 1 OR size = 2))
• Use BEGIN..END blocks only when multiple statements are present within a conditional code
segment.
• Use one blank line to separate code sections.
• Use spaces so that expressions read like sentences.
o fillfactor = 25, not fillfactor=25
• Format JOIN operations using indents
o Also, use ANSI Joins instead of old style joins4
• Place SET statements before any executing code in the procedure.
Coding
• Optimize queries using the tools provided by SQL Server5
• Do not use SELECT *
• Return multiple result sets from one stored procedure to avoid trips from the application server
to SQL server
• Avoid unnecessary use of temporary tables
o Use 'Derived tables' or CTE (Common Table Expressions) wherever possible, as they
perform better6
• Avoid using <> as a comparison operator
o Use ID IN(1,3,4,5) instead of ID <> 2
• Use SET NOCOUNT ON at the beginning of stored procedures7
• Do not use cursors or application loops to do inserts8
o Instead, use INSERT INTO
• Fully qualify tables and column names in JOINs
• Fully qualify all stored procedure and table references in stored procedures.
• Do not define default values for parameters.
o If a default is needed, the front end will supply the value.
• Do not use the RECOMPILE option for stored procedures.
• Place all DECLARE statements before any other code in the procedure.
• Do not use column numbers in the ORDER BY clause.
• Do not use GOTO.
• Check the global variable @@ERROR immediately after executing a data manipulation statement
(like INSERT/UPDATE/DELETE), so that you can rollback the transaction if an error occurs
o Or use TRY/CATCH
• Do basic validations in the front-end itself during data entry
• Off-load tasks, like string manipulations, concatenations, row numbering, case conversions, type
conversions etc., to the front-end applications if these operations are going to consume more
CPU cycles on the database server
• Always use a column list in your INSERT statements.
o This helps avoid problems when the table structure changes (like adding or dropping a
column).
• Minimize the use of NULLs, as they often confuse front-end applications, unless the applications
are coded intelligently to eliminate NULLs or convert the NULLs into some other form.
o Any expression that deals with NULL results in a NULL output.
o The ISNULL and COALESCE functions are helpful in dealing with NULL values.
• Do not use the identitycol or rowguidcol.
• Avoid the use of cross joins, if possible.
• When executing an UPDATE or DELETE statement, use the primary key in the WHERE condition,
if possible. This reduces error possibilities.
• Avoid using TEXT or NTEXT datatypes for storing large textual data.9
o Use the maximum allowed characters of VARCHAR instead
• Avoid dynamic SQL statements as much as possible.10
• Access tables in the same order in your stored procedures and triggers consistently.11
• Do not call functions repeatedly within your stored procedures, triggers, functions and batches.12
• Default constraints must be defined at the column level.
• Avoid wild-card characters at the beginning of a word while searching using the LIKE keyword,
as these results in an index scan, which defeats the purpose of an index.
• Define all constraints, other than defaults, at the table level.
• When a result set is not needed, use syntax that does not return a result set.13
• Avoid rules, database level defaults that must be bound or user-defined data types. While these
are legitimate database constructs, opt for constraints and column defaults to hold the database
consistent for development and conversion coding.
• Constraints that apply to more than one column must be defined at the table level.
• Use the CHAR data type for a column only when the column is non-nullable.14
• Do not use white space in identifiers.
• The RETURN statement is meant for returning the execution status only, but not data.
Reference:
1) Group related table names:
Products_USA
Products_India
Products_Mexico
2) The prefix sp_ is reserved for system stored procedures that ship with SQL Server. Whenever SQL
Server encounters a procedure name starting with sp_, it first tries to locate the procedure in the
master database, then it looks for any qualifiers (database, owner) provided, then it tries dbo as the
owner. Time spent locating the stored procedure can be saved by avoiding the "sp_" prefix.
3) This improves readability and avoids unnecessary confusion. Microsoft SQL Server Books Online
states that qualifying table names with owner names helps in execution plan reuse, further boosting
performance.
4)
False code:
SELECT *
FROM Table1, Table2
WHERE Table1.d = Table2.c
True code:
SELECT *
FROM Table1
INNER JOIN Table2 ON Table1.d = Table2.c
5) Use the graphical execution plan in Query Analyzer or SHOWPLAN_TEXT or SHOWPLAN_ALL
commands to analyze your queries. Make sure your queries do an "Index seek" instead of an "Index
scan" or a "Table scan." A table scan or an index scan is a highly undesirable and should be avoided
where possible.
6) Consider the following query to find the second highest offer price from the Items table:
SELECT MAX(Price)
FROM Products
WHERE ID IN
(
SELECT TOP 2 ID
FROM Products
ORDER BY Price Desc
)
The same query can be re-written using a derived table, as shown below, and it performs generally
twice as fast as the above query:
SELECT MAX(Price)
FROM
(
SELECT TOP 2 Price
FROM Products
ORDER BY Price DESC
)
7) This suppresses messages like '(1 row(s) affected)' after executing INSERT, UPDATE, DELETE and
SELECT statements. Performance is improved due to the reduction of network traffic.
8) Try to avoid server side cursors as much as possible. Always stick to a 'set-based approach' instead
of a 'procedural approach' for accessing and manipulating data. Cursors can often be avoided by using
SELECT statements instead. If a cursor is unavoidable, use a WHILE loop instead. For a WHILE loop to
replace a cursor, however, you need a column (primary key or unique key) to identify each row
uniquely.
9) You cannot directly write or update text data using the INSERT or UPDATE statements. Instead, you
have to use special statements like READTEXT, WRITETEXT and UPDATETEXT. So, if you don't have to
store more than 8KB of text, use the CHAR(8000) or VARCHAR(8000) datatype instead.
10) Dynamic SQL tends to be slower than static SQL, as SQL Server must generate an execution plan at
runtime. IF and CASE statements come in handy to avoid dynamic SQL.
11) This helps to avoid deadlocks. Other things to keep in mind to avoid deadlocks are:
• Keep transactions as short as possible.
• Touch the minimum amount of data possible during a transaction.
• Never wait for user input in the middle of a transaction.
• Do not use higher level locking hints or restrictive isolation levels unless they are absolutely
needed.
12) You might need the length of a string variable in many places of your procedure, but don't call the
LEN function whenever it's needed. Instead, call the LEN function once and store the result in a
variable for later use.
13) IF EXISTS (SELECT 1 FROM Products WHERE ID = 50)
Instead Of:
IF EXISTS (SELECT COUNT(ID) FROM Products WHERE ID = 50)
14) CHAR(100), when NULL, will consume 100 bytes, resulting in space wastage. Preferably, use
VARCHAR(100) in this situation. Variable-length columns have very little processing overhead
compared with fixed-length columns.
Tables: Rules: Pascal notation; end with an ‘s’
Examples: Products, Customers
Group related table names1
Stored Procs: Rules: sp<App Name>_[<Group Name >_]<Action><table/logical instance>
Examples: spOrders_GetNewOrders, spProducts_UpdateProduct
Triggers: Rules: TR_<TableName>_<action>
Examples: TR_Orders_UpdateProducts
Notes: The use of triggers is discouraged
Indexes: Rules: IX_<TableName>_<columns separated by _>
Examples: IX_Products_ProductID
Primary Keys: Rules: PK_<TableName>
Examples: PK_Products
Foreign Keys: Rules: FK_<TableName1>_<TableName2>
Example: FK_Products_Orderss
Defaults: Rules: DF_<TableName>_<ColumnName>
Example: DF_Products_Quantity
Columns: If a column references another table’s column, name it <table name>ID
Example: The Customers table has an ID column
The Orders table should have a CustomerID column
General Rules: Do not use spaces in the name of database objects
Do not use SQL keywords as the name of database objects
In cases where this is necessary, surround the
object name with brackets, such as [Year]
Do not prefix stored procedures with ‘sp_’2
Prefix table names with the owner name3
Structure
• Each table must have a primary key
o In most cases it should be an IDENTITY column named ID
• Normalize data to third normal form
o Do not compromise on performance to reach third normal form. Sometimes, a little de-
normalization results in better performance.
• Do not use TEXT as a data type; use the maximum allowed characters of VARCHAR instead
• In VARCHAR data columns, do not default to NULL; use an empty string instead
• Columns with default values should not allow NULLs
• As much as possible, create stored procedures on the same database as the main tables they
will be accessing
Formatting
• Use upper case for all SQL keywords
o SELECT, INSERT, UPDATE, WHERE, AND, OR, LIKE, etc.
• Indent code to improve readability
• Comment code blocks that are not easily understandable
o Use single-line comment markers(--)
o Reserve multi-line comments (/*.. ..*/) for blocking out sections of code
• Use single quote characters to delimit strings.
o Nest single quotes to express a single quote or apostrophe within a string
For example, SET @sExample = 'SQL''s Authority'
• Use parentheses to increase readability
o WHERE (color=’red’ AND (size = 1 OR size = 2))
• Use BEGIN..END blocks only when multiple statements are present within a conditional code
segment.
• Use one blank line to separate code sections.
• Use spaces so that expressions read like sentences.
o fillfactor = 25, not fillfactor=25
• Format JOIN operations using indents
o Also, use ANSI Joins instead of old style joins4
• Place SET statements before any executing code in the procedure.
Coding
• Optimize queries using the tools provided by SQL Server5
• Do not use SELECT *
• Return multiple result sets from one stored procedure to avoid trips from the application server
to SQL server
• Avoid unnecessary use of temporary tables
o Use 'Derived tables' or CTE (Common Table Expressions) wherever possible, as they
perform better6
• Avoid using <> as a comparison operator
o Use ID IN(1,3,4,5) instead of ID <> 2
• Use SET NOCOUNT ON at the beginning of stored procedures7
• Do not use cursors or application loops to do inserts8
o Instead, use INSERT INTO
• Fully qualify tables and column names in JOINs
• Fully qualify all stored procedure and table references in stored procedures.
• Do not define default values for parameters.
o If a default is needed, the front end will supply the value.
• Do not use the RECOMPILE option for stored procedures.
• Place all DECLARE statements before any other code in the procedure.
• Do not use column numbers in the ORDER BY clause.
• Do not use GOTO.
• Check the global variable @@ERROR immediately after executing a data manipulation statement
(like INSERT/UPDATE/DELETE), so that you can rollback the transaction if an error occurs
o Or use TRY/CATCH
• Do basic validations in the front-end itself during data entry
• Off-load tasks, like string manipulations, concatenations, row numbering, case conversions, type
conversions etc., to the front-end applications if these operations are going to consume more
CPU cycles on the database server
• Always use a column list in your INSERT statements.
o This helps avoid problems when the table structure changes (like adding or dropping a
column).
• Minimize the use of NULLs, as they often confuse front-end applications, unless the applications
are coded intelligently to eliminate NULLs or convert the NULLs into some other form.
o Any expression that deals with NULL results in a NULL output.
o The ISNULL and COALESCE functions are helpful in dealing with NULL values.
• Do not use the identitycol or rowguidcol.
• Avoid the use of cross joins, if possible.
• When executing an UPDATE or DELETE statement, use the primary key in the WHERE condition,
if possible. This reduces error possibilities.
• Avoid using TEXT or NTEXT datatypes for storing large textual data.9
o Use the maximum allowed characters of VARCHAR instead
• Avoid dynamic SQL statements as much as possible.10
• Access tables in the same order in your stored procedures and triggers consistently.11
• Do not call functions repeatedly within your stored procedures, triggers, functions and batches.12
• Default constraints must be defined at the column level.
• Avoid wild-card characters at the beginning of a word while searching using the LIKE keyword,
as these results in an index scan, which defeats the purpose of an index.
• Define all constraints, other than defaults, at the table level.
• When a result set is not needed, use syntax that does not return a result set.13
• Avoid rules, database level defaults that must be bound or user-defined data types. While these
are legitimate database constructs, opt for constraints and column defaults to hold the database
consistent for development and conversion coding.
• Constraints that apply to more than one column must be defined at the table level.
• Use the CHAR data type for a column only when the column is non-nullable.14
• Do not use white space in identifiers.
• The RETURN statement is meant for returning the execution status only, but not data.
Reference:
1) Group related table names:
Products_USA
Products_India
Products_Mexico
2) The prefix sp_ is reserved for system stored procedures that ship with SQL Server. Whenever SQL
Server encounters a procedure name starting with sp_, it first tries to locate the procedure in the
master database, then it looks for any qualifiers (database, owner) provided, then it tries dbo as the
owner. Time spent locating the stored procedure can be saved by avoiding the "sp_" prefix.
3) This improves readability and avoids unnecessary confusion. Microsoft SQL Server Books Online
states that qualifying table names with owner names helps in execution plan reuse, further boosting
performance.
4)
False code:
SELECT *
FROM Table1, Table2
WHERE Table1.d = Table2.c
True code:
SELECT *
FROM Table1
INNER JOIN Table2 ON Table1.d = Table2.c
5) Use the graphical execution plan in Query Analyzer or SHOWPLAN_TEXT or SHOWPLAN_ALL
commands to analyze your queries. Make sure your queries do an "Index seek" instead of an "Index
scan" or a "Table scan." A table scan or an index scan is a highly undesirable and should be avoided
where possible.
6) Consider the following query to find the second highest offer price from the Items table:
SELECT MAX(Price)
FROM Products
WHERE ID IN
(
SELECT TOP 2 ID
FROM Products
ORDER BY Price Desc
)
The same query can be re-written using a derived table, as shown below, and it performs generally
twice as fast as the above query:
SELECT MAX(Price)
FROM
(
SELECT TOP 2 Price
FROM Products
ORDER BY Price DESC
)
7) This suppresses messages like '(1 row(s) affected)' after executing INSERT, UPDATE, DELETE and
SELECT statements. Performance is improved due to the reduction of network traffic.
8) Try to avoid server side cursors as much as possible. Always stick to a 'set-based approach' instead
of a 'procedural approach' for accessing and manipulating data. Cursors can often be avoided by using
SELECT statements instead. If a cursor is unavoidable, use a WHILE loop instead. For a WHILE loop to
replace a cursor, however, you need a column (primary key or unique key) to identify each row
uniquely.
9) You cannot directly write or update text data using the INSERT or UPDATE statements. Instead, you
have to use special statements like READTEXT, WRITETEXT and UPDATETEXT. So, if you don't have to
store more than 8KB of text, use the CHAR(8000) or VARCHAR(8000) datatype instead.
10) Dynamic SQL tends to be slower than static SQL, as SQL Server must generate an execution plan at
runtime. IF and CASE statements come in handy to avoid dynamic SQL.
11) This helps to avoid deadlocks. Other things to keep in mind to avoid deadlocks are:
• Keep transactions as short as possible.
• Touch the minimum amount of data possible during a transaction.
• Never wait for user input in the middle of a transaction.
• Do not use higher level locking hints or restrictive isolation levels unless they are absolutely
needed.
12) You might need the length of a string variable in many places of your procedure, but don't call the
LEN function whenever it's needed. Instead, call the LEN function once and store the result in a
variable for later use.
13) IF EXISTS (SELECT 1 FROM Products WHERE ID = 50)
Instead Of:
IF EXISTS (SELECT COUNT(ID) FROM Products WHERE ID = 50)
14) CHAR(100), when NULL, will consume 100 bytes, resulting in space wastage. Preferably, use
VARCHAR(100) in this situation. Variable-length columns have very little processing overhead
compared with fixed-length columns.
Subscribe to:
Posts (Atom)