Guy Peled introduces the new Visual WebGui AJAX control and theme designer

The problem:
Visual WebGui provides extreme productivity and simplicity when you are satisfied with the out of the box client side behavior / look and feel, but when you want to customize or “do for yourself” something, than you are facing a different level of development in which you need to be familiar with the internals and how they are bounded together and with that keep track of changes that we here at Gizmox are forced to do in those internals.

 

Customization of the UI as you guys expressed is at the critical path for many applications that have actual customers on the end point. As most customers will require customization of various aspects of the UI, I guess lots of the applications developed with Visual WebGui have taken the decision to use Visual WebGui, while compromising or as Palli expressed it, by letting the customer in on the decision and its aspects.

 

There are several levels of customization and UI needs which vary in terms of the current support that Visual WebGui can provide. I have personally been consulting a few projects, which had done extreme customizations to the Visual WebGui UI, but that currently comes at a cost. 

Visual WebGui presentation layer is the other client half of the application and the server is the first half. The presentation layer is responsible of updating its UI and sending events to the server half. So while the server part is totally customizable in terms of object oriented the actual presentation layer is a set of resources which comprises the presentation layer and needs to be hand coded in a very specific way.

 

The presentation layer resources are separated from the server side implementation and they interact with the server side implementation through metadata which provides a runtime description of the control UI state. The presentation layer raises events to the server, notifying the server on events that occurred on the client. To optimize the communication default values are not sent to the client within the metadata, thus leaving the presentation layer to apply its defaults. That behavior causes a difference between the server state and the client actual state. For example the default control font is Tahoma, 8pt but any presentation layer can define its own defaults but currently there is no mechanism to enable the server side to be notified on this.

 

The previous problem provides limitations on the accuracy of the state and the ability to implement a few scenarios where the client data is crucial for completing the scenario. For example if we need to implement the ListView.GetItemAt(x,y) method it is necessary to know what is the column height, what is the listview item height, what is the actual font which might affect the height also and without this data we cannot implement the GetItem method as we cannot calculate the item at the position.
 

I think I don’t need to elaborate on the business value of customizing the application to be custom tailored to the customer, and until we provide a rock solid solution for this problem, it will be hard to use the platform without compromising. The current adoption definitely shows that it’s appealing to compromise, but until this is solved I personally will not sleep at night… (Literally )

 

The challenges: 

A presentation layer is a set of images, style sheets, templates and etc. which are used to provide implementation for the presentation layer. Furthermore those resources can be categorized for specific browser support, or should I say in a more generic level, presentation engines, which can be for example:  IE/Mozzila/WebKit.  Also there are different roles a resource can play with in an existing presentation layer. It can be part of the basic scripts or it can be a script needed for a specific frame.
 

Every control must declare its resources in compile time so the Visual WebGui server can collect those resources to the client. Currently controls declare their resources using attributes, this causes a limitation, that to add resources one must inherit from a control and add the resources. Furthermore one must embed add the resources in a specific way so the Visual WebGui server will be able to collect them. The embedding of resources is different in VB.NET and provides challenges for someone to write a theme in VB.NET.
 

The presentation layer resources are constantly changing. As someone that is also responsible of architecting in Silverlight, I see that this is a universal problem. We had been updating our XAML files with every major update of Silverlight. I am not providing Silverlight as an excuse, rather than providing a reference to a real problem, which we need to address so you guys will have the ability to customize Visual WebGui without having to rewrite every major Visual WebGui version.
 

The goal of any solution as I see it is to bring back the simplicity of developing web when it comes to custom development. This is the first goal, but as I see it is not the spirit of the platform, as I would expect the ultimate Visual WebGui platform to provide an intuitive easy way that does not involve writing lines of code and that can even look at the designer, as someone that might be glad to participate in the process of customizing the UI.
 

A perfect UI customization solution should provide the following:

 

·         A way to use existing design software such as Photoshop, Expression Blend, Flesh CS and etc.

·         A way to override resources without the need to understand the entire architecture of the platform.

·         A way to customize most of the UI look and feel using parameters which can be inherited and overridden within the control inheritance tree and to override the different UI images.

·         A way to avoid writing lines of code to customize the UI and being mostly driven by point and click / drag and drop interfaces.

·         A way to extend existing customizations and to reuse customizations between projects.

