I have uploaded Silverlight sample that uses my VBScript.net compiler to http://www.codeplex.com/aspclassiccompiler. It is available under the source tag in change set 31328 or later.

I am not quite using the capabilities in Microsoft.Scripting.Silverlight yet. I want to take advantages of it when its document becomes available. For the time being, I created my own little host called VBScriptHost in the SilverlightApplication1 project.

I modified App.xaml.cs to create an instance of VBScriptHost and expose it. In MainPage.xaml.cs, I created a ScriptScope object. This is the object that I feed host variables to VBScript. I then parse this object to the Execute method of a CompiledCode object.

In the example, I passed MainPage itself with the variable name "page" to the VBScript. In order to expose the object hierachy of the MainPage, I have to expose MyButton using the x:FieldModifier="public" attribute; otherwise, it is an internal property and is hidden from the dynamic code. In future versions, I will modify my binder in an attempt to access the internal properties so that we do not have to change the access level of objects in the page.

As usually, it can be downloaded from the source tab of http://www.codeplex.com/aspclassiccompiler.

1. This version is built with DLR 0.92. It is compatible with VS 2010 beta 2.
2. We have resolved all API difference with Silverlight so that Silverlight build of our VBScript.net compiler is available for the first time. We will upload some samples in the next weekly release.
3. All the binaries are consolidated into the bin folder.

Going forward, we will stay on DLR 0.92 for a while so that we have a stable build so fix the bugs in core features.

Today, I have uploaded change Set 30945, version 0.5.3.32871, built with DLR Changeset 32871. It could be downloaded from the source tab of http://www.dotneteer.com/aspclassiccompiler. The following are a summary of changes:

1. Now ASP Classic Compiler would run under medium trust or Windows Azure partial-trust. Partial-trust is the default trust level of Windows Azure. Windows Azure does not support asp classic. Windows Azure supprots php but requires full-trust. Asp Classic Compiler is the only way to run asp page on Azure without changing the trust level.
2. Azure sample uploaded. We modified only one view /home/index.asp but that is enough to prove the concept.
3. Variable initialization in declaration statement as a VBScript extension. For example: dim s = new system.text.stringbuilder()
4. Add the operator overloading through extension methods. C# supports extension methods, but not "extension operators". We added this support so that we can add new behavior without the need to modify our binders. Some typical asp code would now run much faster by a simple change. For example, asp pages often have codes like:

<%    
dim s    
dim i        
s = "<table>"    
for i = 1 to 12
s = s + "<tr>"
s = s + "<td>" + i + "</td>"
s = s + "<td>" + MonthName(i) + "</td>"
s = s + "</tr>"
next    
s = s + "</table>"    
response.Write(s)
%>

<%    
imports system    
dim s = new system.text.stringbuilder()    
dim i        
s = s + "<table>"    
for i = 1 to 12
s = s + "<tr>"
s = s + "<td>" + i + "</td>"
s = s + "<td>" + MonthName(i) + "</td>"
s = s + "</tr>"    
next    
s = s + "</table>"    
response.Write(s)
%>
Note that we added "+" operator as an extension operator for the class System.Text.StringBuilder. 

Whenever I search subjects relating to rapid application development, I always encounter Ruby On Rail (ROR). So I decided to take a look of ROR. The creators and supporters of ROR have done an excellent job to make starting with ROR really easy. Instant Rails has made download and installation a one stop shopping.The Rolling with Ruby on Rails is one of the best articles that I have ever read on introducing a new subject.

What makes ROR so productive? I think the following features really make ROR productive:

1. Scafolding: ROR's code generator can generate the skeleton code from a database table. One can then work on generated code to meet the needs.
2. Migration: A typical problem with database application development is what to do when the table schema is changed. ROR has excellent data migration tool built-in.
3. Convention over configuration: ROR uses MVC pattern.Unlike other MVC frameworks such as Struts or String, ROR uses convention to instantiat objects and assemble them together. We neither to work with configuration files, nor have to assemble the objects.
4. ActiveRecord: ROR's model often is simply a subclass of ActiveRecord without additional properties. It is not necessary to regenerate the model when the table schema is changed.
5. Ajax support: ROR really shines at utility functions that can generate Javascript code to create an AJAX application.
6. Easy to create unit tests to test the model and controller.

So am I going to develop my next big application wth ROR? I am still sketical for the following reasons:

1. Scalability concern: I don't think I can do everything in Ruby. I think is much easier to find libraries in Java or .NET. So if I want to create an application with a single language, Java or .Net is a much better bet.
2. Errors are captured at runtime instead of compile time.
3. Debugging support.
4. Model has access to database. I really hope model and persistency are implemented in different layers.

ASP.NET is current still my favorite web application development tool because it is the best tool for build sophiscated view for its support for rich controls. Microsoft has created excellent RAD tools such as strongly-typed dataset and it is nearly as productive as ROR. The main draw back with RAD deeloped with ASP.NET/Strongly-typed dataset is that the view and controller are combined in the code-behind so the controller is not testable. So we really need a scafolding tool to make it easier to generate the MVC skeleton. I am glad to see that projects like SubSonic is emerging.

JSF is the latest offering for the Java web application development. JSF is an MVC framework, similar to Struts. JSF is an enhancement to Struts:

1. The action is now mapped to a method of a bean instead of a servlet. Components can now have events. This is much more like code-behind in ASP.NET. This reduces the number of files one has to work with.
2. More custom tags and richer controls, such as Data Tables.

Here is how JSF compares with ASP.NET 2.0:

1. ASP.NET 2.0 is the mainstream development framework in .net world. JSF is still considered as unproven. Only a quarter or less Java web developer jobs requires JSF.
2. JSF is a specification instead of implementation. Depending on the implementation used, one may get more or less rich components. So evaluating implementation itself is a major task.

In conclusion, projects using ASP.NET 2.0 should expect stable and well behaved frameworks. Developers should find it much easier to develop web applications with richer functionality and to work with AJAX.

Struts is an MVC framework for Java web application development. Struts 1.0 was released in July 2001, roughly a year before ASP.NET 1.0. Currently, 70-80% of Java Web application developer's job requires Struts so it is fair to say that Struts is the current mainstream framework for Java web application.

Struts contains an MVC framework and a set of JSP custom tags. For a simplest application, developers need to provide:

1. An html form in which user can enter data.
2. A Struts bean that serves as model. The inputs in the form is mapped to the properties of the bean.
3. An action servlet which serves as controller.
4. One or more JSP pages that serves as view for the results.

The components are wired together with a configuration file struts-config.xml. Struts framework actually provides a servlet as front-controller in which all actions go to. The front-controller is responsible for instantiate the Struts bean, dispatch the action and route to the approprate view based on the return of the action.

In addition, Struts also supplies custom JSP tags that provides the following functionalities:

1. Preserve the state of input if the view is same as the form.
2. Validation.
3. Layout with Tiles.

Struts provides serveral important functionalities in the framework and significantly reduced the repeatitive tasks in Java web development. ASP.NET does not require a regid MVC pattern like Struts (which could be both pro and con). Besides that, ASP.NET does almost every other things better:

1. Struts still requires coding the same information twice, once in form and the second time in bean. In ASP.NET code-behind, controls are automatically created from form. In additional, ASP.NET supports rich controls, i.e., controls not available in HTML.
2. The modle, view and controller of Struts is scattered in many files. The only place to find them is in the struts-config.xml file. It is inconvenient to work with large number of files. Although the seperation of functionalities into many classes remotes reuse, in reality, the classes are rarely reused.
3. ASP.NET's mechanism to preserve form state is simpler to use.
4. ASP.NET's validation architecture is better and it is transparent to render client-side Javascript depending on the type of clients.
5. ASP.NET's master page and skin is superior to Tiles.

In conclusion, also Struts is a significant improvement over normal JSP/Serlet programming. Struts is still far behind ASP.NET in functionality and productivity. There are tools like AppFuse that would make Struts development easier. It is still nowhere near the experience with Visual Studio 2005 and ASP.NET 2.0.

Perhaps it is time to compare ASP.NET with JSF which is the latest offering in the Java world.

ASP (Active Server Pages) was a revolution to web development when it was released by Microsoft in 1997. Since then, Sun has answered with a better tool in JSP. Microsoft answered to the Java challenge with ASP.NET in 2002. How do they compare to each other? I have done a survey and will anwer the question in a series of posts.

ASP allows server scripts and expression to be embedded in HTML. When it is desirable to seperate the code from the content, one would write the code in a COM object (usually written in VB6) and call the COM object from ASP page.

JSP (JavaServer Pages) has the following advantages over ASP:

• ASP is interpreted while JSP is compiled - better performance.
• In the Java world, one can develop Servlet and Servelet filter. In ASP world, one has to use C++ to write ISAPI Extension and ISAPI filter. ISAPI Extension and filter does not share session state with ASP. While the Servlet functinality is not essential, lack of filter is a limitation for ASP.
• In Java world, one often seperate presentation and code with JSP/Java Bean, like the ASP/COM object combination. One limitation for the Java Bean is that it does not have context while the COM object can access the context. To access the context, one has to write custom JSP Tag. The capability of JSP does make custom components look like HTML.

ASP.Net was Microsoft's answer to JSP. ASP.NET not only has all the capability of JSP, it also represent a major productivity boost:

• ASP.NET's HttpHandler and httpModule is equivalent to Servlet and servlet filter.
• ASP.NET support custom controls, like the custom JSP tags.
• ASP.NET supports a code behind model. This is a productivity boost compare to JSP/Java Bean. With JSP/Java Bean, one has to code the inputs once in the form and then again in the bean. One only create the controls once in ASP.NET pages and they are automatically accesible in code-behind.
• ASP.NET support rich components (none-HTML, such as Grid and TreeView. These are usually DHTML controls manipulated by JavaScript with states saved in a hidden input control. ASP.NET has the viewstate framework for store and retrieve the property of controls. These rich controls can be accessed in the code-behind page transparently like any other control. JSP/Java bean are limisted simple HTML inputs. Therefore, it is much easier to develop feature rich page with ASP.NET than the JSP/Java bean approach.

In conclusion,  JSP is about half way between ASP and ASP.NET. It is perhaps not fair to compare ASP.NET and JSP since they are not really in the same generation. A better comparison to ASP.NET might be JSP/Struts or JSF.

http://www.opensourcetemplates.org/ has some really nice templates.

The problem

When I worked at ESRI, I worked on the .net version of ArcGIS Server Manager, which is a web-based front-end for ESRI’s ArcGIS Server products. The Java team also has a Java version of the product based on the same UI spec. I was the only .net developer on the .net version while the Java team had 2 ½ developers on the Java version, but I was constantly ahead in features. I was proudly thinking that I am a much better developer than my peers on the Java team.

However, a recent project changed my thinking. My current employer is migrating some VB6 based projects to Java. I developed a web service in Java. At the end of project, I have some time left. So I decide to develop a few simple CRUD pages for the configuration table. The idea is fairly simple: I want to develop a page that lists the records in the table. It has a single form at the end of the page that allows me to insert a new record, as seen in the picture below:

When I try to edit the record, the page will enter the edit mode. The row that I try to edit would contain some textboxes. The edit/delete link would change to update and cancel. The insert form would be hiden, as seen in the picture below:

This is a fairly standard feature in asp.net. I can develop a page like this in a few clicks in less than an hour. However, in Java/JSP, I search the Google with words like “Java and RAD” but could not find any rapid application development solution that is simple to use.

The solution

I did a survey on how Java developers do similar things with JSP. JSP allows scriptlets, like ASP developers embed script inside the ASP page. However, it is not good practice to embed lots of code in the contents page. Servlet is a good place for code. You cannot embed Servlet in an JSP page. A typical pattern is that people will have a page post to a Servlet (controller) to do all the processing. The servlet will then forward/redirect to a JSP page (View) to display the result. That is a good practice except the view could need lots of scriptlets if there are lots of conditional rendering. It is possible to embed Java Bean in JSP. However, Java Bean does not have access to Http context. To gain access to the Http context, one would have to develop custom Jsp tags.

Since my goal is to develop a CRUD page that allows me to edit an simple table, here is the design approach that I take. I have one JSP page and 3 servlets. The 3 servlets are used for handling insert, delete and update. The JSP is reponsible for displaying the data. It also contains scriplets to switch between normal and edit mode:

1. Normal mode: Display the table normally. Show the insert form.
2. Edit mode: Display the row being edited as textboxes. Display the button of the row as Update and Cancel. Hide the insert form.

Here is the code:

boolean editMode = (request.getParameter("kc") != null);

if (editMode) {

    action = "updateConfig?kc=" + request.getParameter("kc") + "&kk=" + request.getParameter("kk");

} else {

    action = "addConfig";

}

<form action="<%= action %>" method="post">

    <table>

        <tr>

            <th>Configurationth>

            <th>Keyth>

            <th>Valueth>

            <th>th>

        tr>

<%

while(rs.next()) {

%>

<% if (editMode && rs.getString("CONFIG_NAME").equals(request.getParameter("kc")) && rs.getString("KEY").equals(request.getParameter("kk"))) {%>

        <tr>

            <td><%= rs.getString("CONFIG_NAME") %>td>

            <td><INPUT type="text" name="key" size="20" maxlength="64" value='<%= rs.getString("KEY") %>'>td>

            <td><INPUT type="text" name="value" size="20" maxlength="254" value='<%= rs.getString("VALUE") %>'>td>

            <td><INPUT type="submit" value="update"><a href='config.jsp'>cancela>td>

        tr>

<% } else { %>

        <tr>

             <td><%= rs.getString("CONFIG_NAME") %>td>

             <td><%= rs.getString("KEY") %>td>

             <td><%= rs.getString("VALUE") %>td>

             <td>

                 <a href='config.jsp?kc=<%= rs.getString("CONFIG_NAME") %>&kk=<%= rs.getString("KEY") %>'>edita>

                 <a href='deleteConfig?kc=<%= rs.getString("CONFIG_NAME") %>&kk=<%= rs.getString("KEY") %>'>deletea>

             td>

         tr>

<% }

}

%>

<% if (!editMode) {%>

         <tr>

             <td><INPUT type="text" name="configName" size="20" maxlength="64">td>

             <td><INPUT type="text" name="key" size="20" maxlength="64">td>

             <td><INPUT type="text" name="value" size="20" maxlength="254">td>

             <td><INPUT type="submit" value="insert">td>

          tr>

<% } %>

      table>

form>

I felt that I go back 10 years in time and become an asp programmer again. So here is what I think why at ESRI my peers on the Java team are so much slower than me:

1. JSP does not have an efficient method like code-behind in asp.net that allows close interaction between code and view.
2. The MVC frameworks like Struts that is main stream in Java community tend to product large number of classes for simply thing. Also the MVC promotes separation of responsibility and reuse at the first glance. However, in real life, only a small number of classes are actually reused; most of classes are only used once. The large number of classes create problems in both naming and finding things. In ASP.NET, it is far more easier to work with things and find code.
3. JSP lacks a component model to work with non-HTML controls. Here the non-HTML control means a sophiscated control like Tree that is composed of html, images, css. Its behavior is manipulated by Javascript and DHTML and states often saved in a hidden control. JSP and MVC framework like Struts can only handle native HTML controls. The rich components are handled outside of framework. Therefore, I would say that JSP is about half way between asp and asp.net. For an asp.net developer to work on JSP, it is like going back to stone page.
4. I hope JSF will provide a rich component model that rivals that of ASP.NET. Unfortunately, both the development and the adoption have been so slow. It does not help that our company is still standardized on J2EE 1.4.