I know that I am a big fan of Microsoft products and technologhy, but I read today the Safari (from Apple) is ready to download.

Despite this version is still a beta, you can download it to your PC and start playing with it.

I downloaded it just to get the feel impression of it and also to has an idea how my web applications are being showed there... (good for cross browsers suitabilities). And it's nice...

Download is here.

These days I am working on a very big web application...

In one of my aspx pages I had needed to save lots of data in the ViewState object in order to persist data between postbacks, but when I looked at the rendered HTML, I saw a large hidden field for carring the ViewState.

ASP.NET 2.0 came up with a new feature that helps to reduce the amount of the hidden filed's ViewState data that called: PageStatePersister.

When we add an override the PageStatePersister property and use the built-in SessionPageStatePersister, the behavior of the page remains the same, but the storage used for the bulk of the state data is shifted from the hidden field to session state.

Implamantation instance:

protected override PageStatePersister PageStatePersister
{
   get { return new SessionPageStatePersister(this); }
}

In several cases you'll only want to override this property in your page and to shift the ViewState data into the Sesson object, but if you'll want to use it (wisely of course) on your entire web application? You should implement this property in a particular custom base page and to inherit it to all of your application pages.

The only disadventage that I could think about here is the data existent, session can lose its data and information if its timeout has ended, but ViewState can hold the data forever on the page, because it's hard coded.

I had installed the AJAX extesions framework on my computer in order to assimilate it in my web application that I am working on right now. I added some AJAX controls such as <asp:ClientScript>, <asp:UpdatePanel> and more, and damn... I find that the markup intellisense no longer works for these controls, or for any controls nested within them.

This happens because my ClientScript control is defined in the master page, and when I tried to drag (create) some other AJAX control in the other aspx pages that inherits the master page, the intellisense was lost.

I found a great solution/trick in ScottGu's Blog, that says that in order to see that intellisense in the rest of aspx pages, we need to leave the master page designer open (isn't it little bit ackward?)

