|
|
Web Parts offer more than the opportunity to add or to delete content. You can give your users the option to edit several properties of the used Web Part. As already described briefly at the beginning of this chapter, you'll get good support from a third zone type, the EditorZone, and four editor controls to do this job. Like the CatalogZone, the EditorZone will only be shown if the corresponding mode is activated. In this case, DisplayMode must be set to Edit, which could be considered the big brother of Design.
| Tip |
Due to the fact that the Edit setting of DisplayMode offers the same possibilities as Design and more, you should normally decide to use either one or the other mode depending on how many rights you want to give to your users for personalization. On the other hand, you can make the mode dependent on the roles the current user belongs to. |
I've enhanced the example again. Now it has a third table column, which contains the new EditorZone. I've stored all four existing editors therein: AppearanceEditorPart, BehaviorEditorPart, LayoutEditorPart, and PropertyGridEditorPart. Additionally, I've changed the event handling of the Personalize link buttons so that the page switches to editing mode with a button click.
void LB_Personalize_Click(object sender, System.EventArgs e)
{
WebPartManager manager = (this.Items[typeof(WebPartManager)]
as WebPartManager);
if (manager.DisplayMode == WebPartDisplayMode.Normal)
{
manager.SetDisplayMode(WebPartDisplayMode.Edit);
this.LB_Personalize.Text = "End Personalization";
}
...
If you open the page and activate personalization with the already existing link, the page will appear to be unchanged at first. But there is a small difference, however: an additional link (verb) named "Edit" is shown in the title bar of each Web Part. With a click, you'll see the newly inserted zone with the different editors as shown in Figure 8-10. You can change the existing properties as you like and save them by clicking OK or Apply. Here again, I'm talking about verbs, which you obviously can adapt and localize if necessary. The insertion of new verbs, however, isn't implemented.
Figure 8-10 shows the possibilities of three editor parts that fulfill different purposes according to their names. What you can't see is the PropertyGridEditorPart control. I'll talk about this later in the chapter in the "Custom Web Parts" section.
It's imaginable that certain editing possibilities should only be allowed for exclusive user groups such as administrators. This could be the case with the BehaviorEditorPart control. It would be ideal to have role support equivalent to the Web Parts themselves. The latter has not been implemented yet, so you're facing some work ahead:
void EditorZone1_PreRender(object sender, System.EventArgs e)
{
EditorPart editor = (EditorPart)
((Control)sender).FindControl("BehaviorEditorPart1");
if (editor != null)
{
editor.Visible = this.User.IsInRole("Admins");
}
}
Two different approaches allow you to implement individual options for editing. First, you can use the PropertyGridEditorPart control to let users edit specially marked properties and store them within their personal page profiles. I'll show you how it works when I talk about the development of custom Web Parts in the next section of this chapter.
The second option to allow individual handling is creating a new EditorPart control that you integrate into the template of the EditorZone. The implementation is quite simple. Just derive the control from the abstract base class EditorPart, integrate the input elements, and implement the ApplyChanges and SyncChanges methods to store or to synchronize changes. You'll gain access to the selected Web Part through the property WebPartToEdit.
This approach will only be necessary if you need a large degree of control over what the EditorPart does. Many editing possibilities can be handled with the PropertyGridEditorPart control as well.
|
|