Go to ASP. NET 2.0: Use user controls and custom web components to personalize your portal.

ASP. net2.0: Use user controls and custom web components to personalize your portal Original: Ted Pattison, Fritz onion Translation: Wang Yong OriginalCodeDownload: webparts.exe (619kb) Source: ASP. NET 2.0 personalize your portal with user controls and custom web parts This article is based on the pre-release version of ASP. NET 2.0. All information provided in this article may change in the future. This article will discuss the following: Use Web components to create modular web portal applications; Personalized and custom features; Use Custom User Controls as Web components; Provide personalized featuresProgram; Portal applications are very popular today, and good portals share common and notable features. That is, it will provide visitors with elegant information, and this information is provided through a modular, consistent, and easy-to-browse user interface. Some comprehensive portals go further and even allow website Members to provide content, upload documents, and personalize portal pages. Microsoft added a scalable portal application framework for the Windows Server 2003 platform, and then released a Windows SharePoint service, which provides some basic elements necessary for the portal application framework, this includes support for site members, content and document management, and modular presentation of data using Web components. Web parts provide basic features that support custom and personalized features. In the Windows SharePoint service website, portal application users can add, configure, and delete Web parts so that they can easily personalize or customize pages. Websites based on Windows SharePoint service also provide a simple and powerful method to expand the site, that is, developing custom web components. When creating a Web part that supports custom and personalized features, you just need to add some attributes and set several special labels in your web part class. The tedious and complex work is done by the Web component infrastructure of the Windows SharePoint service, such as serialization, storage, and reading of data related to site custom and member personalization features. ASP. NET 2.0 introduces a set of Web component controls, which are similar to the functions provided by the Windows SharePoint service, they are designed to complete serialization, storage, and reading of data related to site custom features and member personalization features. However, they are more unique and flexible, and they are not tightly coupled with SQL Server or Active Directory. This is undoubtedly good news for companies that want to use form-based verification technology to create a portal or do not want to be limited by a specific database solution.   Figure 1: A sample portal application designed with modular Web Components This article will show you how to use ASP. NET 2.0 web parts development example portal application, the main purpose of which is to let you understand the portal application development web parts, you will face some important design issues. First, we will introduce some basic concepts and control types involved in the new ASP. NET 2.0 web part control set. For example, see Figure 1. Web parts Basics Pages used to place Web parts are called Web parts pages. 2. A Web Part Page requires a webpartmanager control (only one) and one or more webpartzone controls. You can also include an editorzone control or catalogzone control (not required ). Note that. in the aspx file, the labels of the webpartmanager control must appear before any other control labels related to the Web Part infrastructure, such as the webpartzone control, editorzone control, and catalogzone control. To better control the layout and presentation of Web Part pages, you can also use HTML tables in the aspx file to layout different zone controls in different places. Figure 2: typical layout of a Web Part Page Let's take a look at a simple Web Part Page example, which contains the webpartmanager control and webpartzone control: <Asp: webpartmanager id = "webpartmanager1" runat = "server"/> <asp: webpartzone id = "webpartzone1" runat = "server" headertext = "Zone 1"> <zonetemplate> <! -- Time to add a Web part --> </zonetemplate> </ASP: webpartzone> After a webpartzone control is placed on the page, you can use the Web part definition to create a Web Part instance. There are two different ways to create a Web part definition. The first method is to create a class inherited from the webpart class, and the second method is to create a user control. Later in this article, we will discuss in detail the differences between the two methods. Now, create a simple class inherited from the webpart class (see figure 3 ). Each Web Part instance is located on an index location of a specific webpartzone control on a page. A webpartzone control can contain multiple Web components. 4. The webpartzone1 control contains two Web Part instances. Figure 4: Web Components in a specific zone control You can add Web components to a zone by programming and declaring them. Later, you can see how to add Web parts to the parts directory. After creating a catalogpart control, you can add a new Web part to the webpartzone control at runtime. The method for adding a Web part to the webpartzone control programmatically depends on the type of the Web part to be added. If it is a class inherited from webpart, you must create an instance of this class programmatically and then call the addwebpart method of the webpartmanager class. When calling the addwebpart method, you need to input the following parameters: the Web Part instance, the target webpartzone control, and the index position of the Web Part in the webpartzone control. The Code is as follows: // Create Web Part instance from webpart-derived classwebpart WP1 = new wingtipwebparts. helloworld (); webpartmanager1.addwebpart (WP1, webpartzone1, 0 ); This allows you to add Web parts to webpartzone programmatically. The declaration method is to define the control label in the. aspx file on the Web parts page. When a user accesses a page, if you want a Web part to appear in a specific webpartzone control, you can add a zonetemplate to the webpartzone control. The Code is as follows: <% @ Register Assembly = "wingtipwebparts" namespace = "wingtipwebparts" tagprefix = "wingtip" %> <asp: webpartmanager id = "webpartmanager1" runat = "server"/> <asp: webpartzone id = "webpartzone1" runat = "server" headertext = "Zone 1"> <zonetemplate> <wingtip: helloworld runat = "server" id = "helloworld"/> </zonetemplate> </ASP: webpartzone> Don't forget to "Dress up" the Web parts, because if not, your web parts will look boring. A common feature required by inline portal applications is to "skin over" the site and change the appearance of Web Components Based on the visitor's preferences. In the past, this meant you had to create your own architecture to support the function of changing the display mode of controls, which required a lot of work. ASP. NET 2.0 introduces the concept of "theme", which includes a series of style attributes and control attributes. These attributes can be applied to a single control, the entire page, or even the global scope of the entire application. To make your portal application look elegant and professional, you need to customize the appearance of all webpartzone controls, editorzone controls, and catalogzone controls. When you first do this, you will feel this kind of work is very boring. Because you need to skin and modify the display attributes for the content area, title bar, and dynamic menu of the Web parts, Editor parts, and catelog parts. Fortunately, the new ASP. NET 2.0 topic features can extract the results of this. aspxfile interface work into reusable. Skin and. CSS files. This articleArticleThe sample portal application uses the skin replacement and theme functions to customize the appearance of Web parts. You can download the sample from the msdn magazine website. Display Mode and page range A single instance of the webpartmanager control runs on each Web Part Page. It manages the Web Part instance and how the Web part interacts with the webpartzone control. The webpartmanager control also provides a programmable interface to switch the display mode of Web Part pages. For example, you can switch between the following three modes: browsing mode, design mode, and editing mode. For example, to switch the current page to the design mode through a program, you only need to add a link control and set the displaymode attribute to designdisplaymode In the event processing program of this control. The Code is as follows: Webpartmanager1.displaymode = webpartmanager. designdisplaymode; It is important to understand the differences between different display modes of Web parts pages. By default, the Web parts page is in browsing mode, which does not allow users to modify any Web parts. When you switch to the design mode, you can move Web Components inside webpartzone or between different zones. Figure 5 lists all the display modes. ASP. NET 2.0 Web Part Control generates all necessary DHTML and JavaScript code in the background, allowing users to drag and drop operations in the browser. All other editing functions except drag-and-drop operations can be used in browsers that do not support required DHTML and JavaScript features. This means that you do not have to worry about forcing all customers to use Microsoft ie5.0 or later browsers. The ASP. NET 2.0 web parts control also allows you to manage the storage and acquisition of personalized data, so that you can remember where your Web parts were last placed. In addition to code switching to display mode, the webpartmanager control also provides a method to allow switching between user range and shared range on Web Part pages. The page scope refers to whether to modify a Web part for custom operations or personalized operations. All users can see the results of custom operations, and only users can see the results of personalized operations. You can change the scope of a Web Part Page by calling the togglescope method of the webpartmanager control. The Code is as follows: Webpartmanager1.personalization. togglescope (); The default range is the user range. That is to say, modifications to Web components are recorded as personal operations and can only be viewed by the current user. Successfully calling the togglescope method will change the Web parts page to the shared scope. In this way, modifications to the Web parts will be recorded as custom operations. The purpose of the shared scope is to allow administrators or site designers to uniformly modify Web controls on the Web parts page so that all users can see this change. If there is a conflict, personalized modification always takes precedence over global custom operations. The current user does not always successfully enter the sharing scope. By default, no user has such permissions. This permission is only granted to users in the web. config file. The following is an example. It allows all users with the admin or site_designer role to enter the sharing scope and modify the global custom data: <Webparts> <personalization> <authorization> <allow roles = "Admin, site_designer" verbs = "entersharedscope"/> </authorization> </personalization> </webparts> Attributes and personalization Each web part object has a set of standard attributes that can be customized or customized. For example, each Web part has a title attribute that can be customized after being added to webpartzone. The editorzone control and some editor components allow users to modify web part attributes. When a user switches the Web Part page to the editing mode, the Web Part Menu provides an editing command. An editorzone control is displayed when you call the edit command on a Web Part. This control is placed in the relevant Zone Control. ASP. NET 2.0 provides some built-in editor components to modify the appearance, behavior, and layout of standard Web components. By adding custom properties that can be personalized, Web parts personalized configuration data can be easily expanded. You only need to add these attributes in the definition of the Web Part class and add feature labels such as personalizable, webbrowsable, and webdisplayname. After you complete this, the Web Part Control will help you store and obtain these personalized or custom attribute values. When you create a personalized attribute, a private field is usually defined at the same time. The Code is as follows: Private bool _ hR = true; [Personalizable (personalizationscope. User), webbrowsable, webdisplayname ("show HR News"), webdescription ("use this property to show/hide HR News")] Public bool HR {get {return _ hr;} set {_ hR = value ;}} If you want to allow your users to personalize a property like this, you only need to add a propertygrideditorpart in the editorzone control of the current page. Figure 6 shows what the user will see when you do this: Figure 6 editor parts allow users to personalize Web parts If you define a Web Part property as a string or number, the propertygrideditorpart provides a text box for users to modify the property value. If this attribute is Boolean, The propertygrideditorpart provides a check box, as shown in figure 6. Figure 7 shows an excellent programming technique learned from Web component development of the Windows SharePoint service: You can define a personalized Attribute Based on enumeration type. The real value of creating webbrowsable and enumeration-based Personalized attributes is that the propertygrideditorpart generates a drop-down list containing all optional attribute values, as shown in the timeframe attribute in 7. This is convenient for the user and helps ensure that the user selects a valid attribute value. There is one more thing worth noting about the timeframe attribute. It is added with the personalizable feature, whose value is personalizationscople. shared. When an attribute is defined as a shared property like this, it can only be customized but not personalized. Since the shared property cannot be personalized, The propertygrideditorpart will not display this property when the current page is in the user range, but will only display this property in the shared range. Web parts directory We have seen how to add Web parts in advance in the webpartzones control. You can also use another method to complete this function, that is, to allow users to add new Web Components at runtime. You can use the catalogzone control and catalogparts components, such as pagecatalogpart and declarativecatalogpart. (See figure 8) After you use this method to add a catalogzone and catalogpart, You can dynamically add Web parts at runtime, as shown in figure 9. Figure 9: catalogzones allows users to dynamically add Web parts First, you need to understand the purpose of pagecatalogpart. In the design display mode or edit display mode, you can call the "close" command of the Web part. When a user closes a Web part, the Web part and the corresponding personalization or custom configuration are retained so that the user can add the Web part again later. Therefore, the pagecatalogpart control displays a list Of all closed Web parts. You can add them to the page again. The "close" command is different from the "delete" command. The "delete" command appears in edit display mode. When a user deletes a Web part, all relevant information about the part, including custom and personalized data, will be deleted. The declarativecatalogpart can be declared to add a Web part. The code in Figure 8 illustrates how to define this directory, where weatherwebpart, which uses a custom name, is used. With this method, you can provide users with a variety of Web components. As a supplement to this article, we recommend that you read "Introducing the ASP. NET 2.0 web parts framework. This section provides more detailed information and a complete example of using editorzones and catalogzones to create a web control page. Stephen also talked about more advanced topics, including verbs, connections, and Web component import and export. ASP. NET 2.0 portal application development In addition to the architecture of Web Components, some new features in ASP. NET 2.0 make the development of internal portals more attractive. As mentioned earlier in the article, the introduction of theme and skin replacement allows style attributes to be conveniently and directly independent from portal pages. You can make a unified style change without having to modify each page. Of course, what is even more exciting is the introduction of master pages. With the master page, you can place the overall webpartmanager control and all webpartzones controls on a separate template page. Other pages can inherit these basic appearances and functions. In the example portal application, an interesting technique we use is to add a contentplaceholder control to the zonetemplate template of each webpartzone control on the master page. In this way, you can use this content control to add your own web components on the content page of this master page and map them to the corresponding contentplaceholder control. One thing you must consider when designing a master page for a portal website is to provide users with custom features. As you can see, based on the different types of zone controls contained in the page, there are several different ways to modify the custom mode of the page for users to choose from. One way to display custom options to users is to encapsulate the webpartmanager control and a series of buttons (typically linkbutton) into a user control, and then place the control in the master page, you can provide custom options for all pages on the website. If your website has more than one master page to provide different la s for different pages, encapsulating it as a user control (we can call it webpartmanagerpanel) is also very useful. The menu bar of the portal application shown in Figure 1 provides an example user control to display the display mode and range of the current webpartmanager, some linkbuttons are also provided to change the page to one of the editing modes supported by the webpartmanager control. (This is the user control used by the sample portal application ). Another useful feature in your webpartmanagerpanel control is to display or hide corresponding display mode menu items based on the current user and the current page. You can view the supported display modes in the supporteddisplaymodes collection attribute of webpartmanager to display or hide the corresponding display mode menu items. For example, to check whether the current page supports catalogdisplaymode, you should write the following code: If (webpartmanager1.supporteddisplaymodes. Contains (webpartmanager. catalogdisplaymode) {// enable catalog display mode linkbutton here ...} It should also be noted that if the current user does not have the corresponding permissions, calling togglescope will fail. Therefore, it is a good idea to use code to determine whether to display or hide the interface elements that allow users to enter the shared scope. You can query the canentersharedscope attribute of the personalization attribute of the webpartmanager control to achieve this. The Code is as follows: If (webpartmanager1.personalization. canentersharedscope) {// display UI element that allows user to enter shared scope} The webpartmanagerpanel user control in the example application included in this article contains a complete implementation, which can dynamically adjust the display of the pane based on the current user and the current page capabilities. Use user controls as Web Components when using the Windows SharePoint service to create Web components, the most frustrating thing is that you must use code to create the entire control interface, the designer cannot help. Because many web components are composed of a series of interactive server-side controls, it is unfortunate that you cannot use the Visual Studio designer when creating web components. An obvious solution is to allow developers to create user controls and use them as Web components. (A third-party tool named smartpart provides the ability to use user controls as Web Components in the Windows SharePoint service ). ASP. NET 2.0 web components solve this problem. It allows any controls to be used directly as Web components without modifying or packaging them. This not only combines user controls into the Web parts set, but also easily integrates the custom controls used in the existing Asp.net page. the internal working principle of this method is that if a standard control (not a Web Part) is added to the webpartzone control, the system will implicitly call webpartmanager. createwebpart method. This method creates an instance of the genericwebpart class and initializes the instance with the added control. Genericwebpart inherits from the base class webpart and provides the core Web Part attribute implementation. When building the genericwebpart control, it adds the initialized control as a child control. In the page rendering process, like most composite controls, genericwebpart itself does not output any content in the response cache, but serves as a proxy for outputting the sub-control content. The final result is that you can add any control to the webpartzone control on the page without worrying that it will not run. For example, the following page defines a webpartzone control, which includes a user control and a standard calendar control, both controls are implicitly packaged into a genericwebpart control. The Code is as follows: <% @ Register src = "webparts/customerlist. ascx "tagname =" customerlist "tagprefix =" wingtip "%> <asp: webpartmanager id =" webpartmanager1 "runat =" server "/> <asp: webpartzone id = "webpartzone1" runat = "server" headertext = "Zone 1"> <zonetemplate> <wingtip: customerlist runat = "server" id = "customerlist"/> <asp: calendar runat = "server" id = "customercalendar"/> </zonetemplate> </ASP: webpartzone> Like standard Web components, it is also possible to dynamically create controls encapsulated by genericwebpart. For a user control, you must first call page. loadcontrol to dynamically load and create a user control instance. Second, you must explicitly set a unique ID for this control. In addition, you must call the createwebpart method of the webpartmanager object to create a genericwebpart class instance to encapsulate the user control instance. Finally, pass the reference of the obtained genericwebpart instance as a parameter to the addwebpart method and specify the webpartzone to be added. The Code is as follows: // Create Web Part instance from user control filecontrol UC = This. loadcontrol (@ "webparts \ companynews. ascx "); UC. id = "WP2"; genericwebpart WP2 = webpartmanager1.createwebpart (UC); webpartmanager1.addwebpart (WP2, webpartzone1, 1 ); The only drawback of this technology is that you cannot control some special features of Web parts, because your control is not inherited from the webpart class, and only genericwebpart is inherited from the webpart class. Once you run a page containing controls encapsulated by genericwebpart, you will immediately find a phenomenon that most Web components are not expected to be untitled by default, there are no related icons and descriptions. Figure 10 shows a sample user control wrapped by the genericewebpart control with a default title (no title) and a graph. Figure 10 genericwebpart One solution is to add an init event processing routine in your user control. If your control is encapsulated by genericwebpart (the type of the parent attribute can be determined by querying), you should set some attributes of the genericwebpart class in the program. The Code is as follows: Void page_init (Object SRC, eventargs e) {genericwebpart GWP = parent as genericwebpart; If (GWP! = NULL) {GWP. Title = "My Custom User control"; GWP. titleiconimageurl = @"~ \ IMG \ allusr. GIF "; GWP. catalogiconimageurl = @"~ \ IMG \ allusr. GIF ";}} When you run this page again, once the user control is encapsulated by genericwebpart, modifications to the attributes of the genericewebpart parent control are reflected on the Web Components that contain your control. Figure 11 shows a new property-based user control. Note the title and icon. Figure 11 Title and icon Another more attractive solution is to implement the iwebpart interface directly in your user control class. Since the user control never directly queries the properties of Web parts, because the information is processed by the genericwebpart class, it seems that it is useless at the beginning. Fortunately, the designers of the genericwebpart class are aware of this requirement. If the control implements the iwebpart interface, the property in the genericewebpart class will be automatically delegated to the encapsulated control. Therefore, customizing the Web part feature of a user control is only to implement the iwebpart interface and fill in the seven attributes defined in the interface. The code in Figure 12 provides an example of the background code class of the user control, implementing the same result as the previous dynamic modification of the genericwebpart attribute. You may also consider creating another base class for your user control. This base class inherits from usercontrol and implements the iwebpart interface, then it can be inherited by all the user controls in your portal application. This is what we did in the example application of this article. In this way, your user controls can initialize the required attributes in their constructor, and others are controlled by the base class. Figure 13 shows a user control base class implementing the iwebpart interface and a code corresponding to the background class. The user control uses this base class to set the title and icon attributes. Now that you have the flexibility to create user controls, you may ask: When you have user controls supported by the designer, you can also customize Web part features, why do we need to create custom controls? In fact, you need to do this for several reasons. One of the reasons is that you cannot add a defined action (verbs) to the user control ). To do this, you must directly inherit from the webpart and then rewrite the verbs attribute. Of course, you can also consider implementing the iwebeditable interface in your control. Another reason is that the user control is limited to the application directory unless you. the ascx file is copied from one project to the directory of another project. Otherwise, you cannot share the user control in multiple web applications. On the other hand, the custom Web Part class inherits from the webpart class and can be compiled into a reusable DLL and deployed to the Global Assembly Cache (GAC ). Another point is that by customizing the Web parts class, you can also write a custom designer for your controls to change the default appearance in Visual Studio, you can also create an icon when this Web Part class is placed in the toolbox. Figure 14 provides a feature comparison table that allows you to choose whether to customize Web components or user controls. Web parts and personalized feature provider programs The Provider Program is ASP. A new feature of NET 2.0, this is also one of the main reasons why you can see that so many built-in functions and complete controls can run with little or no code. The basic idea behind the Provider Program is to define a set of common data-related tasks for a specific feature and aggregate those tasks into an abstract class declaration, this abstract class inherits from the common providerbase class. In the personalization features discussed in this article, the data-related tasks that must be clearly provided include: Saves the attributes and layout of Web parts for a specific page or user; Loading the attributes and layout of Web parts for a specific page and user; Saves General Web Part attributes and specific page la S (for general customization ); Load General Web Part attributes and specific page la S (for general customization ); Resets the attributes and layout of a specific page and user's Web parts to their default values; Resets the Web Part attributes and layout of a specific page to its default value (for general customization ); Some other features that are affiliated with the personalized architecture also require the capability of persistent storage, but they can basically be attributed to the above six requirements. If we assume that a class can complete these six actions and successfully save and restore data, when the site is running, the webpartmanager control on each page can use that class to save and restore all personalized and custom data. The abstract class defining these methods is called the personalizationprovider class. By default, a specific derived class is used as the sqlpersonalizationprovider class. Figure 15 shows the three methods that represent the six features we have defined. Note that, whether or not the entered username parameter is null, each method can personalize or share user-defined data. All personal data is saved as normal binary data (byte []). The default sqlpersonalizationprovider class will write the data into an image field in the database. Since ASP. NET 2.0 knows that a class can provide these methods, it can create more logic in the basic control set than before. In our case, the webpartmanager class on each page that uses Web parts is responsible for correctly calling the current personalizationprovider class to serialize and restore personalized settings for each page. Figure16The editorzone control interacts with the default sqlpersonalizationprovider class. Figure 16 Interaction The more you use ASP. NET 2.0, the more you will know about the provider architecture. For example, there are many providers, such as member providers, role management providers, site map providers, and site monitoring providers. All provider programs define a similar core method set for interaction with controls. Modify personalized data storage Like most provider programs in ASP. NET 2.0, the default personalized provider program is implemented for SQL Server background storage. If the configuration file is not modified, the default sqlpersonalizationprovider uses the SQL Server 2005 express edition connection string and supports local file-based databases. The connection string is like the following: Data Source =. \ sqlexpress; Integrated Security = sspi; attachdbfilename = | datadirectory | aspnetdb. MDF; user instance = true one advantage of using the SQL Server 2005 express edition file-based database is that it can be dynamically created without any additional settings. This means that you can build a new site and enable personalized features without setting up databases! When you first interact with the website, the system will generate a new aspnetdb in the app_data directory of the site. MDF file, and initialize the database with tables and stored procedures that support all default provider programs. This is great for small sites that do not need to scale up or support many concurrent users. However, for enterprise systems, data must be stored on a fully managed and dedicated database server. Fortunately, it is very simple and straightforward to modify the database used by sqlpersonalizationprovider. The sqlpersonalizationprovider configuration initializes the connection string to localsqlserver, which means that it will find the configuration item named localsqlserver in the section of the configuration file, use the relevant connection string to open the connection to the database. By default, this string is what you see above, meaning it will write a local SQL Server 2005 express edition. MDF file. To modify it, you must first clear the localsqlserver connection string set and reset a new connection string value in your web. config file. (Or you can modify the machine in the machine range. config file to affect all the sites on this machine) The following is a web. config File example, which modifies the provider Database Value to point to a local SQL Server 2000 instance: <Configuration xmlns = "http://schemas.microsoft.com/.NetConfiguration/ v.2.0"> <connectionstrings> <clear/> <Add name = "localsqlserver" connectionstring = "Server = .; integrated Security = sspi; database = aspnetdb "/> </connectionstrings>... </configuration> Before the modification takes effect, the local SQL server must have a database named aspnetdb, which contains the tables and stored procedures required by sqlpersonalizationprovider. With ASP. NET 2.0, a tool named aspnet_regsql.exe is released, which can be used to create this database. When you run the program with the default settings, it will create a local database named aspnetdb, which has all the tables and stored procedures required by the provider program, alternatively, you can install these tables and stored procedures into an existing database. The names of all tables and stored procedures start with "ASPnet", so they are unlikely to be repeated with any existing tables. And all ASP. like the Provider Program of NET 2.0, this indirect mode provides a very flexible architecture that allows you to completely replace the backend data storage without modifying any page or Web components. Create your own personalized Provider Program It gives you a certain degree of flexibility to modify the connection string for the personalized Provider Program. However, the sqlpersonalizationprovider still uses the namespace system. Data. SQL. Client function to access data. This means that you must use the sqlserver database. If you need to save personal data to another database, or it may be another completely different data storage, you will have to go further, create your own personalized data provider. Fortunately, most difficult jobs are ready for you and easy to use. As an example of storing personalized data to another type of data storage, the example portal website in this article has a complete implementation of a custom provider program named filebasedpersonalizationprovider class, it saves all personal and custom data to a local binary file under the app_data directory of the application. The name of the binary file is generated by each user and path, and each path has a unique and common user configuration file. To create a custom personalized data provider, you must first create a new class inherited from the personalizationprovider base class, and then override all the abstract methods inherited from the base class. The class definition shown in Figure 17 demonstrates how to do this. To make your provider program operational, there are only two important methods that must be implemented: loadpersonalizationblobs and savepersonalizationblob. These two methods complete the binary serialization of personalized data. When a page is loaded, the personalized architecture calls them. When the Web Part Page is in editing, directory, or design mode, if the data is modified, the personalized architecture also calls them to write the data back. (Typically, it is based on a specific user ). In the sample code downloaded, the implementation code of savepersonalizationblob writes the datablob parameter to a file based on the input user name and unique path name. Similarly, the loadpersonalizationblobs implementation code searches for this file (using the same naming method) and returns a user-defined or shared BLOB data. If the input username parameter is null, both methods will save or load shared data by default. If it is not null, user personalized data will be saved or loaded. Figure 18 shows the implementation code of the two methods in the example filebasedpersonalizationprovider, and a pair of helper methods used to generate a unique file name based on the user name and path information. Once the Provider Program is fully implemented, you can register it as a provider program through the provider section in the personalized configuration section. To actually use it, you must define it as the default personalized provider in the web. config file. The following is an example of using our custom file-based Provider Program as the default provider: <Webparts> <personalization defaultprovider = "filebasedpersonalizationprovider"> <providers> <Add name = "filebasedpersonalizationprovider" type = "wingtip. providers. filebasedpersonalizationprovider "/> </providers> </personalization> </webparts> If we re-run our website, all personal data will now be stored in a local binary file. Obviously this is not the best solution, but the sample code provides some ideas to let you know how to implement your own personalized provider, no matter what type of backend storage you want. Figure 19Shows how our new provider is inserted into the entire Web component architecture. Figure 19Use filebasedpersonalizationprovider Further steps So far, you have seen that if ASP.. NET 2.0 and its new Web component control to create portal applications with rich features that support customization and personalization, while ASP. NET 2.0 makes this work quite simple. Perhaps the most important feature of this architecture is plug-in capabilities. The provider architecture makes it easier to write personal data that meets the characteristics of your site to the backend data storage, and will not be bound to a specific serialization implementation or data storage. So now let's move forward and use ASP. NET 2.0 web components to create custom sites! If you like this article, there are a lot of things to learn to create Web parts in the ASP. NET 2.0 portal application. Remember to download the sample code from the msdn magazine website. Some examples can be used in ASP. NET 2.0 Quickstart tutorials. We also recommend that you read Fredrik normé n's blog, which contains some interesting examples of ASP. NET 2.0 web components.

Author Profile Ted PattisonHe is a consultant and trainer who provides some easy-to-use training courses through pluralsight, offers consulting services through TED Pattison group, and author of several books. Fritz onionIs a partner of pluralsight. Pluralsight is a company engaged in education and content creation. It focuses on ASP. NET web development, Fritz orEssential ASP. NET(Addison Wesley 2003. At www.pluralsight.com/fritzThe above shows his network records.

This article is translated by vckbase MTT