What are the advantages to developing a Web application with Web Parts as opposed to more traditional ASP.NET development?
The trend today is towards component-based architecture where developers create discrete, functional components and then add them to existing applications. In the past, developers have created the components through things such as user controls or custom server controls. Web Parts take the component-based design paradigm and add other common functionality, such as drag-drop, and architectural features, such as personalization. The end result is that the amount of code required to create fully-featured, sophisticated, modern Web applications is significantly reduced. What sort of "gotchas" should developers be aware of if they are using Web Parts for the first time?
There are not really "gotchas" as such. My advice to anybody who is planning to build on top of the portal framework is that they take the time to study the various components and layers that exist within the portal framework. This will allow them to familiarize themselves with the points of extensibility that exist within that framework and therefore gain an understanding of what options they have for extending and creating deep customizations within their applications.
When I wrote my book -- ASP.NET 2.0 Web Parts in Action: Building Dynamic Web Portals -- I designed the story to take the user on a very hands-on journey to explore these extensibility points; this is all achieved while developing real world scenarios. A great example of this can be seen when we climb under the hood to modify the default behaviour of zones to provide users with a catalog zone that appears in a pop-up dialog window as opposed to the default behaviour where the catalog zone is displayed inline on the page. This is typical of features that customers will see in other modern portals, such as Sharepoint version 3, and want to emulate in their own applications.
Without a good knowledge of the range of options that exist for making this type of modification, developers might implement their code changes in a kludgey manner. By contrast, the solution that we go through in the book is quite straightforward and relatively elegant in comparison. How does the life cycle of a Web page apply to Web Parts? How does it differ from that of a more static ASP.NET application? How is it the same?
The portal framework adds its own lifecycle on top of the standard lifecycle of the page. Developers can then use the portal lifecycle events to interact with components within the portal at key times. The two most significant events that occur are toward the end of the page's lifecycle, when personalization data for the current page is saved, and near the beginning of the page's lifecycle, when that data is retrieved and reloaded into the page.
Personalization is a very core concept within the portal. Personalization is the thing that allows users to make changes to their pages and to have them "remembered" on subsequent visits to the page. As an example, a user could add a new web part to their page at runtime -- such as a web part that displays weather information. This web part would appear on the page on each subsequent visit to the page by that user until such time as the user chooses to manually remove it.
What happens under the covers is that personalization data containing information about any page modifications is saved and reloaded by the Web Part manager. The Web Part manages uses that data at the key lifecycle times to dynamically adjust the page to reflect the user's settings.
In my book I show the reader what events exist in the portal and explain when they would commonly use them to perform tasks. What options are available for ASP.NET server controls in Web Parts applications?
Developing web parts is no different to developing other reusable controls, as they are developed by simply creating either user controls or custom server controls. The important thing to note is that a Web Part is always a class that is derived from the System.Web.UI.WebParts.WebPart class. This base class adds properties that are common to all web parts -- such as Title, Description, etc. -- and provides other members of the portal framework with a common interface to communicate with. For example, when displaying a Web Part in the editor zone, that zone uses these common properties to fetch and set the information about the Web Part. Are there any additional security concerns with Web Parts development?
The most important security aspect to learn about probably relates to importing and exporting Web Parts. By using this feature, users can export a Web Part and then import it again at some later date. It's a really cool feature because we can leverage it to easily create a plug-in style architecture where applications can be extended at runtime -- thus avoiding large, whole application, re-deployments.
Users just need to be aware that when the Web Part is exported, data relating to personalization changes is stored in clear text within the resulting XML. Thankfully the portal framework provides ways to protect sensitive properties so that their data can be omitted from the import/export process. For example, when exporting a web part that contains user details, it might be wise to omit sensitive information such as Social Security numbers and other confidential data. Can you provide a couple examples of Web sites that make good use of Web Parts? What is it that makes these pages stand out?
Sharepoint is a great example of a portal that uses Web Parts. The latest version of Sharepoint (version 3) is actually built on top of the ASP.NET 2.0 portal framework. So Sharepoint V3 is a heavily customized example of the types of applications that we can use the ASP.NET portal framework to build.
I expect that one of the largest audiences for my book will be developers [who want] custom Web Parts for Sharepoint V3 because those web parts are created with exactly the same System.UI.Web.WebParts.WebPart class that is used in the book.
Other popular sites that use web parts are internet web sites such as Live.com and Pageflakes.com. Throughout my book, when I walk the reader through creating features, is it always done so in reference to cool features that exist on these popular portals because I believe that these are the features that customers will ask for. The concepts behind Web Parts -- the UI, at least -- seem similar to that of Ajax. How does development with Web Parts compare to development with ASP.NET AJAX, both on the server side and on the client side?
Features such as Atlas and Web Parts are examples of how the ASP.NET team are continually focussed on providing us with a richer toolset. High-level abstractions such as these and others such as membership, master pages and Web services provide ASP.NET developers with the ability to rapidly deliver very sophisticated applications. Have you heard about any new and/or improved functionality for Web Parts in ASP.NET 3.0?
One thing that I'd live to see is better support for Ajax behaviours so that things like dragging a Web Part from one zone to another zone no longer requires a full postback of the page -- although I'm not specifically aware of any plans that the ASP.NET team have for implementing such a feature. Is there anything about Web Parts we did not touch upon that you would like to add?
In addition to my book I also have an open source blogging engine called SingleUserBlog that is built using the ASP.NET 2.0 portal framework. This application is a good working example of the types of features and customizations that are discussed throughout the book. You can find the SingleUserBlog open source project on Microsoft's CodePlex website at the following URL: http://www.codeplex.com/SUB.