URL:
http://samples.gotdotnet.com/quickstart/aspplus/doc/portalapp.aspx
and a good asp resource site:
www.asp.net
Wednesday, December 29, 2004
Thursday, December 23, 2004
[ASP.NET] A tutorial about How to connect to access database using oledbconnection
Basic Database operations using ADO.NET - CRUD (Create, Read, Update, Delete)
This chapter demonstrates the basic database operations using the ADO.NET classes. The sample code in this chapter uses the OleDb Provider.
http://www.dotnetspider.com/technology/tutorials/CRUDSample.aspx
This chapter demonstrates the basic database operations using the ADO.NET classes. The sample code in this chapter uses the OleDb Provider.
http://www.dotnetspider.com/technology/tutorials/CRUDSample.aspx
Wednesday, December 22, 2004
[ASP.NET] a general introduction to the page layout design
Creating Usable Page Templates in ASP.NET
Overcome ASP.NET's lack of page templating using this robust and upgradeable templating approach.
by Joe Agster December 15, 2003
http://www.devx.com/dotnet/Article/18011
Overcome ASP.NET's lack of page templating using this robust and upgradeable templating approach.
by Joe Agster December 15, 2003
http://www.devx.com/dotnet/Article/18011
Friday, December 17, 2004
[.net] use keyword "as" to cast object in C#
here is the piece of code:
...
protected Login login1;
private void Page_Load(object sender, System.EventArgs e)
{
// Put user code to initialize the page here
// add login module dynamicly
//control1 = LoadControl("Modules\\Login\\Login.ascx");
Control ctr = LoadControl("Login.ascx");
login1 = ctr as Login;
...
...
protected Login login1;
private void Page_Load(object sender, System.EventArgs e)
{
// Put user code to initialize the page here
// add login module dynamicly
//control1 = LoadControl("Modules\\Login\\Login.ascx");
Control ctr = LoadControl("Login.ascx");
login1 = ctr as Login;
...
[.net] Open Issue: session state and name space
I found that the session state was missing between two user controls in different folders.
Still need to test.
Still need to test.
Thursday, December 16, 2004
[asp.net] great tutorial of Raising Event from User Control
Easily Raise Events From ASP.NET ASCX User Controls
http://dotnetjunkies.com/WebLog/bsblog/archive/2004/10/06/27795.aspx
http://dotnetjunkies.com/WebLog/bsblog/archive/2004/10/06/27795.aspx
Tuesday, December 14, 2004
Frame based lay out can be instead by using "user control"
Create user controls as different components and place them on the form in default.aspx. These user controls can be orginized by using table.
Two tutorials:
http://www.asp101.com/lessons/usercontrols.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconcreatingpageletcontrol.asp
Two tutorials:
http://www.asp101.com/lessons/usercontrols.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconcreatingpageletcontrol.asp
Monday, December 13, 2004
compare package in Java and C#
From
http://www.ondotnet.com/pub/a/dotnet/2001/06/07/csharp_java.html?page=3
Conceptually, Java packages are the same as .NET namespaces. However, implementations are different. In Java, package names are also a physical thing that determines the directory structure where your .java files must reside. In C#, there is a complete separation between physical packaging and logical naming, so the name for your namespace has nothing to do with the physical packaging. In C#, each source file can contribute to multiple namespaces and can take multiple public classes.
The physical packaging in .NET is called assembly. Each assembly contains a manifest that enumerates the files that are contained in the assembly, controls what types and resources are exposed outside the assembly, and maps references from those types and resources to the files that contain the types and resources. Assemblies are self-contained and an assembly can be contained in a single file or be split among a number of files. This packaging mechanism solves the problem with DLL files, notoriously known as DLL Hell.
http://www.ondotnet.com/pub/a/dotnet/2001/06/07/csharp_java.html?page=3
Conceptually, Java packages are the same as .NET namespaces. However, implementations are different. In Java, package names are also a physical thing that determines the directory structure where your .java files must reside. In C#, there is a complete separation between physical packaging and logical naming, so the name for your namespace has nothing to do with the physical packaging. In C#, each source file can contribute to multiple namespaces and can take multiple public classes.
The physical packaging in .NET is called assembly. Each assembly contains a manifest that enumerates the files that are contained in the assembly, controls what types and resources are exposed outside the assembly, and maps references from those types and resources to the files that contain the types and resources. Assemblies are self-contained and an assembly can be contained in a single file or be split among a number of files. This packaging mechanism solves the problem with DLL files, notoriously known as DLL Hell.
Friday, December 10, 2004
Checkpoints: Use Case
(Copy from RUP. IBM)
Is each concrete use case involved with at least one actor? If not, something is wrong; a use case that does not interact with an actor is superfluous, and you should remove it. For more information, see Guidelines: Use Case.
Is each use case independent of the others? If two use cases are always activated in the same sequence, you should probably merge them into one use case.
For an included use case: does it make assumptions about the use cases that include it? Such assumptions should be avoided, so that the included use case is not affected by changes to the including use cases.
Do any use cases have very similar behaviors or flows of events? If so - and if you wish their behavior to be similar in the future - you should merge them into a single use case. This makes it easier to introduce future changes. Note: you must involve the users if you decide to merge use cases, because the users, who interact with the new, merged use case will probably be affected.
Has part of the flow of events already been modeled as another use case? If so, you can have the new use case use the old one.
Is some part of the flow of events already part of another use case? If so, you should extract this subflow and have it be used by the use cases in question. Note: you must involve the users if you decide to "reuse" the subflow, because the users of the existing use case will probably be affected.
Should the flow of events of one use case be inserted into the flow of events of another? If so, you model this with an extend-relationship to the other use case.
Do the use cases have unique, intuitive, and explanatory names so that they cannot be mixed up at a later stage? If not, you change their names.
Do customers and users alike understand the names and descriptions of the use cases? Each use-case name must describe the behavior the use case supports.
Does the use case meet all the requirements that obviously govern its performance? You must include any (nonfunctional) requirements to be handled in the object models in the use-case Special Requirements.
Does the communication sequence between actor and use case conform to the user's expectations?
Is it clear how and when the use case's flow of events starts and ends?
Behavior might exist that is activated only when a certain condition is not met. Is there a description of what will happen if a given condition is not met?
Are any use cases overly complex? If you want your use-case model to be easy to understand, you might have to split up complex use cases.
Does a use case contain disparate flows of events? If so, it is best to divide it into two or more separate use cases. A use case that contains disparate flows of events will be very difficult to understand and to maintain.
Is the subflow in a use case modeled accurately?
Is it clear who wishes to perform a use case? Is the purpose of the use case also clear?
Are the actor interactions and exchanged information clear?
Does the brief description give a true picture of the use case?
Is each concrete use case involved with at least one actor? If not, something is wrong; a use case that does not interact with an actor is superfluous, and you should remove it. For more information, see Guidelines: Use Case.
Is each use case independent of the others? If two use cases are always activated in the same sequence, you should probably merge them into one use case.
For an included use case: does it make assumptions about the use cases that include it? Such assumptions should be avoided, so that the included use case is not affected by changes to the including use cases.
Do any use cases have very similar behaviors or flows of events? If so - and if you wish their behavior to be similar in the future - you should merge them into a single use case. This makes it easier to introduce future changes. Note: you must involve the users if you decide to merge use cases, because the users, who interact with the new, merged use case will probably be affected.
Has part of the flow of events already been modeled as another use case? If so, you can have the new use case use the old one.
Is some part of the flow of events already part of another use case? If so, you should extract this subflow and have it be used by the use cases in question. Note: you must involve the users if you decide to "reuse" the subflow, because the users of the existing use case will probably be affected.
Should the flow of events of one use case be inserted into the flow of events of another? If so, you model this with an extend-relationship to the other use case.
Do the use cases have unique, intuitive, and explanatory names so that they cannot be mixed up at a later stage? If not, you change their names.
Do customers and users alike understand the names and descriptions of the use cases? Each use-case name must describe the behavior the use case supports.
Does the use case meet all the requirements that obviously govern its performance? You must include any (nonfunctional) requirements to be handled in the object models in the use-case Special Requirements.
Does the communication sequence between actor and use case conform to the user's expectations?
Is it clear how and when the use case's flow of events starts and ends?
Behavior might exist that is activated only when a certain condition is not met. Is there a description of what will happen if a given condition is not met?
Are any use cases overly complex? If you want your use-case model to be easy to understand, you might have to split up complex use cases.
Does a use case contain disparate flows of events? If so, it is best to divide it into two or more separate use cases. A use case that contains disparate flows of events will be very difficult to understand and to maintain.
Is the subflow in a use case modeled accurately?
Is it clear who wishes to perform a use case? Is the purpose of the use case also clear?
Are the actor interactions and exchanged information clear?
Does the brief description give a true picture of the use case?
Tuesday, December 07, 2004
[.NET]Building and Hosting PDS Web Applications for Project Server 2003
a tutorial using PDS API.
http://msdn.microsoft.com/office/understanding/project/codesamples/default.aspx?pull=/library/en-us/odc_pj2003_ta/html/odc_pjhostingpdswebapplications.asp
http://msdn.microsoft.com/office/understanding/project/codesamples/default.aspx?pull=/library/en-us/odc_pj2003_ta/html/odc_pjhostingpdswebapplications.asp
Monday, December 06, 2004
web form authentication how to from MSDN
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secmod/html/secmod17.asp
Friday, December 03, 2004
[J2EE]an article show a sample application using JSF
Title: Creating a pet store application
by: Derek Yang Shen
From: JDJ, issue 11, 2004
JSF, Java Server Faces, is a server-side, user interface component framework for j2EE applications.
by: Derek Yang Shen
From: JDJ, issue 11, 2004
JSF, Java Server Faces, is a server-side, user interface component framework for j2EE applications.
Thursday, December 02, 2004
Wednesday, December 01, 2004
.net: treeview web control and frame
Use the Target and Navigateurl properties to implement treeview menu.
Four Enhancement Web Control for .NET 2003
In 2002 Microsoft® released four ASP.NET Web controls designed to provide enhanced experiences for Web visitors using Microsoft Internet Explorer. These Web controls, dubbed the Internet Explorer Web Controls, or IE Web Controls for short, consist of the following four controls:
* The MultiPage Web control
* The TabStrip Web control
* The Toolbar Web control
* The TreeView Web control
* The MultiPage Web control
* The TabStrip Web control
* The Toolbar Web control
* The TreeView Web control
Subscribe to:
Posts (Atom)