Visual WebGUI – This Best Practice is part of a collection of advice provided by information technology professionals on how they have solved various challenges, and addressed IT priorities within their organizations.
FindItByMe.com, Inc., a local area search engine provider
FindItByMe.com needed to rapidly create a front-end for its search engine technology with limited resources, and a single developer.
Visual WebGUI, an open source rich Internet application (RIA) development and deployment platform atop standard .NET allowed FindItByMe.com to create interfaces that provided the best of the ASP.NET experience and the best of the WinForms experience. Visual WebGui was the only viable alternative to put the FindItbyMe site into production, given the company's limited resources. The tool's learning curve was also low enough which allowed FindItbyMe.com to mock up the front-end and save approximately $250,000 and two years of development time.
Who provided this information:
John Graffio, CEO, FindItByMe.com, Inc.
How it worked:
FindItByMe.com needed to deploy a publicly accessible web site in a short amount of time with only one developer who was proficient in WinForms but not as proficient in ASP.NET or web technologies. Since Visual WebGui provided exactly this match of capabilities to the requirements, it was a natural fit and a test was undertaken to see if its promise held true to its claims. A short test quickly turned into actual deployment, since the Visual WebGui environment was so easy to work in. In about three weeks time, a working model of the web site was running, compared to an eight week effort with classical ASP.NET that only resulted in a mock-up of a site with no real functionality.
Rules for success:
- The development platform must have allowed direct transfer of WinForms knowledge under the .NET environment.
- The platform must have allowed for rapid prototyping.
- The platform must have easily connected to Microsoft SQL Server, since this was the primary database back-end being used.
- The platform must have allowed for a concise coding model that allowed it to be easily maintained during each phase of the engineering cycle.
- The platform must have allowed for easy deployment to the web site, which turned out to be simply copying a dll file to the active web site.
- The platform must have allowed seamless integration to the ASP.NET environment where necessary.
- The platform must provide rock-solid security, which the VWG environment does provide.
- Understand how the Visual WebGui event system works, in that no code actually runs on the client. This can be critical if a classical ASP.NET programmer tries to get the VWG environment to act in a similar manner to classical ASP.NET.
- Be aware of the differences in access to resources between classical WinForms and the VWG implementation. While this is well documented in their literature and they provide numerous working samples to illustrate this difference, not knowing the underlying technology can be challenging to the uninitiated.
- Not making use of their instructional videos and forum discussions and experiences of other developers.
- Over-doing the interface to be too similar to WinForms in terms of workflow. While VWG's implementation of AJAX provides for the smallest amount of data to be transferred with screen refreshes, it can be tempting to code your application as you would on a 100 MB backbone. This would work fine on an intranet application, but on a public web site it could cause bottlenecks.
- Making use of module level global objects makes them global to all sessions running on the server (I found this out the hard way). This might be desirable behavior in an online gaming environment where each person who logs in might join an online member list, but ignorance of it can lead to unexpected results.
- It can be tempting to implement applications before you have fully tested them, since the environment is so easy to work in and fast to develop with.
Best practice checklist:
- Understand Visual WebGui technology via its online resources.
- Code your data transport layer according to the speed of the backbone that your application will run on.
- Avoid overuse of event-sinks, since all the event processing takes place on the server (there are exceptions to this, but this is the default behavior).
- Use a fairly simple set of controls to construct the site, since ours is a public site and many web users have never interacted with many WinForms controls.
Three must-ask questions:
- Are transparent screen refreshes important to your users?
- Is impenetrable security important?
- Is rapid and simple deployment of the application a requirement?
Hindsight is 20/20:
I wish I had studied the memory model and the event model better before diving into the coding.
- While I started using this product when it was in beta form, I actually deployed my site with their beta-level code. I consider the product to be out of beta mode, and I am happy I stuck with the implementation of Visual WebGui. Here are some additional points to consider however:
- If you have an existing WinForms application that runs on a local area network, and you would like to deploy it in a browser, this should be your only choice of platform. If you make extensive use of third party controls, and the control publisher has an ASP.NET implementation, VWG has a "wrapper" facility so you can continue to use the third party controls in exactly the same way you would use them in the WinForms environment.
- If you have an existing ASP.NET or HTML web application, you must consider your user base and the differences between the WinForms style controls and the way classical web pages behave. While the screen refreshes of VWG are vastly superior to anything in the HTML/DHTML world, if your users are already well trained in your old application, be aware of their learning curve especially if you have a large user base.
The ideas expressed in this article are solely those of the vendor and its client, and do not necessarily reflect the opinions of ITworld.