Skip navigation

IntraWeb for ASP.NET

Writing ASP.NET Applications in an Application-centric Way

asp:review

 

IntraWeb for ASP.NET

Writing ASP.NET Applications in an Application-centric Way

 

By Mike Riley

 

As the popular axiom says, there's more than one way to solve a problem. And in business, the best way in the eyes of management is often the fastest. ASP.NET has dramatically accelerated the ability to design, code, and release Web-based applications. However, many programmers have yet to invest the time necessary to learn the most effective paths and best practices.

 

Recognizing that there are still legions of technologists who have yet to become advanced ASP.NET developers, Atozed Computer Software has ported their award-winning IntraWeb Web application development framework to the .NET platform. By doing so, they have made the lives of many developers much easier.

 

.NET Development the IntraWeb Way

IntraWeb forgoes the HTML page metaphor in favor of a WinForm-like approach to Web application development. As such, laying out pages and assigning actions to click events is more like developing a VB6 or Delphi application as opposed to an ASP.NET HTML client presentation layer. Because the design surface of an IntraWeb application is encased in an Atozed.Intraweb.AppFormUnit class, every object contained in it optimally derives from the Atozed.Intraweb tree. As a result, labels, text and list boxes, images, database objects, and even rich media objects (such as MPEG and QuickTime references) have their own IntraWeb derived controls.

 


Figure 1: An IntraWeb application uses its own user interface objects, including everything from text fields to media elements.

 

Naturally, any other .NET component can also be added to and consumed by the IntraWeb application. As a result of the IntraWeb palette, a mind-shift must take place for existing ASP.NET developers to warm up to and appreciate the efficiency IntraWeb has to offer. It took me over a week to acclimate and reorient my perspective toward the form-based, application-centric approach that IntraWeb's design demands, compared to the page-based metaphor that ASP.NET and other dynamic page-generating scripting languages require. Therefore, only developers who are open to new approaches will be amenable to IntraWeb's application design and deployment philosophy.

 

Once open-minded developers do become enlightened by the speed and simplicity that IntraWeb has to offer, a deep appreciation for the product's capabilities begins to overtake the concern and skepticism of proprietary vendor lock-in. It's true that coding with IntraWeb's assemblies can house .NET applications in an abstracted application entity, but this can actually work toward some developers' multi-platform environments. In addition to the .NET platform, Atozed has released IntraWeb for Delphi for Win32, Kylix for Linux, and Java, giving applications built using its framework much more operating system and language flexibility than ASP.NET.

 

Another advantage is the speed of application development using IntraWeb as compared to ASP.NET. For any developer who has learned ASP development from Microsoft's IBuySpy demo, Atozed has reconstructed that shopping cart demonstration using IntraWeb using a fraction of the code. Not only does this save paper, it also makes it considerably easier to understand what the application is doing. For example, looking at the validation code for an IntraWeb object is similar to validation code attached to a Windows Form control. After I wrote a few examples of my own, I asked myself in amazement, "Is that all I have to write? I'm done already?!" Needless to say, I was impressed with the rapid development results that IntraWeb promised and delivered.

 

IntraWeb applications can be compiled and executed as either ISAPI DLLs or standalone .NET executables. The standalone approach, although once again having that counter-intuitive "bad design" stigma associated with standalone Web servers, may be useful for small department or prototype demonstration purposes. I found that it was also considerably easier to debug a standalone application versus a DLL. And once my IntraWeb app was working to my specifications, I easily converted it to an ISAPI DLL. Try doing that with an ASP.NET app!

 


Figure 2: IntraWeb applications can be deployed either as ISAPI DLLs or standalone executables.

 

Trusting in IntraWeb

As I stated earlier, the steepest learning curve associated with IntraWeb is the deprogramming necessary for existing dynamic script-based page developers. It's definitely easier for traditional Windows Forms-based programmers to learn and write applications with IntraWeb than it is for veteran ASP.NET developers. As such, it's not a framework that everyone will want to use. Large enterprises that already have blackbelt ASP.NET developers may find the paradigm shift too disruptive and initially constraining. But even those diehards may consider it at least for rapid prototyping needs after they see how few lines of code were required for the dynamic image map product demo.

 


Figure 3: One of several example projects is Die, Fly! Die!, an IntraWeb version of Microsoft's popular IBuySpy demo.

 

However, because IntraWeb handles everything, developers are sometimes at the mercy of the presentation layer syntax returned to the client browser. This rarely is a problem with Internet Explorer, but I did encounter some nasty layout issues running IntraWeb applications in a Mozilla Firefox browser. (Atozed was already aware of the Firefox issues and expected to address them in a future release.) When IntraWeb encounters a browser header of unknown origin, it defaults to displaying a "Device not supported" error message that could be a problem serving certain mobile clients that don't fully support the HTML 3.2 or higher specification. Another oddity was the fact that the product's integrated help-based documentation requires a separate download and installation instead of being bundled with the primary application installation package. The company is going to address this issue as well.

 

Conclusion

The more I used IntraWeb for ASP.NET the more I appreciated its powerful and timesaving features. Although I would still most likely use straight ASP.NET for most of my Web development needs, because of my experience level and the number of components and code snippets I've amassed over the two years I've been developing for it, I may turn to IntraWeb for that quick prototype or unique request by a customer not interested or capable of running IIS and who needs a standalone approach that is sand-boxed by the .NET Framework. If simplicity and speed of Web application deployment are paramount, IntraWeb may be the ideal solution.

 

Rating:

Web Site: http://www.atozed.com/intraweb/

Price: See Web site.

 

Pros

Cons

Excellent rapid prototype development tool for Web-centric application designs.

Modifying presentation layer syntax for multi-browser support is problematic.

Powerful functionality that would take pages of ASP.NET code can be designed with IntraWeb using only a few lines of code.

Learning to readjust to IntraWeb's application-centric approach may be a challenge for seasoned ASP.NET developers.

Proven technology available for four platforms (.NET, Win32, Java, and Linux).

 

 

 

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish