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

Monday 17 January 2011

Timesheet solution for SharePoint 2010 - Part 2 UI

Problem: Using the database design from Part 1, I need to create the UI for users to submit timesheets.  The screen to capture the users timesheet looks like this:

Related posts in this series:
Part 1 - Design & data storage
Part 2 - Building the UI(This blog post)
Part 3 - Installation Steps 
Part 4 - Final Part

Part 2 Continued...

Initial Hypothesis:  Create 4 connect web parts to allow users to submit their timesheets weekly.  Also allow site collection administrators to submit timesheets for users.  The web parts will also allow administrators to approve or reject the timesheet.
Resolution: Create 4 connected web parts to display user timesheets on a page.  Use the dialog framework to add and edit tasks.  The ability to add a new task is done in another web part on a separate page.  The edit task allows users to edit or delete and existing task, this is another custom web part place on a separate page within the site collection.

Create a web parts to perform basic administration options.  I have create 3 administration web parts within Visual studio to allow administrators to update key timesheet information such as adding new client or projects or assigning people to a project.

Reporting for the timesheet can be created using either: Reporting Services and integrated into SharePoint, BCS to query data, or custom web parts.
Part 1 - Design & data storage
Part 2 - Building the UI (This blog post)
Part 3 - Installation Steps 
Part 4 - Final Part

Timesheet solution for SharePoint 2010 - Part 1

Part 1 - Design & data storage (This blog post)
Part 2 - Building the UI
Part 3 - Installation Steps
Part 4 - Final Part

Problem:  A common requirement on Intranets is to have a timesheet template on SharePoint.  There are solution for company timesheets.  I wanted to build a timesheet application that was scalable, reportable and friendly for SharePoint. 

Initial Hypothesis:  There are timesheet solutions for SharePoint and most are portable to SharePoint 2010.  Often the timesheet solutions integrate with Outlook as well.  If you have outlook this is often the best solution as users seem to accept Outlook based solutions fairly easily.

I came across http://www.pointbeyond.com/, there timesheet solution was built for WSS3/MOSS, this looks like a solid solution based on SQL Server so their is no real reliance on SharePoint lists however, SharePoint surfaces the timesheets, administration and reporting requirements.  I have not implement the solution but it appears solid and expandable.

In WSS3 I think it would be very difficult to build a detailed timesheet application based on SharePoint lists due to the list size issue and the list relationship complexity required for a timesheet application.

Resolution:  I want a SharePoint Foundations solution that can be used on all SharePoint 2010 farms that can capture and administer timesheets for a business.  SPMetal has greatly improved application development when using SharePoint lists to store data in SP2010 however, due to the number of relational lists and the support for transactional CRUD operations I believe it is better to use SQL Server and store the data in relational tables.  Custom connected web parts will allow users to enter their weekly timesheets.  The solution allows for the use of BCS and External Content Type (ECT) in SP2010 for administration and reporting.

The data access technology choice is between Linq to SQL and using the Entity framework 4.0.  As SharePoint 2010 supports .NET 3.5, a separate Visual studio project/business layer would be required.  Additionally my take on these 2 competing Data access technologies is, if it's simple then use Linq to SQL, if it's complex and could change down the line use the entity framework.  I choose to use LINQ to SharePoint as I am using 7 tables to store all my timesheet task related data.  Below is the Entity Relationship Diagram (ERD) for the timesheet application.


Part 1 - Design & data storage (This blog post)
Part 2 - Building the UI
Part 3 - Installation Steps
Part 4 - Final Part

More Info:
Updated: 25/02/2011 Laura Rogers wrote this article on the time card that is useful.
http://www.sharepoint911.com/blogs/laura/Lists/Posts/Post.aspx?ID=113







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.

Wednesday 14 July 2010

SP2010 CQWP customisation

Overview: Content Query Web Part (CQWP) in SP2010 is similar to in MOSS. This post walks thru using the CQWP to display a custom list and custom columns while outputting custom html via a custom xslt.
CQWP (need the publishing feature enabled, this creates the styles library and add the CQWP) by default uses the xslt /Style Library/XSL Style Sheets/ItemStyle.xsl.

Steps:
  1. Don't write over ItemStyle.xsl as this si supplied by SP2010 OOTB. Rather create a new xslt and put it into the styles library. Build up the xslt, I based my file on the itemstyle.xsl file, see rules for getting the output you are looking for using How to: Customize XSL for the Content By Query Web Part
  2. Custom xslt formatting, I always add the following code in case I want to see what the available fields are:
  3. Deploy the custom style sheet via a feature.
  4. Create a new Custom list called "Pets" and add columns for Title, Age & Status (choice):
  5. Edit your custom xslt to display for "Pets" as shown below:
  6. Add a new CQWP to your page. Configure it to display items from your new list (Pets).
  7. Change the "Presentation" section, "Item Style" to Show "Pets". Apply the Changes:
  8. CQWP displays as:
  9. Edit the CQWP "Age" property to "Age"
  10. Edit the CQWP "Age" property to "Status"

    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):