·         A way to customize third party controls as well as internal out of the box controls.

·         A way to create a control from scratch using the same capabilities. 

·         A way to edit multiple presentation layers with the same drag and drop UI.

·         A way to be able to design in runtime or disconnected from Visual Studio and actually needing to compile the project.

 

The solution: 

I have been carrying this challenge with me for quite a time and I have been sketching from time to time different solutions, based on the previous requirements.  We have implemented the basic solution and we are working on providing you guys a preview version of 6.4 which will allow you to try out the concepts. The current post is meant to allow to be prepared for the upcoming change and to influence the solution at a relatively early stage.
 

The first thing that I saw as a necessity is to provide a mediator between the presentation layer and the server side control. I called this mediator the Skin which is a store for skin properties / resources that can be inherited and used both in design-time and in run-time.
 

The Skin is mapped by an attribute, to the control and the control is able to query the Skin object in runtime to get information like the ListView item height (as I said before, this will solve a lot of Visual WebGui issues because for the first time, the server is aware of client side definitions).
 

The Skin class replaces all the different attributes that a control can have and provides all the services needed to retrieve the presentation layer resources. The resources and properties will be stored with in a resx file to enable future editing of external applications or non compile time usage of the skinning mechanism.
 

 

The skin class has a designer which allows adding resources / manipulating existing resources and defining the properties of the resources or the skin.  As you can see from the following figure, we took the basic resource editor UI of Visual Studio and implemented it as a Visual WebGui skin designer. The idea is to provide a familiar UI and to extend it with functionality that will help you get custom controls and themes done quicker.  Every skin can define properties which can be used within the different resources of the control. For example the font is defined in the Skin object and is used by the control resources as a parameter for style sheets or within any other resource.
 

 

As you can see from the following figure various resources can be edited in the control designer and every resource can be configured to specify which presentation layer / engine will the resource apply to and what its role within that presentation layer is.
 

 

Now by providing a way to create skins (using the skin object) and define their resources and properties, we provide a object oriented way to investigate controls and provide a UI for creating full support skinable controls, both internally at Gizmox and externally for third party controls.
 

The next thing I did is to define another designer which provides a full overview of all the controls in the project and with that a storage for overriding the skin resources. The class that implements this store and the overview designer is called Theme.  Theme classes are simple classes that can be added to any project, thus enabling themes within the main project or in a separate library. 
 

As any class Theme can be inherited so you can create reusable themes or extend third party themes. The Theme class also saves its data and resources to a resx file, which provides it the same capabilities as said before.
 

The next figure shows the theme designer which is an extension to the control designer. While the control designer is dedicated for editing resources for a single control, the theme designer is responsible for editing all the controls to create a set of resources that can be applied to change the entire UI. Notice that there is a tree view on the left which provides an overview of the controls and their hierarchy. Evrey referenced assembly which has skinable controls will automaticly add its controls to the tree. The tree provides a visual way to see the inheritance as defining the font in the root level will automaticly populate to the leafs and it goes with our saying that you can override properties and resources in any givven level.
 

 

In the previous figure you can see that the list view skin is edited and you can see all its resources. The little shortcut sign at the side indicates that the resources are not overridden in the theme, which means that this is a link to the actual image. We can right click any resource and override it, which will copy the resource locally and open if for editing and that off course will change the icon to indicate that this resource is overridden.

For example in the following figure we wish to override the style sheets of the listview control, so we simply right click the resource and click override, which will copy the resource locally and open it for editing.
 

 

After clicking the override menu item, we will be able to edit the overridden resource:
 

 

 

This was a basic overview on the theme / control designer which provides you guys with an idea of what we are working on and with the help of the preview version that we will release to get understand what you need to do to migrate to the new version, if you have any customizations of your own over the existing schema. By the way we converted our controls using a macro which we will provide with the preview version so you can do most of the migration work automatically.
 

Visual WebGui will have to go through a process of template standardization which means to split resources in to multiple small editable resources, to add parameterized capabilities where ever possible to provide larger support for point and click theme creation rather actually coding. I guess that ideas from you guys that will be implemented will make the process even easier but as I see it this is the first step for making all of Visual WebGui easier rather than providing a simple abstraction in one aspect and throw you to the dogs in another aspect.

 

View the original Introducing the new control designer and theme designer... blog entry.