Custom Controls - Inheritance
From Visual WebGui Wiki
Contents |
Overview
In this article you will find information on inheritance in Custom Controls, how resources are used in the final version of the control when it is rendered and how you should choose to create a custom style or create your control from scratch as a custom control
Inheritance - Custom style or Custom control
When creating a custom control you have the choice of inheriting from an existing control or creating a brand new one. Rule of thumb is that if you are inheriting from an existing control, you should implement your control as a Custom Style Control, thereby using (inheriting) features from the parent control, those that you do not change.
Remember that you have two types of inheritance to think about here. One is the inheritance of the server side control, which you gain by stating the inheritance in your code-behind code (C# or VB.NET) and then you have to presentation inheritance (the resources, .xslt, .js ...) which you gain by inheriting your server side code from another control and not changing the MetaDataTag in the attributes of that new control.
If you wish, you can of course inherit your server side control from a standard control (like a TextBox), give it a new MetaDataTag which would then make it a brand new control presentation wise, and then create all the resource files your self.
How contents of resource files are used at runtime
When all the embedded resources (.xslt, .js, ...) for all used controls are collected and sent to the client, the contents of all the standard controls are retrieved and then the contents of your resource files are added to that pile before everything is sent to the client. You need to make sure that what you do include in your resource files does not unintionally overwrite anything that is allready brought in with the standard controls.
This is a little different between the resource types, but the principal is the same: Don't overwrite anything that is coming in with the standard control you are inheriting from, unless you actually mean to do so.
If you do follow this rule, then changes that are made in the future to the Visual WebGui framework's standard controls in a new version will be reflected in your application as they should. If you don't follow this, you run the risk of those changes not be reflected, as you did allready overwrite them with you custom control's changes.
A good example of this is the WatermarkTextBox which you can find in the sources (Gizmox.WebGui.Forms.Extended). That control inherits from TextBox, uses Custom Style to signal that it's a WatermarkTextBox and not a standard TextBox and then only includes in the .xslt and .js what is actually being changed by this control.
XSLT resource files
When using .xslt resource in an inherited custom (style) control, you only include the sections that you actually change. There are mainly two types of sections in the .xslt files, templates (somewhat like subroutines) and template matching sections.
You can not include a template section with the same name as the one being brought in with the standard control you are inheriting from. If you do need it, you must change it's name to something else and modify your .xslt code to use that new template. If you don't change the name, two different templates (subroutines) will be included in the combined .xslt and you have no way of knowing which will be used.
As for the template matching lines, you include only those sections you need, and add to the matching filter to match only your custom style that you set for the control. That way you make sure that you are not overriding any of the sections coming in from the standard control.
JS resource files
JavaScript resource follows a very similar rule as the .xslt resource. You only include in the .js file what is actually being changed for your control. If you write new functions, you should name them with the name of your control, followed by an underscore and then the function name. If you need to override functions that are allready in the standard control, you should consider copying them from the standard control, name them with the above conventions and then implement your changes to the new function. If you don't, and you override the function with the same name as in the standard control, keep in mind that your function will override the one in the standard control. Then if you think of having two custom controls in your app, both overriding the standard function, you are bound to have trouble.
