My diary of software development

Archive for the ‘Web Development’ Category

jQuery UI Script# Import Library

Script# comes with a jQuery import library but not a jQuery UI import library. I went out looking for one and found one on CodePlex named Script# Contrib which hadn’t been completed yet but it was a great start to the concept.

I took it and completed it for jQuery UI 1.8.21 and contacted one of the developers to ask about merging or forking my code. He told me they weren’t working on it anymore and to go ahead and fork it.

So I took it, cleaned it up, and wrote the jQuery UI Script# Import Library available here on CodePlex.

Advertisements

JavaScript Intellisense with Visual Studio 11 Beta

I’ve spent a lot of time in VS10 editing large JavaScript class frameworks and so I was very thankful for the Intellisense support in the IDE. It’s was a wonderful experience to write OO JavaScript with Intellisense but it was hit or miss when the Intellisense would actually show up in the IDE. It seemed that sometimes the IDE would just ‘forget’ about a class. And there were many other things which made the experience of writing in JS difficult at best such as all those times when VS10 SP1 would crash intermittently when editing large bodies of JS files.

I decided to take a look at VS11 beta and see how it handled Intellisense when doing JavaScript object oriented development. I knew that Microsoft was targeting JavaScript as one of the languages to build Metro apps from so I figured they may have cleaned up the JS development experience in the IDE.

To write this blog entry, I’m comparing the VS11 Beta as of March 2010 with my experience in VS10 SP1.

Referencing Class Files

In VS10 I had to place a reference comment in the file to see a class in another file:

/// <reference path=”Truck.js” />

This isn’t too bad unless you’re working with dozens of class files in which case you’ll have inevitable circular references somewhere. When VS10 ran into circular references, it would slowly leak memory and eventually crash.

In a VS11 Metro project, all you need to do is reference the JS class files from one of your .HTM pages. Once referenced, the class is available to you in every other JS file. So just adding this line to one of the HTM pages in your project will make the Robot class available everywhere:

<script type=”text/javascript” src=”js/Robot.js”></script>

But not in VS11 Web Projects

The above technique does not work in web projects, it only works in Metro projects which was very strange to me. In the web projects I still had to add reference comments to a JS file to pick up classes defined in other files.

Why? If the IDE can build Intellisense from the script tags in the web files for a Metro project, then why can’t it do the same for a web project? Maybe it’s something to do with the beta version, I don’t know but I’m anxious to try it out in the RTM version.

Thinking about running ASP.Net alongside an existing ASP script reporting site

A potential client has an existing web report site coded in legacy ASP script. They want to port the application to ASP.Net but do not want to take on the risk of doing this all at once. So I was asked to write up something quick and short about doing something like this which our sales people could take to them. The information which I put together is below. I’ve x’ed out the name of the potential client to protect the innocent and all that:
 
 

I understand that the current XXXX reporting site is too mission critical to allow a whole scale conversion to ASP.Net but that they do want to migrate it to ASP.Net. So, one way to reduce the risk involved in conversion to ASP.Net is to run the ASP script site side by side with an ASP.Net site while transferring components from ASP script to ASP.Net in a staged timeline.

 

I do not have architecture specifics for the XXXX ASP script reporting site to give details on how to do this, but most web reporting sites contain the following common components:

1.       A Security token to indicate the user has been authenticated and authorized to access the site.

2.       A connection to the reporting database.

3.       Report query criteria.

4.       Report data.

5.       Control information.

 

I’ll discuss each of the above components with regard to how a dual Asp script / ASP.Net site may work with them.

 

Security Token

The security token is an indicator that the current user has been authenticated by the application and is authorized to use it. This token is normally stored in session state although some sites may store it in a web cookie.

There are at least two recognized solutions to allow session state interoperation between ASP script and ASP.Net:

1.       Storing the session state in a common state server. The ideal state server would be a SQL Server database which contains all of the active sessions. In order for the sites to distinguish their session state from another session state in the database, the two sites would maintain a cookie key and use it to extract their appropriate session.

2.       This solution requires two special pages:

a.       An ASP script form to extract session objects and write them to a dummy form as hidden input types. This dummy form would have an ACTION pointing to the ASP.Net page described below.

b.      This ASP.Net page would iterate through the hidden input types written above and store them into the ASP.Net session object.

 

If the security token were contained in a cookie that cookie would have a very near term expiration and it would be simple for both the ASP script and the ASP.Net site to access the same cookie.

 

Reporting Database Connection

There would be no value gained from trying to share the same database connection between the two sites. Although at a deep level, the connection object is simply a series of network TCP packets sent to and from the SQL Server, at the level the web sites use the connection, it varies greatly. ASP.Net uses an ADO.Net connection and ASP script uses an ADODB connection.

 

 Report Query Criteria

This is information such as the date range and additional query criteria chosen by the user to extract their report data. Usually, the user is presented with a single page where they enter this criteria and then push a button which submits the page and returns their report data. This operation, where the criteria data is submitted and a report page is returned could be performed quite easily between an ASP script page and an ASP.Net page or vice versa. The data would be transferred between the two using the request header of the page.

 

Report Data

Sharing the report data between the sites is probably one of the trickiest things to do and I don’t believe there would be a need to do it. One use for it that I can think of is for a drill-down report. Perhaps levels one and two of the drill down report would be implemented with ASP script but levels three and four would be done with ASP.Net. It is my opinion that if a situation arose where report data needed to be shared between the two sites, that entire report should be migrated to ASP.Net.

 

Control Information

Control information is the type of information that glues the pages together so that they form a single consistent experience for the user. For example, it may contain the user’s preferences, or their navigation history so that they can easily navigate back, or it may contain their security role which allows them access to a filtered set of reports. This information is best stored in the database, the session, or cookies. All three of which can be easily shared between the sites.