Monday, August 24, 2009

What is a Data View?

A Data View is a live, customizable view of a data source that leverages Microsoft ASP.NET technology. Office SharePoint Designer 2007 retrieves data from a data source in the form of Extensible Markup Language (XML) and displays that data by using Extensible Stylesheet Language Transformations (XSLTs). You can modify a Data View by using Office SharePoint Designer 2007. A Data View can display data from a wide variety of sources, including database queries, XML documents, Web services, SharePoint lists and libraries, and server-side scripts. You can also create a Data View that displays data from multiple data sources.

A Data View retrieves data from a data source and displays that data by using XSLT

Data Views present live views of data that you can filter, sort, or group. You can also change the layout, apply styles, or apply conditional formatting in a completely WYSIWYG (what you see is what you get) environment.

After you insert a Data View into your page, you can also use the WYSIWYG tools in Office SharePoint Designer 2007 to add or remove columns, change font formatting, or apply colors. When you format a Data View by using the WYSIWYG tools available in Office SharePoint Designer 2007, Extensible Stylesheet Language (XSL) is inserted directly into the HTML. While it is possible to edit the XSL directly in Code view, you can use the formatting tools in Office SharePoint Designer 2007 to apply XSL quickly and easily without knowing any XSL.

Developer Introduction to Workflows for Windows SharePoint Services 3.0 and SharePoint Server 2007

Introduction to Workflows

Microsoft Windows SharePoint Services provides a robust, customizable work environment for users to create, collaborate, and store valuable business information. Now, with Microsoft Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007, you can attach custom business processes to these documents or list items.

You can represent these custom business processes by using workflows. A workflow is a natural way to organize and run a set of work units, or activities, to form an executable representation of a work process. This process can control almost any aspect of an item in Windows SharePoint Services, including the life cycle of that item. The workflow is flexible enough to model both the system functions and the human actions necessary for the workflow to complete.

You can create workflows that are as simple or complex as your business processes require. You can create workflows that the user initiates, or workflows that Windows SharePoint Services automatically initiates based on some event, such as when an item is created or changed.

Suppose you need to create a simple workflow that routes a document to a series of users for approval or comments. This workflow would include actions that the system needs to perform, as well as provide interfaces for the users to interact with the workflow in prescribed ways. For example, Windows SharePoint Services would send an e-mail message to the selected users when the document was ready for review. Those users would then need to be able to notify Windows SharePoint Services when they had completed their reviews and, optionally, enter any comments. The workflow framework included in Windows SharePoint Services 3.0, and extended in SharePoint Server 2007, enables you to model such complex work processes and present them to end users in an easily understood, unobtrusive manner that guides them through each step of the process.

This article provides a high-level overview of workflows as they are implemented in Windows SharePoint Services and extended in SharePoint Server. It includes a discussion of the developer tools available to create workflows in both environments, and the respective capabilities and advantages of those tools.

Thursday, August 20, 2009

Configurable Silverlight Image Rotator

http://www.anothercodesite.com/Blog/2008/12/default.aspx

Exploring the Data View Web Part

Companies typically use a multitude of repository types to store and manage their data. A company may use SQL Server to store relational data; the Windows file system for storing semi-structured data and eXtensible Markup Language (XML) files to hold hierarchical data. The need to aggregate and manage data in a central location is a very common requirement within portal environments. To cater to this need, you could build custom Web Parts using Visual Studio.NET to incorporate various data sources. Instead, for a range of scenarios, you will want to try to use the Data View Web Part first. The Data View Web Part is an advanced tool that allows you to create solutions for viewing and managing data in a fraction of the time it would take you to build a similar solution in Visual Studio.NET. The Data View Web Part lets you view and manage data coming from different data sources, like Web services, SharePoint lists and server-side scripts.

Data View Web Parts are able to retrieve data from various data sources in the form of XML even if the data itself in its original form is not XML, and make it very easy to adjust the appearance of that data by applying eXtensible Stylesheet Language Transformations (XSLT) to it. XSLT is used for transforming the structure of an XML document. The XML data within a Data View Web Part can be formatted using the Microsoft Office SharePoint Designer’s Design view. The next procedure explains how to open a SharePoint page in design view using a Internet Explorer.

Open Internet Explorer and navigate to a SharePoint site.
Click the Page button at the upper right corner. If SharePoint Designer is installed on your machine, this opens a menu that contains the option Edit with Microsoft Office SharePoint Designer. Click Edit with Microsoft Office SharePoint Designer, which by default, opens the SharePoint site in SharePoint Designer’s Design view.
If the page is opened in another view, you can switch back to Design view by clicking the Design tab at the bottom.
The Data View Web Part offers many possibilities, such as consuming various data sources, sharing data sources, defining the look and feel of data overviews, and adding editing capabilities to data overviews. The Data View Web Part is all about aggregating and managing data from various data sources. The first thing you need to learn about the Data View Web Part is how to import and display data. To start this discussion, we will take a closer look at data sources, data source libraries, and SharePoint Designer.

Importing and displaying Data
From the perspective of the Data View Web Part, a data source is a repository of information or an end point that provides access to an information repository, for example, a database or a Web service. The Data Source Library is the main entry point for accessing and managing data sources within SharePoint sites.

SharePoint Designer, based on FrontPage technology, is a powerful tool that makes both Windows SharePoint Services (WSS) 3.0 and Microsoft Office SharePoint Server (MOSS) 2007 implementations a lot easier. SharePoint Designer lets you define new data sources, add Data View Web Parts to SharePoint Web pages that access, and display these data sources in a visual way. Manipulating the Data View Web Part visually might seem to have to do less with software development when compared to typing code yourself, but the fact of the matter is, nowadays creating software becomes more and more abstract and visual.


for more refer:http://www.lcbridge.nl/vision/2009/dvwp.htm

SharePoint 2007 and workflow

Process to define personalization requirements

I'm often asked by customers how SharePoint can be used to personalize content for users. Although there are plenty of features in SharePoint to achieve personalization, you have to be able to come up with the rules that define an audience and then how you will identify the information that is relevant to each audience.

Wouldn't it be great if all information and content mapped to a comprehensive taxonomy and that we could automatically align the taxonomy with groups of people? Because this is not usually a simple thing to achieve, we need to prioritise the work required to start targeting information and content to users based on a number of factors.

Therefore, before we start talking about SharePoint personalization features, we need to identify the audiences, taxonomies, information /content sources, business priorities and the relationships between each of these.



You can start the process from an audience or content perspective (left vs. right). From an audience perspective, membership can be broken down into two types:

Optional (opt in/out)
Fixed (based on business rules)
Active Directory group membership or some other line of business application that manages access to information based on a user's role is a common way of defining audience membership but this often doesn't align to a taxonomy such as an EDRMS file plan.

Some audiences will be broad in scope while others will be very narrow.

There will be more than one taxonomy (internal and external), so look for areas of the taxonomy's that can be linked to audience properties.

Audiences will often not agree on which information is of most value. Prioritized personalization of information based on value to the business vs. level of complexity will help users understand the big picture.

Priority will be based on a number of factors:

Volume of content (architectural impact)
Value of content in helping make informed business decisions
Structure of content (formal taxonomy vs folksonomy or none)
Accessibility of the content (API's, iFilters, federated search etc)
Once all of these requirements have been identified, then we can architect a solution...

InfoPath Forms in Office SharePoint Server 2007

I’m sure it comes as no surprise that Office InfoPath 2007 is the forms designer of choice for Office SharePoint Server 2007. But the average SharePoint developer, used to reaching for ASP.NET when he needs to create a form for SharePoint, might be surprised at all the places you can employ InfoPath to quickly create forms for enterprise management functions.
The main reason for this is the fact that in InfoPath 2007 you can create what the InfoPath guys are calling symmetrical forms. Symmetrical forms are InfoPath forms that can be hosted either in the Office client applications like Word, PowerPoint, and Excel, as well as in the SharePoint Server browser interface. So you can create a single form, and know it’ll look and work the same whether the user sees it in an Office application or in the browser interface.
(How is this possible? Short version: SharePoint Server 2007 uses Office Forms Services, a server-based run-time environment for InfoPath 2007 forms, to host the forms in the browser. Office Forms Services consumes the forms you create in the InfoPath client and renders them in an ASP.NET framework, which acts as a run-time environment for the form. This environment presents a form editing experience that matches the InfoPath 2007 client application. The Office client applications, on the other hand, include the ability to host the native InfoPath forms. )
So naturally, symmetrical forms are very handy for enterprise content management areas, where the user might be working with documents in their native client application, or online through the SharePoint Server browser interface.
Here’re a couple of the places where you can employ InfoPath forms for enterprise content management in SharePoint Server 2007:
· Document Information Panels
A document information panel is a form that is displayed within the client application, and which contains fields for the document metadata. Document information panels enable users to enter important metadata about a file anytime they want, without having to leave the Microsoft Office system client application. For files stored in document libraries, the document information is actually the columns of the content type assigned to that file. The document information panel displays a field for each content type property, or column, the user can edit.
You can create document information panels either from within SharePoint Server, or directly from InfoPath 2007.
How to: Create or Edit a Custom Document Information Panel from within Office SharePoint Server 2007
How to: Create a Custom Document Information Panel from InfoPath
· Workflow Forms
You can create InfoPath forms for use with workflows in SharePoint Server 2007. That way, the user can interact with the workflow form from within the Office client application, and not just through the browser.
SharePoint Server 2007 uses Office Forms Services to display workflow forms, be they association, initiation, modification, or edit task forms. The only difference is that there’s a different .aspx page hosting the Office Forms Services control for each type of workflow form. Initiation forms are hosted by a different .aspx page than modification forms, for example. Each different hosting page knows how to submit the information from its type of form to SharePoint Server (and hence, to the workflow engine).
The .aspx pages that contain the Office Forms Services web part are included as part of SharePoint Server, of course.
How to: Design an InfoPath Form for a Workflow in Office SharePoint Server 2007
So if your putting together an enterprise content management solution in Office SharePoint Server, and you’d like your user to be able to interact with your custom forms in the client application and the browser, it might be worth your while to take a look at InfoPath 2007 and Office Forms Services.