One of the main areas of investment when developing Web Parts is the user interface and the output of (X)HTML code. A Web Part needs to merge transparently into an existing page (Web Part Page or Wiki Page), adhering to the rich and user-friendly layout of the hosting site, which can be a public CMS solution. Nevertheless, the output of the Web Parts can be defined in its CreateChildControls method or, for Visual Web Parts, in the ASCX code of the corresponding visual control. However, you cannot always predict where the Web Part will be hosted; thus, you cannot provide a layout that will be appropriate for
every kind of output.
Of course, you can try to satisfy different layout requirements by just working with Cascading Style Sheets (CSS), but in general, there’s no one-size-fits-all solution. This is an issue that Microsoft had to face when developing SharePoint itself.
Consider how Web Parts such as the SearchCoreResults or the XsltListViewWebPart render their output, to name but a couple of
examples. These native Web Parts accept an XSLT transformation as one of their main parameters and apply that transformation to an XML document that represents the real content of their output.
Often, in real SharePoint solutions that target not only intranet/extranet sites but also public Internet scenarios, you will need to develop custom Web Parts that follow these same basic principles.
This technique is truly powerful because it lets you define a completely custom layout for Web Parts while still sharing common business logic and behavior, but it doesn’t impose any specific constraints about the (X)HTML code to output, so it’s often your best choice in realworld SharePoint Internet solutions.
