Author: Peter Birkholm-Buch (Page 10 of 17)

• CQWP Step by Step

Styling

• Customizing the Content Query Web Part and Custom Item Styles
• Using a Custom ContentQueryMain.xsl
• Show multiple columns in CQWP
• CQWP HINTS – Swap the “title” URL from “$SafeLinkUrl” to a custom URL
• CQWP HINTS – Only show more link if needed
• CQWP HINTS – Import XSL Styles into “ItemStyle.xsl”
• CQWP debug item style
• Get the CQWP to output raw HTML Tags

Custom Queries

• Overriding the Content Query Web Part
• How to: Customize the Content Query Web Part by using Custom Properties

Programmatic

• Subclassing the Content Query Web Part: Adding Dynamic Filtering

Cool Examples That Tie It All Together

• CQWP HINTS – Windows Media Player
• Video: Customizing Content Query Web Parts by Using Custom Properties in SharePoint Server 2007
• How to customize the Content Query Web Part XSL to aggregate blog posts

Enhanced CQWP’s

• CQWP with Query Override – available on the Intranet
• Lightning Tool Conductor Web Part – available on the Intranet

Notice: I wrote this when I was still working for NNIT, but the principles still apply.

Eli Robillard wrote a post on “When to use a database, SharePoint, or wiki” with the following highlights:

A database stores structured data. The structure is typically designed and owned by an individual. Politically, it’s a dictatorship. Line-of-business applications which gather and distribute raw data are typically associated with databases.

Sharepoint provides webs to store lists and documents. Think of this as loosely-structured data. Sharepoint lets you control this data with versioning, backup and recovery, workflow, security, policies and auditing. The structure might be seeded by an individual, but ownership is distributed. Sharepoint should be designed to unfold according to to will of the distributed owners. Politically, Sharepoint provides representative leadership like a parliamentary system though the leaders are typically appointed rather than elected. Sharepoint is used by “information workers” to create, manage, and publish information typically stored in lists and documents. Sharepoint is used as an interface to databases. Sharepoint is a social tool used to recognize and reinforce relationships among people. Through either Sharepoint’s business intelligence capabilities or its integration with Reporting Services, Sharepoint can report on data from structured and loosely structured data stores. Sharepoint can index and provide search for structures, loosely structured, and unstructured data stores.

A Wiki provides webs to store text with embedded references to media. This is unstructured data. Wiki content can be seeded with the intention to unfold according to some master design, but politically, it’s anarchy. A Wiki allow control through versioning and moderation. A Wiki is well-suited for collaborative documentation.

I the years to come eS will hopefully get the chance to convert a lot of Lotus Notes databases to Sharepoint. Each time you have to stop and figure out which one or all of the above mentioned data storage mechanisms you have to use in order to convert the functionality of the Lotus Notes database to Sharepoint.

Lotus Notes databases basically comes in two flavors:

1. Plain data (one or more tables) with views and no LotusScript code – basically it’s a spreadsheet with alphanumerical data
2. Data with views, references and business logic in LotusScript code – basically it’s an application

In the first case it’s a no brainer to just convert the database into a WSS site with the data in custom lists combined with custom views and perhaps a few Web Part Pages thrown in with connected Web Parts that displays data. This is exactly what JPTL is doing right now with a Lotus Notes database from Novo Nordisk Stakeholder Relations.

In the second case it’s much more difficult and each Lotus Notes database or more appropriately Lotus Notes Application has to be thoroughly analyzed. Once you have a good understanding of the business requirements and these was implemented in the Lotus Notes Application – stop and take a look at the slide below.

Your job now is to transform the business requirements from the square Lotus Notes approach to the round Sharepoint approach.

Can you fulfill the same surface area of business requirements with standard Sharepoint functionality? This is where creative use of lists (custom, tasks, wikis and so on), document libraries, views, Web Parts, workflows and Web Part Pages comes in.

Obviously there will be cases where it’s just not possible to get the job done and you’ll have to revert to a normal application design with ASP.NET (remember that Web Parts in WSS3.0 is a ASP.NET2.0 Web Part) and a backend database – but hopefully it will won’t be very often. You could take the middle road and use a list for storage and you could even use SilverLight for the UX instead of ASP.NET.

From: http://stuffthathappens.com/blog/2008/03/05/simplicity/

Er jeg blevet interviewet af Daniel Frost fra Microsoft om:

http://danielfrost.dk/post/Froste28099s-podcast-Episode-1-e28093-Hvad-laver-en-CTO-.aspx

Check this out: http://feedproxy.google.com/~r/bsimser/~3/tRLAwBhGWrc/calculated-time-left-columns-in-sharepoint-with-jquery.aspx

Jeg har gennem tiden skrevet et utal af tilbud baseret på udbudsmateriale, der var mere eller mindre gennemarbejdet.

Desværre har de fleste kravspecifikationer en stor fejl:

1. De funktionelle krav har været skrevet i hvordan-form i stedet for hvad-form

Når man skriver kravspecifikation for funktionelle krav, er det en kunstform kun at beskrive det som systemet skal kunne (altså selve forretningskravene) og ikke hvordan systemet forventes at løse disse krav.

Når funktionelle kravspecifikationer er skrevet i hvordan-form giver det store vanskeligheder at udnytte standardsystemer til at løfte krav der dybest set kan håndteres af standardfunktionalitet, fordi der i kravene er indlagt krav til proces og præsentation.

Det bedste i sådan en stituation er at indgå i tæt dialog med kunden og gennem workshops søge at forstå selve hvad-essencen i kravene. Herefter er det så muligt via prototyping at vise hvordan krav kan løftes f.eks. via standardfunktionalitet.

Jeg kalder processen for “Transformation af forretningskrav med fast overfladeareal”. Det handler i virkeligheden bare om at forstå de basale forretningskrav og vise hvordan de kan løftes nemmest via standardfunktionalitet. Jeg har gennemført workshops med dette formål med masser af kunder. Senest med Københavns Universitet, hvor vi fik reduceret omkostningerne til projektet med næsten 25% ved, at løse krav med standardfunktionalitet, i stedet for at kode en løsning der opfyldte de oprindelige krav 100% uden brug af standardfunktionalitet.

Processen kan bruges i alle situationer, hvor der er tale om en løsning, hvor det er muligt at bruge et standardsystem til at løse store dele af forretningskravene.