Hi Michael -
Pipeline Overview
No HTML is sent from the server to the browser. The XSLT is not interpreted on the server.
Instead, VWG uses a much more efficient approach. All the XSLT's themselves are sent to the browser when the app first starts up. Then, when you create a button, for example - the server simply sends a message telling the browser to create a button. The browser will interpret the XSLT on-the-fly & add the HTML to the page. This is how VWG achieves presentation-layer abstraction. The client is responsible for drawing each control, based on the properties of each control. The pipeline is very, very compact. It's also how VWG is so fast.
1.) Server - Control Properties > Attributes
To continue our example, When creating a Button - the Server sends Attributes to the Browser describing the Button. Attributes are equivalent to the Button's Properties. Controls are responsible for serializing their Properties into Attributes. Before the server can tell the browser to create a Button - the server calls RenderAttributes() on the Button control. It is the Button's responsibility to serialize it's Properties on the server into a set of Attributes that will be sent to the browser. These Attributes are then sent as an XML message to the browser. Attributes contain everything the Browser needs to draw the Button.
To see the Attributes for your Control - Simply examine the message being sent from the server to the browser. Gizmox has an integrated debugger, which will show you the XML pipeline messages being sent between the server & client (along with the Attributes being sent for each Control). You can easily turn the Gizmox debugger on in your web.config.
2.) Client - Attributes > XSLT > HTML
Once the Button's Attributes are received by the Browser, the Button's XSLT is interpreted using these Attributes. One thing to note is the ID Attribute, which is used to uniquely identify each Control/Component. After processing, the result of the XSLT is an HTML string. This HTML is then added to the page dynamically & positioned accordingly. To view the HTML that was generated by the XSLT - Download Firebug Lite (for IE) / Firebug for FireFox. You can then inspect the Browser's HTML & Look within the VWG_BodyContent DIV to see the generated HTML for controls on your Form.
--
Custom Controls & MetadataTags
When the Button's Attributes are sent to the Browser - the Attributes must be mapped to the Type of the Control - so VWG knows these Attributes are for a Button. We use the MetadataTag to identify each Type of Control. This MetadataTag is used in all VWG Pipeline messages to identify the Type of Control. So, all Controls need a MetadataTag added to the class, like so: [MetadataTag("YourControlName")].
VWG Controls use shortcuts for these names to conserve bandwidth. For example, instead of sending the string "TextBox" to the Browser, it simply sends "T". If you look at the VWG Source - you will see the MetadataTag on the Textbox is: [MetadataTag(WGTags.TextBox)]. WGTags is simply an enumeration, where WGTags.TextBox = "T". For a Custom Control - Simply replace WGTags in the XSLT with the MetadataTag for your Control (match="WC:YourControlName").
Hope this helps!
Ryan