For some more information and tricks (in ScottGu's Blog) you can click here.

Hey, I just can't wait this movie will be coming on screens already, so I have decided to remind you that in 4th of July will be the premier.

Is this logo reminds you somthing...?

So, here is a link to to countdown to Transformers movie with trailers, photos and more (from Yahoo! site)...

See you at the theaters...

I am working now on a large web application, that need to be used by more than one websites (at least 5 of them, websites and web services), therefore I have needed to do some isolating here with my main core projects.

Some background...
I have a common assembly (web application) that holds only the user controls, server controls and custom controls, which need to serve the all other web applications that are using them. This assembly has a reference to the other web application in order to have some information about some properties, session variables and global members, by this information, it knows to gereate some actions on runtime (or even in design). BUT, in the other hand, this web application need to use the controls that the first assembly has published, here we have a problem, we got a circular references, which is now allowed in .NET framework, also it isn't allowed anywhere I think...

So, how we gonna solve this problem?

The solution is quite simple and is known as Seperate Interface Pattern. (Click here to get some more info).

The main steps to implement it are:
Let define a project that called ProjectA and holds the user controls (etc...) implementations along with InterfaceB. ProjectA would maintain a reference to InterfaceB, which will hold any properties such as members, methods, events etc...

Now, lets define ProjectB which will implement InterfaceA. Now, ProjectB would reference ProjectA and (BUT) ProjectA would not reference ProjectB of course.

The result, ProjectA can access to ProjectB's specific exposed members and ProjectB can use the controls of ProjectA.

I read a nice post at Web Worked Daily that holds the same title my post holds...

This post (click here to read it) talks about some very common mistakes that a web worker could do, I aggree that the post is focusing on freelancer web workers, but there are some very usefull topics that can contribute you something even if you are a salaried employee and you want to create yourself at the 'end of the day' a successful online career.

The post speaks also to team leaders that need to plan the project schedule, set missions to her team members (the actual developers), stick on deadlines and to deliver (at last) a fine working project to the development end point. In addition, this post also relates to project managers by that it shows some examples how to manage the specific project properly, how to devide missions in the right way and more...

AND, in the bottom line, it displays its 5 common mistakes...
Enjoy

After doing great usage with CAPTCHA in my site (when adding comments - if you didn't try it I am inviting you to give it a try and add some comments after reading this post...), I decided to give some words about it...

Some definitions...
a CAPTCHA is a type of challenge-response test used in computing to determine whether the user is human, aka "Completely Automated Public Turing test to tell Computers and Humans Apart". A CAPTCHA involves one computer (a server) which asks a user to complete a test. While the computer is able to generate and grade the test, it is not able to solve the test on its own. Because computers are unable to solve the CAPTCHA, any user entering a correct solution is presumed to be human.

There are several approaches to this CAPTCHA mechanism, that comes to supply the same idea of effect (to differ a human user from a computer user of course), like:
- Carnegie Mellon's PIX CAPTCHA, which the user here sees few images and need to differ which one is exceptional.
- Oli Warner's KittenAuth, the user here needs to select all animals of specific speices in the proposed images.
- Microsoft's Asirra, quite similar to KittenAuth, but works under larger amount of images.

Some issues that are important in order of using CAPTCHA in your web site:

• You must dock the CAPTCHA image/s in a non dominant place in your web site - think about it, the CAPTCHA mechanism is comes to help you to avoid bots, not to take a central place in your site.
• The CAPTCHA image/s supposed to has as much as small weight (something like between 4 to 8 kb), the site should not be affected from the CAPTCHA image/s creation. I'd rather creating the CAPTCHA image/s using HttpHandler that display the image/s from an outside mechanism.
• The area of the image/s should be appropriate to the site isuue. Images of cats should not be appropriate to a government site for example, therefore select the image/s properly.
• Store the CAPTCHA in a safe place and name them in appropriate names in order to use it properly.

OK, what about some implementation? There are a lot of ways to implements this algorithm, which is not so complex. You can find a lot of written open source small application that implements this CAPTCHA mechanism.

In the web application that I am working on at work, we saves all distorted images in a DB (and its images' values of course) and grabs it randomally on each request of the specific page that holds the CAPTCHA. The distorted image is shown to the user and its value is stored in the page viewstate (which is also encripted of course).
After that user enters her input, that value is being validated against the distorted image's value and if it's correct, moves on...

Do you have more suggestions of CAPTCHA implemetations?

Hi fellows, how are you?

I read a nice article regarding editing and encrypting/decrypting web.config sections. The nicest thing in that feature is the ability to access to the web.config content via the actual code behind (and) in run-time. (Could be a lot of reasons to access the file from the code itself, and the API is very 'friendly').

Click here to get the directive to this article.

Bye bye...

Hi again..

I am here again with the same issue, and this is because a long conversation that I had with Oren Ellenbogen (ex. co-worker) about some extending and refactoring of the former post solution (you can see it here if you missed it).

The main goal in the Session/Application objects encapsulation was the ability of avoiding casting each time that we would use these objects, this is annoying especially we uses the specific object in most of the flows of the application.
The other goal is getting the ability of managing these objects in one centered place.

NOW, some extesibility...
This object need to be maintened everytime that we want to add a new session/application object. Good usage of generics will solve this problem -> this will bring up the ability of adding new objects everywhere that we'll want (example in the continuance...).

So, look at the following implemetation:

public static class SessionRepository
{
   public static bool IsExist(string objectKey)
   {
      return HttpContext.Current.Session[objectKey] != null;
   }

   public static TObject GetInstance<TObject>(string objectKey)
   {
      return (TObject)HttpContext.Current.Session[objectKey];
   }

   public static void Add<TObject>(string objectKey, TObject obj)
   {
      HttpContext.Current.Session.Add(objectKey, obj);
   }
}

Some usage:

if (SessionRepository.IsExist("SomeObjectKey"))
{
   SomeObject obj = SessionRepository.GetInstance<SomeObject>("SomeObjectKey");

   // Do your things...
}

SessionRepository.Add<SomeObject>("SomeObjectKey", SomeObject);

This way of implementation comes to help us with the casting issue and it gives up extensibilty options. I think that there is a small disadventage here - we also need to remeber the keys of the objects in the session object - but there is nothing perfect.

Summary:

1. Both of the solutions are good and each has each advantages/disadventages, you can prefer the best way of using.
2. The first way (shown in the former post) enables you a direct access to the object stays in the session/application, but need to be managed for each time we want to add new object into the session/application.
3. The way shown here holds a different approach, enables you extensibility, but you don't have the explicit access to these objects.
4. In both ways, the casting issue is covered!

That's it for today.

Commets will be appriciated...