Call with custom Feature Specification component

On the GSP platform, components play an important role in making the platform more flexible and user needs more changeable ,. net method call, user-defined form display, and so on are the most common application scenarios. However, due to our weak component platform capabilities, the component platform has long been used as a universal reflection caller. Standardizing components is the only way to develop the component platform. This articleArticleOnly from the perspective of using custom features to enhance the degree of standardization of components.

From my perspectiveProgramThe auxiliary information added to the set, type, method, attribute, and other elements can tell the caller what to do before the call, what to do after the call, or what to let the compiler do. We often use existing features in the. NET Framework, but there are few scenarios for custom features.

Below I will describe two problems in the use of components and explain how to use features to solve them:

1. on the workflow's manual activity node, You need to define a document as a data reference for manual execution. Here we need to input some parameters (permissions, fetch conditions, document classification, etc.). Our component platform describes the form as a component, and the description contains information about how to call this form. However, there are slight restrictions in implementation. For a web form, the URL followed by a parameter can be well implemented. For a winform form, a constructor that matches the parameter must be required. However, many document authors prefer to implement these parameters as attributes rather than parameters in constructors. In this case, apart from the strong identification of the form parameter name and the same as the form attribute, there is no good way.

2. In a similar situation as in 1, we define the real parameters for these component parameters. Generally, the fields in the schema of the document data are used, but this process also leaves our end users confused, unless we agree that the parameter name must match the field in the schema, this problem cannot be solved.

The above two problems can be solved in a more elegant way by using custom features. We designed the following features:

[Attributeusage (attributetargets. Property, allowmultiple = false, inherited = false)]
Class gspparamsattribute: attribute
{
Private string paramname;

Public String paramname
{
Get {return paramname ;}
Set {paramname = value ;}
}

Private string actualparamname;

Public String actualparamname
{
Get {return actualparamname ;}
Set {actualparamname = value ;}
}

Private string actualparampath;

Public String actualparampath
{
Get {return actualparampath ;}
Set {actualparampath = value ;}
}
}

[Attributeusage (attributetargets. Class)]
Class gspsupportparamspecifyattribute: attribute
{
}

You can mark the document as follows:

[Gspsupportparamspecify ()]
Class myform: Form
{
Private string someproperty;

[Gspparams (paramname = "someproperty", actualparamname = "otherproperty")]
Public String somproperty
{
Get {return someproperty ;}
Set {someproperty = value ;}
}
}

For our component designer, we found a property somproperty that needs to be used as a parameter on the GSP platform. For process design, When referencing this component parameter, you will find that you need to find the otherproperty field in the schema to configure this parameter as a real parameter. When you find the gspsuppparamparamspecify feature during running of component calls, you will know that some attributes of this type need to be assigned values, then the gspparams feature is found in the somproperty attribute, and you will know which parameter is used to assign a value to this attribute.

Reflection is required for features found. The type provides enough information for us. Using Multiple overloading of attribute. getcustomattribute () makes it easier for us to use multiple scenarios.