Showing posts with label web parts. Show all posts
Showing posts with label web parts. Show all posts

Wednesday 29 December 2010

Connected Web Part Series - Part 1

Problem: There is a lot of information relating to web parts however this series is aimed at connected web parts in SharePoint 2010.  This 1st post deals with creating a custom connection between 2 visual web parts (a provider & a consumer).

Overview:  Create a Interface to enable communication between the provider and the consumer web part.  Create Visual User controls to connect to each other. 
Tip: Web Parts are easier to connect than Visual Web Parts, so only use Visual web parts if there is a heavy visual requirement.

Steps:
Create a new Web Part (it will be the provider web part)
 Create an Interface (contract between the provider and consumer web parts)
 Implement the Interface in the Provider web part
Create the Consumer web part as shown below
Deploy the solution and activate the feature that contains the 2 web parts
In a browser add the 2 web parts to a page (Provider & Consumer) 
 Connect the 2 web parts as shown below

Friday 24 December 2010

Connected Web Part Series - Part 2

Title: Creating a web part that is both a consumer and a provider.

Problem: I needed a web part that receives data from a provider web part.  The same web part then passes data onto a consumer web part.  I.e.  WebPartGetUser (Provider), WebPartShowWeeks (Consumer & Provider) & WebPartShowProductsOrderedinWeek (consumer). 

Hypothesis:
WebPartGetUser - Retrieve the user and passes the user id to the web part WebPartShowWeeks.
WebPartShowWeeks  - Consumes the UserId and show weeks where the user placed an order.  A drop down list show all the weeks, when the week is selected, the week is passed to the WebPartShowProductsOrderedinWeek web part.  This show all the orders placed in a specific week.

Saturday 31 July 2010

SharePoint 2010 simple reporting options

Overview: SSRS has it's place but I want to gather reports from a composite application where data is stored in SharePoint lists.
Solutions:
OOTB web parts - UI may be tricky to get right but useful for quick reporting that can be performed by power users for general business users. Use filter, List View (XLVWP), CQWP, data View, chart web parts.
Custom Web parts - either write or buy web parts for querying lists. Custom CAML queries provide a solution to display data. Con is that it's pretty development heavy, inflexible and requires code deployment. SPMetal has issues with joins, publish columns and hidden columns such as "Created by". Also see Ninetix reporting.
Dataviews - Displaying list data using SPD - need SPD access. Joining 2 lists.

Giles Hamson has a good chart explaining reporting options.

Wednesday 23 June 2010

Delete Web Parts from a page using the browser

Problem: A web part fails, is hidden and you can remove it using the edit mode on a SharePoint page.
Resolution: A custom crafted url will display a list of web parts and allow you to cleanup the page as required. Enter the domain plus http://url/_layouts/spcontnt.aspx?&url=page>

If the page with the problem had the url http://demo1.dev/myarea/printer.aspx
You would enter the url http://demo1.dev/_layouts/spcontnt.aspx?&url=myarea/printer.aspx
Alternatively Approach: Append ?content=1 to the url and you will be directed as above.
Example:
Page: http://www.demo.dev/sites/sponline/Pages/ViewProperty.aspx
Make it: http://www.demo.dev/sites/sponline/Pages/ViewProperty.aspx?contents=1
You get re-directed to: http://www.demo.dev/sites/sponline/_layouts/spcontnt.aspx?&url=%2fsites%2fsponline%2fPages%2fViewProperty.aspx

Thursday 17 June 2010

XLVWP - Filtering the xslt List View Web Part Series

Overview: Xslt List View (XLV) Web Part is widely used in SP 2010. This series of posts shows how to use this Web Part. Various connected web parts can be used to filter the XLVWP such as a List Filter Web Part.

Filtering: The filtering web parts provides a good way to filter data in the XLVWP. Using Connected Web Parts it is easy to filter the data you wish to retrieve. Below is the setup of 2 List View Web parts that are used to filter depending on the selected data.


Presentation: SPD 2010 provides a good tool for customising the presentation of the XLV WP. Additionally you can uncouple the default shared XSLT and provide your own customised xslt.

Also see:XSLT List View Web Part (XLV):

Filter web parts are missing

I couldn't find the "filter web parts" on my SP 2010 installation, they are there just add them to the web part gallery.
In the RTM the filter WP are available by default and didn't need to be added.

A list of OOTB Web Parts

How Filter WP work from the MS site. Writen for MOSS but still applies to SP2010.

  1. Connect a filter Web Part to a List View Web Part to display a subset of data.
  2. The filter Web Part provides a value.
  3. The filter value is passed to a column in the List View Web Part by using a Web Part connection.
  4. The List View Web Part displays only those columns that match the filter value

Sunday 13 June 2010

Using embedded jQuery in xslt for SharePoint

Problem: A lot of web parts (WP) use xslt to create the html user interface(UI). You need to escape characters in order to get jQuery to work.
Initial Hypothesis:
Can use a Content Network Content copy of jQuery, has the advantage of being up-to-date and may be cached in user browser already. Issue is that may not be trusted or available on an Intranet.
jQuery file/s should be embedded in the master page (this should be activated in a feature).
Inside the xslt add the jQuery to perform your custom actions as shown below that does not escape characters:

Sunday 6 June 2010

Application Architecture in SharePoint 2010

Problem: I have a client that needs a composite built using 2010. The application is used to manage digital assets for suppliers. Key questions are where to store data and how to access the data.
Hypothesis: Where to store data, previously in MOSS I would of used SQL Server and accessed it via the BDC or custom web parts. In SP 2010 lists have been vastly improved and are now a good option for storing data. The new External Content Type can be used on SQL but goes beyond my requirement.
The key improvements to SharePoint lists are:

  1. Lookup lists are improved and easier to implement;
  2. Query joins and LINQ improve retrieving data;
  3. LINQ gives you strongly typed lists which using the old "Server Object Model" were weakly typed;
  4. LINQ querries are converted to CAML querries and therefore more performant than using the Server object model method and alot cleaner than using CAML to query data;
  5. Formula based validation on fields;
  6. Store level enforcement (MOSS enforce requirements such as null values only at the UI level);
  7. Improved referential integrity between lookup lists.
My choice was between using SQL Server to store the application data and SharePoint lists. SQL tables have the following key advanatages of they are more performant, and are transactionable. The easy of use and adavantages meant that SharePoint lists are the prefered option for storage.
Application for the suppliers and users also has several options however SharePoint provides most of the admin screens. The actual app can be built using application pages or web parts or the method i prefer, the client object model.

Accessing SharePoint Data options to consider are: Client Object Model (Weakly typed), however REST API's are Strongly typed for SP lists only. New in SP2010
Server Object Model (OM) is weakly type lists but offers the most flexibility. The Server OM existed on MOSS but is improved in SP2010. LINQ gives strongly type SP lists that can be read-write (new in SP2010)
Resolution:
Used SP lists to store the digital assets, the ordering data is also stored in SharePoint lists. For speed of development in the prototype I built using application pages using web parts that accessed the lists using LINQ to SharePoint. The final application will be built using the Client OM.