Code Snippet
1. General Philosophy
Hybrid web parts let you use "modern" ASP.NET web part development techniques and capabilities combined with base Windows SharePoint Services capabilities.
The general design is to, wherever possible, make implementing a hybrid web part operate like a "vanilla" ASP.NET web part.
2. Creating a Hybrid Part
To create a hybrid web part, one derives from
Microsoft.SharePoint.WebPartPages.WebPart.
Usage of certain features will automatically make your web part a Hybrid Web Part:
- ManagedLink
Implements IPersonalizable
- Uses the ASP.NET Personalizable attribute
Also, if your web part does not contain any XML serialization attribute hints, we will consider it a Hyrbid Web Part.
3. Restrictions on a Hybrid Part
Hybrid parts can not:
- Return toolparts via the GetToolParts method. They must use ASP.NET's CreateEditorPart function
Hybrid parts can have:
- Xml serializable properties but they won't be used when we try to persist the Web Part. For that each personalizable property will need an applicable type converter.
Windows SharePoint Services Facilities you can use in a Hybrid Part
- Web Part Caching (e.g., SharePoint based caching methods, like PartCacheWrite/PartCacheRead/PartCacheInvalidate)
- V2 Web part connection interfaces, including client side connection capabilities and cross page connections
- Asynchronous features of web parts (work items)
ToolParts with Hybrid
Toolparts are not automatically injected for Hybrid webparts (this is only done for ASP.NET WebParts to simulate the pure ASP.NET developer experience where there might be toolparts inside the ZoneTemplate on an EditorZone on an ASP.NET page.)
So:
You always call GetToolParts and CreateEditorParts for Hybrid Parts.
You call CreateEditorParts and inject toolparts for ASP.NET parts
