Wrox Real World Sharepoint 2010 – Chapter 9

[Chapter 9: Sharepoint 2010 web Part]

Explorer these web part before creating a custom one:
(1) XSL List View (XLV) Web Part
(2) Data View Web Part (DVWP)
(3) Data Form Web Part (DFWP)

web Part:
1. Reusability – reusable
2. Componentization – encapsulate common business functions
3. Interoperability – facilitate cross-webpart and cross-page communications with other web parts
4. Portability – should work on Sharepoint and non-sharepoint (ASP.NET) site.
5. Configurability – can be configured by client.

Web part is derived from System.web.UI.WebControls.WebParts,.Webpart.

Create control declaratively –
<asp:TextBox Text=”….”….>

Create control imperatively: (imperative – using a command)
TextBox t=new Textbox();
t.text=”….”

Web part development:
(1) make a DLL
(2) write some XML
(3) deploy.

*** Sharepoint feature is a bundle of functionality that can be activated in one of 4 scopes: Web, Site Collection, Web Application or Farm. Everything delivered to a Sharepoint farm should be delivered using a WSP. This includes all Sharepoint Features, all files detined for Sharepoint root, all content detined for the configuration or Content Database, all web.config modifications, and so on,

Whenever a new item is added into a Sharepoint Project, VS attempts to auto-update the feature and solution with its best guess as to where that item should be included. Build -> Debug from the menu will sve changes to all project files, compile the imperative logic (if any) into an assembly, validte the declarative logic, generate a WSP, upload to Sharepoint (either Farm’s solution store or site collection’s solution gallery), and by default, activate the features in the solution.

Web Part benchmarks: Each web part must meet the following benchmarks:
(1) compiled
(2) Signed – actually not required for all, but is required for web parts for GAC.  Always sign web PART!!!!
(3) Marked as Safe – a sharepoint app will run a web part only if it is eplicitly identified as SafeControl in the web.config.
(4) Trusted
(5) deployed 

web Part makeup – a minimum of two files make up the web part –
(1) web part definition – come in the form of an assembly
(2) web part template – (*.webpart)

** Page :
(1) File system: ….\_layouts\**** (application pages) [{Sharepointroot}\TEMPLATE\LAYOUTS]
(2) Content database:
      a. Instance pages (system pages), and publishing pages (site pages)
      b. Master page gallery: Master page, payge layouts

What is instance page (system page) – are pages not based on PageLayout. Wiki page; web Part page; Meeting workspace tab page; ASPX/HTML page; /default.aspx; /Lists/Tasks/AllItems.aspx…. Use masterURL to decide which master page to use

*** Publishing pages: Pages always based on a Page Layout. Use CustomMasterURL to decide which master page to use. /Pages/default.aspx; /Pages/Todd.aspx

** Master Page — master pages in Master Page Gallery are used for Content Pages; whereas master pages in _layout are typically for ApplicationPages.

** Page Layouts –They’re  in the master page gallery and are used to define what Content Type (and therefore what site columns) will be positionsed where within the master page.
Application pages:

Web Part Galleries:
web part tempalte is hossted in web part Galleries. web Part templates uploaded to the site collection;s web part galleryy are available anywhere from within the site collection. These web part templates typically get into site collection web Part Gallery using a Module Feature.

web part templates placed in the physical wpcatalog folder just off the root of the web app’s IIS web site will be shown in all pages of all site collections within the web app. These web part templates typically get into web App’s Web Part Gallery using the Dwpfiles element of the Sharepoint solution.

*** Web Part manager. web Part Manager typically is placed on the master page; but Sharepoint uses SPWebPartManager. Job:
(1) maintain an inventory of the controls on a specific page that supports web parts.
(2) provide a vehicles to add/remove/import/export web parts
(3) raise web part life cycle events.
(4) Change between the different web page views (design, page layout, editing views etc.)
(5) Create/delete/manage web parts connections.
(6) Manage page and web part personalization.

** Web Part Zone – primary role: provide a common user interface and to control the appearance of web part controls.

Sharepoint Web Part requires these two controls: SPWebPartManager and WebPartZone.

On the Insert –> Web Part page, you can upload a web part template (from local) by clicking the “Upload a Web Part” link. Browse and select the *.webpart file. Once uploaded, the uploaded will be available for selection in the “Imported Web Parts” category.

Web part properties: 4 attributes unique to Sharepoint – state management:
(1) WebBrowsable – whether end user can see the properties in the Edit pane. If false, to imperatively set the property’s value on behalf of the end user.
(2) WebDescription – this string shows as a tooltop over the display name.
(3) webDisplayName – shows as the label for the control in the Editor pane.
(4) Personalizzable – a. PersonalizationScope.Shared – true/false: whether Sharepoint should store one value for everyone; b. PersonalizationScope.User: whether Sharepoint should still one common value for everyone, but allow anyone who has permission to personalize to change that value.

** Web Part resources: Sometimes it is needed to deploy other resources with the web part, such as CSS< HTML, Javascript, CSV, XML etc.
 
** Creating a sample visual web part.

When creating a custom/new web part, change the Group property of the web part’s Element.XML to a custom name, so they can be displayed in a specific category:
<Property Name=”Group” Value=”RealWorld” />

Look at the property of the Feature, the deplayment path is:
$SharePoint.Project.FileNameWithoutExtension$_$SharePoint.Feature.FileNameWithoutExtension$

That’s {ProjectName}_{FeatureName}

web part (or other items to be deployed) <<< Feature <<< package

In Package designer, it is default to deplay to WFE. To validate a package, use “Packaing Explorer”, do this to open Packaging Explorer:
View –> Other Windows –> Packaging Explorer. The Packaging Explorer will open in the Tool Box area!!!! (on the left) Right click the top item, right click and “Validate”. Once validatation completed, you will see at the bottom whether it’s successful/failed. You will see the reason in the output window.

When will the “validate” fail? For example, you create a Visual Web part project, but try to deploy it as a sandbox solution!!!! Simply change the solution to be a Farm solution and the validation will pass.

In Webpart’s *.cs file, add this (example) to inside the web part class, to create a user-customizable property: Your web part can use user’s input to customize the web part.

        [WebBrowsable(true)]
        [Personalizable(PersonalizationScope.Shared)]
        [WebDisplayName(“Gagaoolala”)]
        [WebDescription(“Enter the custom name: gagaxxxxxx”)]
        [System.ComponentModel.Category(“Real World”)]
        public string WpProperty { get; set; }

Page 335, 07/17/2011, 10:17PM

Advertisements
Post a comment or leave a trackback: Trackback URL.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: