WebGui Homepage
AJAX has been becoming increasingly popular as it continues to buld the basis to provide users of web based applications with more capabilities of the client-server rich-client interface. AJAX’s underlying foundation of the XMLHTTP protocol is nothing new and has been around since the heyday of “Classic ASP”. Nonetheless, the new capabilities that AJAX frameworks are providing are bringing increased richness and useability to web applications. At the same time, new security threats are threatening the AJAX development model as hackers continue to find ways to exploit security vulnerabilities with the client-side call that the AJAX frameworks provide.
Now another entry into the growing field of AJAX frameworks has come up on the radar which may be worth a look. The open-sourced framework, “Visual WebGui” hopes to resolve some of the issues currently plaguing most AJAX implementations today.
The excerpts below from the “Visual WebGui” website should give the reader a more concise understanding of what this framework hopes to accomplish.
Steve Naidamast
Black Falcon Software. Inc.
What is Visual WebGui?
Visual WebGui introduces a different approach to AJAX front-ends. While the trend is towards empowering the client (browser) with more capabilities, enabling direct consumption of services by client side objects and distributing processing between the client and the server, WebGui adopts the server based computing approach whereby service consumption and processing is handled on the server and human interaction is handled on the client. This model provides intrinsic benefits for enterprise applications since it provides additional measures of security and control which are not available on browser based solutions. This approach, called “Empty Client”, employs de-coupled GUI components which decouple GUI logic from GUI presentation (rendering) and enable remoting of the display/input capture between the client (browser) and the server. It is this approach that provides an even greater benefit by enabling application logic (usually entailing both business and presentation logic) to be handled within one, stateful, object-oriented environment developed in a high level, OOP language such as C#, VB.Net or Java rather than a mix between Javascript and a server based language.
Using a homogenous platform provides developers with immeasurable productivity benefits and enables developers to make better use of existing assets, knowledge and experience rather than requiring the steep learning curve of AJAX. Visual WebGui provides server side controls which behave like existing desktop application controls both in design time and in run-time. These controls manifest themselves as AJAX controls on the browser in run-time and look like their desktop counterparts. The architecture of the system is in no way limited to representing these base controls in their current “desktop” look and feel since it makes use of de-coupled components. Our initial offering contains the popular Microsoft controls that are a basic part of any Windows based application. These controls provide a huge productivity benefit to web developers who lag behind their desktop bretheren, while supporting the most common needs of desktop application developers without letting them down.
In addition the system is extremely extensible. Visual WebGui’s SDK enables extending the framework by adding additional controls, changing themes/flavors (skins), creating composite controls based on base controls and creating gateway components. Since ultimately Visual WebGui is an extension to the app servers context (in the case of .Net an extention to IIS/ASP.net) it can interoperate with client side and server side legacy code. This means that Visual WebGui UIs can host and interoperate with existing HTML/Javascript client only controls or with embedded DOM objects such as Applets and ActiveX controls. Similarly existing web applications can interoperate with WebGui components/forms/windows since they are in essence URLs like any other sharing the same application and session context.
As a web developer, you are used to working with requests, responses, html and scripts, as your tools of the trade. These serve you well when you are creating sites, and you can even utilize such tools to create a full blown application. But, developing web applications is definitely not a job for rookies, and even web experts don’t get the job done without a good deal of sweat. Visual WebGui was developed to offer an alternative. It provides you, the developer, with a new tool to simplify development of complex web applications.
If you really think about it you will reach the conclusion, that you have been using a hand drill to do a tractor’s job. The irony of it, is; that on the other side of the world, there is a VB6 or WinForms developer, that is doing exactly what you are trying to do, but what takes you weeks to achieve, he achieves in days.
Why does it take him a few days and not weeks? We will show you in the following paragraphs. but for the time being, just imagine that you had his tool working for you on the web, can you imagine what effect that might have on your productivity? If you have a mental picture in your head then you have imagined Visual WebGui.
With Visual WebGui you will still be creating the same standard, browser agnostic, zero footprint web application, only using a much more powerful and intuitive tool. As an added bonus to getting your job done quicker, you will also be able to add WinForms skills to your resume, as Visual WebGui is really WinForms working on web.
WinForms vs. WebForms
The concepts that you are so familiar with in WebForms, originated from the evolution of the web. From static pages to dynamic client-side and server-side pages, pages are still the cornerstone of every web environment. They serve well as a general purpose environment, ranging from developing personal home pages to developing full blown enterprise applications.
WinForms on the other hand originated from VB, MFC and other desktop environments and were developed solely to serve application development. As such, they are much more applicable for developing applications, and provide larger building blocks for developing such applications.
This explains the great difference in implementing the same solution on each environment. As a web developer you have to deal with many details, and low level interactions, which are taken for granted by desktop developers as part of their environment. In the following section we will go over the main differences between WebForms and WinForms together, and see, that there is more than just a difference in implementation time.
Events vs. Requests and Responses
In the past, web environments were totally based on requests and responses. Meaning that you would have a form, that was submitted to the server as a request that generated a server response. Such concepts have evolved with time, and translation was added to events layer, that resulted in environments like ASP.NET and J2EE, a much more intuitive way to program your application.
Although events were introduced into web environments, they did not match their desktop counterparts, which forced developers to add their individual scripting client side glue code. When AJAX was introduced such concepts were reshuffled once again as most of the logic was transferred to the client. This forced the developer, yet again, to deal with the need to use requests and responses in order to implement his application.
Desktop developers on the other hand were always given a fully event driven environment, making their development tasks much simpler. Programming a file explorer like application, was for them as simple as dragging a tree view and a list view and implementing a couple of event handling methods. While web developers had to deal with exposing services and consuming them, and of course, doing all that as scripting on the browser.
Forms vs. Pages
As a web developer, you are familiar with the concept of a page which originates from the early days, when such pages where static resources that had links to other pages. The concept of a page is excellent when you are implementing a web site, but creates lots of work when creating applications. Take for example a dialog scenario which is implemented over web using two disconnected pages bound together through a client side script.
Imagine that creating a dialog was as simple as creating an object, calling its methods, and setting its properties. This is exactly how desktop developers see dialogs. This concept is called forms. A form, represents a window which can have child forms, which are windows as well. It sounds outrageous; that when you create a page that has a script, which in turn opens a new browser window with a second page, which receives arguments and displays user interface, which then, uses a script that is used to callback the parent page… all that, while a desktop developer simply creates an object.
When you are working in single object oriented layer, you are also able to implement many useful design patterns, such as the observer design pattern. This means that when objects need to interact with each other they only need to post an event to the form and other objects will subscribe to that event saving you the hassle to explicitly bind events between controls. Just to underline the difference, the same task in the web scenario would require multiple cross referencing scripts.
Form Designer vs. Text Editor
It is only natural that in a web environment application design will take the form of a text editor. Originating from content, web environments require the flexibility of a text editor. The web development editor usually provides a mechanism for adding controls while most of the layouting is done by hand.
Desktop environments on the other hand always kept it simple. Their dedicated nature made them available with very productive designers, allowing developers to really design their application with no need for hand coding whatsoever. Using concepts like anchoring and docking they achieve layout exactly how they want it.
Programming a complex dialog, using desktop designs, is as easy as using a Power Point application. This provides desktop developers with the ability to rapidly develop, and if need be, change their dialogs. Changing the layout in web environments, usually requires a great deal of headaches to the web developers which are required to recode large tables to implement the new layout.
Single Language vs. Multiple Languages
As a web developer you have to master a lot of different languages in order to implement a web application. You have multiple server side pages, interacting with multiple script files and CSS files, which are required to work together as a well oiled machine. To spice up your web development task, you also have to do it in multiple layers, which add a greater level of complexity. It is common knowledge that the more application parts you have, the more work you will have to put in to develop and maintain your application.
Desktop developers on the other hand use a single compiled language to manipulate a well defined object model, which dramatically reduces the complexity of their applications.
Using the explorer application scenario again, a WinForms implementation will include one single layered, compiled file, while developing the same application using WebForms will contain multiple files in multiple languages, with multiple layers. The complexity differences grow dramatically as the complexity of the application grows, presenting a glass ceiling for web developers that is reached very quickly.
Full OOP vs. Semi OOP
As a web developer you get to use object oriented concepts in a small portion of the implementation which dramatically decreases when combined with AJAX. The importance of these concepts, for complex applications is crucial and the emerging of frameworks such as GWT and Script# show that the big guys are aware of these issues as well. These frameworks generate your scripts for you while allowing you to develop your application in a fully object oriented programming environment. But do not sit back too soon; this implementation presents a loose connection between your code and the runtime code making it very hard to debug your application.
Desktop developers on the other hand, are provided not only with a full OOP environment, but also with lots of mature concepts that have been developed during many years of developing desktop applications. Design patterns originating from desktop development have through the years found their way to web implementations, but the architecture of web environments, permits only partial implementation of them, leaving a great deal of useful design patterns exclusively to desktop developers.
Data binding vs. Data oriented
As a web developer you are used to working in a stateless environment forced by the need to be scalable. But even when you are not implementing the next Amazon application, you are still presented with the same general purpose tools. It is common practice to implement stateful web applications as it dramatically simplifies implementation and reduces security issues. However, working with pages still implies some kind of stateless implementation that presents developers with non-trivial tasks.
Desktop developers on the other hand, are provided with a stateful environment which utilizes the state to simplify development tasks. They are presented with a full object model allowing them to interact with the UI elements in a much more intuitive way. They are provided a richer data binding mechanism again simplifying their development tasks.
Full vs. Limited User Controls
As a web developer, you are used to having user controls not sharable between applications. If you insist on sharing them you have to switch to web controls which are implemented in a lower level without design time capabilities.
Desktop developers are provided with a user control mechanism that can be used across projects, which is a very important feature if you are a component vendor or if you are an architect that wishes to divide your solution into different logical parts that are developed by different teams. Design time usage of these controls generates an actual presentation of what the control looks like rather then a square place holder.
Dedicated vs. General Purpose
Bottom line! Web environments were not intended to be used as a way to develop applications. The web evolved layer after layer, trying to close the gap between web environments and the desktop. After many years of evolution, the underlining concepts of web environments are still there limiting the ability to provide a solid basis for web application development. While web concepts are lacking for developing applications, desktop environments have always been there providing a much more reasonable way to develop complex applications
Visual WebGui is offering you the same tools and capabilities that were designed for developing desktop applications reengineered to work over HTTP. Under the hood we are still providing the same legacy HTTP request/response interface that standard browsers can utilize but we are exposing you to plain old reliable desktop concepts. You get to enjoy the richness and effectiveness of a desktop development environment without loosing any of the capabilities that you enjoyed when you developed using web environments. Although we are presenting you with a desktop like framework Visual WebGui is an extension to ASP.NET and lets you combine and use the best of both worlds.
Architecture
VWG applications do not require installation on the server!VWG is implemented as an IHttpHandlerFactory and is deployed with your application as a couple of runtime assemblies. Deploying a VWG application is no different then deploying an ASP.NET application, except that it requires you to register the WGX script map extension, mapped the same way as ASPX script map is mapped.
VWG does not process logic and data in the browser!A VWG application is implemented using a single layered server side code which manages a remote UI presentation layer on the browser.
VWG applications do not require opening services for browsers to consume! As said in the previous paragraph, a VWG application is implemented using a single layered server side code which is the only layer that needs to consume services. VWG applications are written as if they where local WinForms applications with the exception that they are still running in a web environment. That said you can still implement components that consume services.
VWG does not generate JavaScript code! The scripts used by the browser are either VWG core services or VWG UI components logic which should not change from one application to another. Every VWG component provides its own controlling script and it can interact with the VWG client services, VWG client state data and its DOM elements. Interacting with the server side component is done using the VWG client services, normally by raising an event that is handled on the server. This means that the code you write is the code that runs in runtime execution and as so debugging is done on the actually running code as opposed to GWT implementation.
VWG applications are stateful! VWG applications provide server based computing over ASP.NET. This is implemented by using the ASP.NET session object as the application container. In terms of scalability and redundancy VWG applications should currently utilize a session sticky hosting approach and can also utilize a state serializing UIP application block. Floating session support will be available in the future (currently not enabled because of delegate serialization).
VWG optimizes communication band width consumption to the minimum, by separating between UI logic, UI templates and UI metadata. The UI logic and UI templates which are comprised of scripts and XSLT templates, that implement the different UI component behaviors and appearances, are loaded to the browser once as cached resources. The reset of VWG communication is done through UI metadata updates sent to the browser and UI event queues sent to the server.
VWG does not rely on ASP.NET’s page model! VWG applications provide a different pipeline dedicated for serving applications over HTTP which provides an alternative to ASP.NET pages. VWG implements the concept of WinForms forms over ASP.NET base classes. VWG forms are mapped using the web.config to virtual URLs. Every form can have multiple child forms and multiple controls just as a WinForms application form.
VWG projects are actually ASP.NET projects! This means that you can enjoy both worlds utilizing the right tool for the right task. VWG can extend existing ASP.NET applications by implementing dialogs in VWG and consuming them from ASP.NET pages. VWG can use ASP.NET pages through gateways (see next paragraph) enabling developers to use ASP.NET pages with in a VWG application. A sample usage could be populating an HtmlBox using an ASP.NET page for displaying reports.
VWG provides a concept of gateways to bridge the gap between the WinForms object model and the web architecture. “Gateways” is a mechanism that enables declaring a VWG component as a gateway, which can be compared to implementing an IHttpFactory. The URL of the gateway can by extracted using the GatewayReference object and used by the browser. A sample usage of gateways can be creating a graph control by inheriting the PictureBox control and implementing it as a gateway so that the image displayed will be dynamically generated (see the graph control sample with in the catalog application).
VWG provides a mechanism to implement custom controls. VWG custom controls are no different then the build in control accept that built in controls don’t have to be registered. The VWG configuration section with in the web.config file contains a controls section which enables registration of custom controls (see the WinPanel control with in the catalog application or explore the open source code to see how the built-in control where implemented).
VWG provides a concept of themes to customize the presentation layer. A VWG theme is actually an assembly that has embedded resources. Those resources are used to override core component resources and custom control resources. This means that you can override the TabControl template for example to display the control in a completely different layout. The resources are embedded according to the namespace of the overridden resource. If for example you have a “TextBox.xslt” resource embedded in Gizmox.WebGUI.Forms you will embed your overriding resource in “Gizmox\WebGUI\Forms\TextBox.xslt”.
VWG provides a concept of flavors to provide theme variations. A VWG flavor is actually a set of name/value definitions that can be used in the different CSS files. You can select the active flavor from the web.config. Flavor definition files can also be overridden using themes.
