Frequently Used Regular Expressions

June 28, 2007

There are a variety of tasks that regular expressions can be used for in regards to input validation and file parsing. Some of the most common expressions are often hard to remember because of the power and options available. Here is a list of commonly used regular expressions:

Use Expression
Social Security Number \d{3}-\d{2}-\d{4}
US Phone Number ((\(\d{3}\) ?)|(\d{3}-))?\d{3}-\d{4}
US Postal Code \d{5}(-\d{4})?
Internet EMail Address [\w-]+@([\w-]+\.)+[\w-]+
Internet URL http://(%5B\w-]\.)+[\w-](/[\w- ./?%=]*)?
Simple Password (digit) ^(?=.*\d).{4,8}$
Advanced Password (upper, lower, digit) ^(?=.*\d)(?=.*[a-z])(?=.*[A-Z]).{4,8}$
Common File masks ^(.+)\\(.+)\.(.+)
Major Credit Card \d{4}-?\d{4}-?\d{4}-?\d{4}

Reference:
ASP alliance


Password Validation via Regular Expression

June 26, 2007

I have recently been working on Password validation via regular expression, after so many researches I came across very good quality articles so I recapitulate over here.

When it comes to password validation using regular expressions, things can get a bit complicated. Normally, you want people to enter a “good” password that has a mix of numbers and letters. But you may not care where the numbers and letters appear. So you’re not looking for a “pattern” in the string. You just want a letter somewhere and a number somewhere.

In this first example, the password must be at least 8 characters long and start and end with a letter.

^[A-Za-z]\w{6,}[A-Za-z]$

The ^ looks for something at the start of the string. The brackets indicate the valid character set. So it must start with an upper or lower case letter. After that, the \w means there can be valid alphanumeric characters (numbers 0-9, upper/lower case letters a-z, the underscore) and says there must be at least 6 (but no upper limit). Then comes another set and the $ looks for something at the end of the string. So this statement says there must be a letter, then at least 6 of any alphanumeric characters, then a letter (making 8 the minimum number of characters).

In this second example, the password length doesn’t matter, but the password must contain at least 1 number, at least 1 lower case letter, and at least 1 upper case letter.

^\w*(?=\w*\d)(?=\w*[a-z])(?=\w*[A-Z])\w*$

Again, the ^ and $ are looking for things at the start and end. The “\w*” combination is used at both the start and the end. \w means any alphanumeric character, and * means zero or more. You’ll see why it’s “zero or more” in a bit. Between are groupings in parentheses. The “(?” combination is a flag in regular expressions. Basically, they say “apply the following formula, but don’t consume any of the string”. In this example, instead of specifying the order that things should appear, it’s saying that it must appear but we’re not worried about the order.

The first grouping (called an “atom” in “regular expresion speak”) uses the = sign. This means that there must be a match. Other choices are ! for a negative match (the string must not look like this). There are others (more complicated) for preceeding matches and stuff. We can refer you to a regular expression syntax web site for further details.

After the = sign comes “\w*\d”. Again, any alphanumeric character can happen zero or more times, then any digit (\d means any digit from 0 to 9) can happen. So this checks to see if there is at least one number in the string. But since the string isn’t comsumed, that one digit can appear anywhere in the string.

The next atom (grouping) is (?=\w*[a-z]). This is similar to the digit grouping, except it looks for a lower case letter. Again, the lower case letter can appear anywhere, but there has to be at least one.

The third atom is (?=\w*[A-Z]) which looks for an upper case letter somewhere in the string.

At the end is zero or more alphanumeric characters. To match this string, the minimum characters needed is 3 (one upper case letter, one lower case letter, and one number).

In this third example:

  • Must be at least 10 characters
  • Must contain at least one one lower case letter, one upper case letter, one digit and one special character
  • Valid special characters are –   @#$%^&+=

^.*(?=.{10,})(?=.*\d)(?=.*[a-z])(?=.*[A-Z])(?=.*[@#$%^&+=]).*$

As you can see in the regex, the list of special characters is configurable.

Reference:
Breaking Par Consulting
Anil John’s Blog


VS 2008 JavaScript Intellisense

June 22, 2007

One of the features that web developers will really like with VS 2008 is its built-in support for JavaScript intellisense.  This is enabled in both the free Visual Web Developer 2008 Express edition as well as in Visual Studio, and makes using JavaScript and building AJAX applications significantly easier. 

Below link is a quick tour of some of the new JavaScript intellisense features to take advantage of:
Scott Gu’s Blog


ViewState improvements in ASP.NET 2.0

June 18, 2007

When I browsing through Internet I came across very good article : View State improvement made in .NET 2.0.

In this article is not going to expol the benefits of view state. this article will explain you whats improved for ViewState in .NET 2.0.

Couple of things to keep in mind: Turn off view state when its not needed and secondly ask yourself if its cheaper to requery the database or cache the queried data and data-bind on each request instead of using view state (data controls by their very nature generate significant view state).

Control State

One of the most frustrating aspects of working with server-side controls in ASP.NET 1.x is the all-or-nothing mentality with respect to view state. Behavioral aspects of controls like pagination in the DataGrid or selection change notifications in textboxes require view state to be enabled to function properly. I’m sure all of you are sufficiently daunted by the prospect of leaving view state enabled in any of your DataGrids at this point. In ASP.NET 2.0, Microsoft addresses this particular problem by partitioning the view state into two separate and distinct categories: view state and control state.

Control state is another type of hidden state reserved exclusively for controls to maintain their core behavioral functionality (SelectedIndex in a ListBox is an essential bit of information), whereas view state only contains state to maintain the control’s contents (UI). Technically, control state is stored in the same hidden field(__VIEWSTATE) as view state (being just another leaf node at the end of the view state hierarchy), but if you disable view state on a particular control, or on an entire page, the control state is still propagated. Control state allows a control to intelligently split their state into what is absolutely required and what is not. The nice aspect of this implementation is that we can now amend our original principle on optimizing view state for ASP.NET 2.0 to be much stronger: if you populate the contents of a control every time a page is requested, you should disable view state for that control.

As long as control builders properly partition their state into behavioral state (to maintain core functionality) and UI state (to retain contents), this statement should be followed religiously. I would like to tell you to start following this recommendation now with all work done in ASP.NET 2.0, but the DataGrid has not been refactored to keep its behavioral state in control state. Fortunately, the new GridView is the logical successor to the DataGrid and it uses control state properly, as do the new versions of the TextBox and DropDownList controls. following figure shows a list of the controls that currently make use of control state and what properties they store there for your reference.

 

Serialization

The next thing I wanted to point out are the serialization improvements in v2.0. View state (and control state) serialization now uses a new mechanism implemented in ObjectStateFormatter instead of using LosFormatter. the new serializer serializes the same object graph into roughly half the size, and spends about half as much time in the serialization and deserialization process.

No more text: LosFormatter wrote to a TextWriter; ObjectStateFormatter writes to a BinaryWriter. This by itself doesn’t do much, other than it enables a some other improvements.

Token-based approach: LosFormatter wrote out strings to represent data types and embedded the data within <, > brackets. None of that anymore. ObjectStateFormatter capitalizes on the underlying binary model, and writes out a byte representing the following data, and then the data.

No more strings: The old formatter converted everything to strings (numbers, booleans etc.) to write into the TextWriter. The new one writes out bytes. This saves the cost of converting to and from a string.

More compact storage: Integers are stored as 7-bit encoded numbers. So most of them (values 0 – 255) just take a single byte instead of 4. In the case of booleans, there are simply two boolean-type tokens: a true one and a false one, so there is no additional cost to storing boolean data. DateTime is also special cased. Just the TickCount is saved, which by the way isn’t lossy as the string version is.

Indexing of strings: Lets say you had a DataGrid with a 100 cells. You’d have the word “Text” in view state a 100 times! This came from the Text property of TableCell. The StateBag type (that is used for ViewState) now saves property names using IndexedString. The ObjectStateFormatter special cases this type (like Pair and Triplet) to build a running table of strings. Each time a string is reused, it simply saves out a token referring to an IndexedString, and the index within this running table.

If we place a DataGrid on a form and bind it to the authors table in the pubs database, the size of the view state string in 1.x is 12,648 characters. If we do the same in 2.0, the size of view state is reduced to 6,728 characters, a reduction of nearly half. Following Figure shows the contrast in space required by view state in ASP.NET 1.x, ASP.NET 2.0, and the number of characters actually rendered to the page for a variety of input sizes.

View State Size Comparison

Without doing anything special, you can look forward to an immediate reduction in the size of your view state with the release of ASP.NET 2.0. This does not mean that you should stop thinking about whether your controls need view state to function properly or not, since it can still contribute significantly to the size of the response, as evidenced in Figure. 

References:

MSDN

Nikhil Kothari’s Weblog


UML : A Hands-On Introduction for Developers

June 14, 2007

I came across very good article for UML. This tutorial provides a quick introduction to the Unified Modeling Language.
UML : A Hands-On Introduction for Developers


CmsHttpContext Vs CmsApplicationContext

June 6, 2007

when I surfing on net I found very good article on MCMS API. I found its very useful.

Compared On CmsHttpContext CmsApplicationContext
Instance Only one instance can be created using Current property. When we call CmsHttpContext.Current, the request is send to the server and it will check the HttpContext for an existing CmsHttpContext. If it finds one, then it will returns that. Otherwise it will create a new instance of it with the current identity, save that in the HttpContext and returns the new one. Any number of instances can be created with the constructor. All the instances will be created with an authentication and mode.
Authentication It will take the correct authentication from the current HttpContext. The identity will be created accordingly (Windows Identity or Passport Identity or Forms Identity) and the correct token will be taken for the creation of a new context. There are four kind of Authentication available with four different type of overloads. The appropriate one can be used. For more info on this, check the PAPI help.
Where it can be used This one can be only used in application’s which comes under HttpContext (web applications and web services). This can be used in windows applications, web applications, console applications, web services, etc.
Mode An instance is created by the server with the mode, which depends on the request we send. It can’t be changed. Must switch the request to change the mode (it will create an instance with that mode). An instance can be created with any mode which is required. It can’t be changed, a new instance must be created with a different mode.
Duration Because this is used in web based, duration of the instance is small. It is possible to have long running sessions (duration of time from when an object is modified to when CommitAll() is called) using this. But it is not a good practice to have long sessions. Because long running sessions can block accessing a site.
Dispose() It is not necessary to dispose the instance always, it will automatically handled by the server – CmsEndRequestModule will call this, if there is a valid instance exist in HttpContext after the response is send to client. After the use of CmsApplicationContext instance it must be disposed. Otherwise it may give problems. For more
information check Creating scalable applications using the CmsApplicationContext.
RollBackAll() After calling RollBackAll(), the instance is invalid, but after the call to this method, if we don’t use the instance, no need to call Dispose(), server will handle that. If we use after calling this, then its a must to call Dispose() and get a new instance. After calling RollBackAll(), the instance is invalid and it must be disposed and a new instance must be created for future use.

There are few properties and a method which are only available in CmsHttpContext(driven from CmsAspContext). They are not available in CmsApplicaitonContext. They are Channel, ChannelItem, CmsQueryString, IsUsingTemplate, Posting, UserCacheKey, ChannelItemIsVisible and ResolveUrl (). For more information, check the PAPI documentation.

Reference Taken From :

http://chestermr.blogspot.com/2005/05/cmshttpconte…

as such you will find lot of good articles in chester’s blog.


How Content Management Server works?

June 1, 2007

Introduction

On a traditional Microsoft ASP.NET–based Web site, when a request for a Web page comes in to the Microsoft Internet Information Services (IIS) Web server, the Microsoft ASP.NET Internet Server API (ISAPI) extension catches incoming requests for ASP.NET–based files (based on file extension). The ISAPI extension then forwards these requests to the ASP.NET worker process.

Traditional ASP.NET-based page processing

1. The browser requests a Web page from IIS.
2. The ASP.NET ISAPI extension determines that the request is for an ASP.NET–based file.
3. The extension passes the request to the ASP.NET worker process.
4. The worker process assembles the page, and then returns it to IIS.
5. IIS returns the page to the browser.

For more information about page processing on traditional ASP.NET–based sites, see The ASP.NET HTTP Runtime.

What happens when IIS receives a request for a Web page on an MCMS Web site? MCMS works with IIS, an MCMS ISAPI filter (called ReAuthFilt.dll), and the ASP.NET worker process to handle incoming page requests.

The following diagram shows the nine basic steps.

MCMS ASP.NET–based page processing

1. The browser requests a Web page from IIS.
2. The MCMS ISAPI filter determines that the request is an MCMS page (posting) or resource.
3. The filter rewrites the request with help from the MCMS Content Server.
4. The filter passes the updated request back to IIS.
5. The ASP.NET ISAPI extension determines that the request is for an ASP.NET–based file.
6. The extension passes the request to the ASP.NET worker process.
7. The worker process communicates with the MCMS Content Server to assemble all the information for the page.
8. The ASP.NET worker process returns the assembled page to IIS.
9. IIS returns the page to the browser.

You can see that most of the steps are the same as those for traditional ASP.NET–based pages, but with two big differences:

· The MCMS ISAPI filter catches MCMS requests and rewrites them with help from the MCMS Content Server.
· The page is assembled differently: the ASP.NET worker process communicates with the MCMS Content Server.

The MCMS ISAPI Filter

When a page or resource request arrives through IIS, the MCMS ISAPI filter (ReAuthFilt.dll) traps it. An ISAPI filter always runs on an IIS server, filtering every request until it finds one it needs to process. For more information about ISAPI filters, see ISAPI Filter Overview.

MCMS Pages

For an MCMS page, the filter takes the URL apart to find the relevant Posting. MCMS “friendly” URLs are constructed as follows: http:/servername/channel/channel/posting.

Note   MCMS friendly URLS do not have extensions, for example posting, posting.aspx and posting.abc all work.

After the filter has determined the Posting, it determines the Template and the template file (Template.SourceFile), and then it constructs a new URL using the ASPX template file. The new URL contains several query string parameters, including the GUID of the posting, which is used to find the placeholders for the posting. Then the filter passes the transformed URL back to IIS.

MCMS Resources

The filter categorizes an MCMS resource as one of the following:

· A resource from an MCMS resource gallery.
· A “local resource” that is not stored in a resource gallery.
MCMS handles local resources the way a traditional ASP.NET–based Web site handles them.

To handle a request for a resource from an MCMS resource gallery, MCMS uses a disk cache rather than retrieving a resource from the Content Repository database. MCMS removes the resources from the cache when they are updated or deleted from the Content Repository.

The following steps shows how resources from an MCMS resource gallery are served when they are already in the disk cache.

MCMS processing resources already in the disk cache

1. The browser requests an MCMS resource, such as a graphic, from IIS.
2. The MCMS ISAPI filter determines that the request is an MCMS resource.
3. The filter checks with the MCMS Content Server that the user has rights to the resource.
4. The filter retrieves the URL of the resource in the disk cache.
5. The filter returns the resource URL to IIS.
6. IIS returns the resource to the browser.

If the resource is not in the disk cache, MCMS first places a copy of the resource from the MCMS Content Repository in the cache, and then returns it to the browser.

The following steps shows how resources from an MCMS resource gallery are served when they are not already in the disk cache.

MCMS processing resources not yet in the disk cache

1. The browser requests an MCMS resource, such as a graphic, from IIS.
2. The MCMS ISAPI filter determines that the request is an MCMS resource.
3. The filter checks with the Content Server that the user has rights to the resource.
4. The Content Server makes a copy of the resource from the Content Repository.
5. The filter places the copied resource in the disk cache.
6. The filter retrieves the URL of the resource in the disk cache.
7. The filter returns the resource URL to IIS.
8. IIS returns the resource to the browser.

Assembling MCMS Pages

An MCMS page is built of several pieces, which are all assembled just at the time when a browser makes the request for the page.

Note   You can implement ASP.NET output caching on your Web site; however, that is not discussed in this article. For more information, see Enabling ASP.NET Output Caching.

Because the content in MCMS pages is edited from the browser, MCMS pages are assembled during authoring time as well as presentation time.

MCMS pages are based on template files, which contain placeholder controls and resources. When the ASP.NET worker process executes a template file, placeholder controls on the template file create instances of their placeholders and placeholder definitions. The placeholders retrieve content from the Content Repository or from the page request when a Web Author user previews a page containing new content. The worker process requests resources through a separate process, discussed in MCMS Resources.

The following diagram shows how an MCMS page is assembled.

Conclusion

MCMS works in a way that is similar, but not exactly the same, as a traditional ASP.NET-based Web site. Incoming requests are handled by IIS and the ASP.NET worker process, but MCMS and the MCMS ISAPI filter are also involved.

After an MCMS page is requested, it is assembled from information on the file system and in the Content Repository. This enables newly edited MCMS pages to always display up-to-date content.