Foxone---A fast and efficient BS framework--(1)
Foxone---A fast and efficient BS framework--(2)
Foxone---A fast and efficient BS framework--(3)
Foxone---A fast and efficient BS framework--(4)
Foxone---A fast and efficient BS Framework--web control Property Editor
As we all know, there is a WebForm control property editor in VS that automatically reflects the individual properties of the control and the corresponding edit control based on the type of the property, for example:
1. Boolean type, corresponding to the drop-down box, inside the option appears yes and no
2. Enumeration type, corresponding to the drop-down box, the options appear in the enumeration of the individual values
3.string type and int type, all that appears is the input box
For other types of properties except string and value types, the support is not good enough, you need to manually implement your own UITypeEditor, and declare it in attribute way into the property.
If you do not declare the editor for the custom complex type, the result will be the following user property:
Just give a pale input box, no practical meaning, just want to tell you this property I recognized, powerless ...
Obviously I can't get everyone who implements a custom control to implement a uitypeeditor, so I decided to add support for other types based on the VS control property editor, including:
1. All interface types that inherit from the IControl interface;
2. All types that implement the self-icontrol interface and their subclasses;
3. Generic list attribute (ilist<t>), but type T can only be a subclass that implements the IControl or its implementation class;
The effect is this:
The above is the individual properties of the table control, where the properties of string and value types appear in the Table component column, and other types of properties appear in each tab, with interfaces, complex types, and generic list types;
Where, for a generic list type, the editing page appears as follows:
When you click "Add" on this page, the TableColumn type of editing appears.
For custom complex types, the effect is as follows:
For the properties of the interface type, the following edit page appears:
Note that the five alternative data sources are implemented with the Ilistdatasource type, as long as the implementation of a specific interface, no one by one registration will be automatically recognized (of course, the extension is in the new project you later, the project's assembly to register it)
Of course, you can also use a specific attribute to declare that a property requires a specific edit control, or a data source, or whether it appears in the editor.
For example:
For a data table data source, when editing its properties, the table name can be selected directly instead of manually, but the property type is string because:
In the code, I declare this property with Formfieldattribute to use a drop-down box, and the data source that declares the drop-down box with Functiondatasourceattribute is from Alltabledatasource.
In this case, the control property editor is flexible.
For such a design, the implementation of four points is more critical:
1. For reflection recognition of control property types, different editing pages appear for different types;
2. Serialization of controls;
3. The storage of the result after serialization, the association of its parent-child relationship;
4. Anti-serialization of controls;
In the following article, I will continue to narrate these 4 points.
If interested can join the group to Exchange, group number: 581523872
Foxone---A fast and efficient BS Framework--web control Property Editor