Understanding Field Controls and Web Parts in SharePoint Server 2007 Publishing Sites

I red a new article which was Published by Andrew Connell
I prepared a small notes on this article....
The CEWP doesn't store version history, it doesn't participate in any publishing approval workflow and it does store absolute URLs rather than relative URLs. Even if you enter a relative URL into the editor, it will be converted to an absolute URL. The rich text editor that the Publishing HTML field type is tied to does not convert relative URLs to absolute URLs.
What are the differences between Web Parts & Field Controls and when to use them?
Field controls differ from Web Parts in two fundamental ways: who has control over the layout and structure of the page, who has control over the content on the page, and where the content is stored.
Web Parts
Beginning with Windows SharePoint Services 3.0 and Office SharePoint Server 2007, the ASP.NET 2.0 Web Part framework manages all of this on behalf of Windows SharePoint Services. This means that Windows SharePoint Services no longer controls which Web Parts are on the page or their locations on the page, and does not manage the content stored in the Web Parts. The content and configuration data for Web Parts, known as personalization data, is stored in the ASP.NET 2.0 personalization data store. In Windows SharePoint Services 3.0 sites, this personalization data store is kept in the SharePoint content database.
It is important to understand how Web Parts work within ASP.NET 2.0 and Windows SharePoint Services 3.0 sites. When a Web Part is added to a page in a SharePoint site, ASP.NET 2.0 inserts a block of XML into the Web Part zone that notifies ASP.NET 2.0 about which Web Part to load and what data to assign to all of the Web Part's public properties. When the page is requested, the ASP.NET 2.0 Web Part framework examines this XML to find the Web Part to load (by assembly and class), loads the control, and sets the values of all the public properties. Finally, the page rendering process renders the Web Part.
This XML data is stored in the ASP.NET 2.0 personalization data store—not with the page itself. This means the personalization data is tied to the page's URL and user context, not to the page or version of the current page (as in a SharePoint Server publishing site).
The advantage to using Web Parts for content is that you can personalize the content on a user-by-user basis if the publishing site has a way to uniquely identify users, such as by requiring a logon.
Field Controls
A field control pulls data (in display mode) from a particular column in a list item and writes back to that column in edit mode. Pages in a Publishing site are stored as items in a list; the Pages list. Because they are in a list, they can leverage all the benefits a list has to provide, but visioning & history is the most important here. When a developer places a field control on a page layout, they have the ultimate control of where it is placed on the page.
Field controls provide developers and designers a higher level of control over content pages than Web Parts do. Content owners can only add and manage content within field controls. They cannot move field controls on the page or override the settings set by developers.
What is the significance?
• Consistent lookand feel (A corporate brand)
• Structured organization of contentand a versioned and/or historical record of the content.
If structure and history is important on your site, you should ONLY consider field controls for your content. If you want to have a more relaxed authoring environment where structure & history isn't important, Web Parts are better.
To summarize: the content in Web Parts is not versioned and there is no history, but the content in field controls is versioned & a history is retained
And My Guru explained how to add Safecontrol entries into Web.config file ….