2008. június havi bejegyzések

A lényeg kiemelése

A Word 2003-ban volt egy Autosummarize funkció, amely nevéhez hűen kiemelte a lényeget egy dokumentumból. A Word 2007-ben is elérhető ez a szolgáltatás, azonban alapértelmezés szerint nincs kint a szalagon, nekünk kell kitenni:

Word Options: AutoSummary

Ezek után az alábbi opciókat tudjuk beállítani és a funkció kiválóan működik angol szövegre:

AutoSummarize beállítások

Mivel én személy szerint jobban kedvelem a képes megoldásokat, ezért némi keresgélés után sikerült rátalálnom a Wordle weboldalra, ahol a lényeg kiemelése a tag-cloud megoldáshoz hasonlóan méret-, elrendezés- és szín variációkkal történik. Lehet tippelni, hogy Szalkáry Károly barátom miről írta a diplomamunkáját:

Wordle: Diploma

Ez pedig én lennék, rövid angol CV alapján, tömören:

Wordle: Balássy György CV

Mikor jutunk el odáig, hogy a keresőmotorok találatai nem egy csupasz listában, hanem átláthatóan rendezve jelennek meg?

Technorati Tags:
Reklámok

Run ablak Windows Mobile-on

Nem éppen gyakori kérdés, de azért újra és újra belefut az ember, hogy hogyan lehet Windows Mobile-on egy parancssort, vagy legalább egy Run ablakot előhúzni. Íme egy trükk: tartsuk nyomva az Action gombot és közben tappintsunk sokáig a címsorban az óra helyére. Az Analog/Digital menü helyett ez jelenik meg:

Run parancs

A Run-ra tappintva pedig előjön a desktopról már ismert ablak:

Run dialógus ablak Windows Mobile-on

Mindezt emulátorban is elő lehet húzni, csak tudni kell, hogy az Action gombnak megfelel a billentyűzeten a Ctrl, azt kell sokáig nyomva tartanunk. Továbi gyorsítóbillentyűk megtekinthetők itt.

Ha ez nem elég, akkor még jól jöhet a Windows Mobile Developer Power Toysban található PPC Command Shell, illetve a Google számos freeware-t is kidobott.

Technorati Tags: ,

Adatok bekérése SharePoint Designeres workflowban

SharePointos workflow fejlesztéshez igen jól használható eszköz a SharePoint Designer (SPD), de tagadhatatlan, hogy néha nehéz elsőre eligazodni a felhasználói felületen. Az egyik ilyen “néha” akkor jön velünk szembe, amikor a folyamat futása során adatokat szeretnénk bekérni a felhasználóktól.

Az adatok bekéréséhez és a felhasználókkal történő kommunikációhoz a SharePointos workflow-k a feladat listákat használják. A SharePoint Designerben az Adatgyűjtés a felhasználóról (angolul Collect Data from a User – a webhely nyelvétől függően) műveletet használhatjuk arra, hogy a feladat listába újabb elemet tegyünk:

SharePoint Designer: Adatgyűjtés a felhasználról

Az Adatok (angolul data) linkre kattintva egy Custom Task Wizard varázsló segítségével adhatjuk meg, hogy milyen információkat szeretnénk megtudni a felhasználótól. Az első kérdésnél egy nevet és egy leírást kell megadnunk:

Custom Task Wizard: név és leírás

A varázsló következő lépésében pedig a bekérendő adatokat definiálhatjuk:

Custom Task Wizard: mezők

Érdemes tudnunk, hogy mi történik a háttérben:

  • A SPD létrehoz egy új tartalomtípust azzal a névvel, amit itt megadunk. A tartalomtípus a Workflow Task típusból származik, tehát 0x01080100 kezdetű azonosítója lesz. Az új tartalomtípus azon a webhelyen jön létre, ahol a workflow-t készítjük.
  • A SPD hozzárendeli ezt a tartalomtípust a folyamathoz rendelt feladatlistához.
  • A SPD létrehoz egy ASP.NET alapú űrlapot a http://szervernév/webhelynév/Workflows/folyamatneve/űrlapneve.aspx címen. Ha barátságos folyamat- és űrlap neveket használunk, az URL gusztustalan lesz. (Persze esélyünk sincs barátságos URL-re, mert van pár tucat karakternyi query string a végén.) Az űrlapot hozzárendeli a tartalomtípushoz szerkesztési űrlapként (tehát csak edit módban fog megjelenni, display módban nem). Ezen az űrlapon statikus szövegként, Title és Description címen megjelenik a varázslóban megadott név és leírás:

Feladat szerkesztő űrlap

Miután így definiáltuk az adatokat és az azokat bekérő felületet, és még azt is megadtuk, hogy ki nyerte meg ezt a feladatot, végül egy változót kell megadnunk:

SPD_WFD_04-Variable

A trükk az, hogy itt egy ID típusú változót kell megadnunk, azaz a művelet eredményeként nem közvetlenül az adatokat kapjuk meg, hanem azt, hogy a SharePoint a folyamathoz kapcsolt feladat listában melyik listaelembe mentette el a felhasználó válaszait.

Persze ilyenkor felmerül a kérdés, hogy ezt hogyan tudom visszanyerni? Például ha naplózni szeretném a Vélemény mezőt, így kell felkonfigurálni a Define Workflow Lookup ablakot:

Define Workflow Lookup

Kis segítség a beállítások olvasásához: ha SQL lenne, ezt írhatnánk:

SELECT Vélemény

FROM Feladatok

WHERE Szám = VéleményezésiFeladatID

Általánosabban:

SELECT LookupDetails_Field

FROM LookupDetails_Source

WHERE FindTheListItem_Field = FindTheListItem_Value

A lookup eredménye olyan típusú lesz, mint a felső Field mezőben megadott oszlop.

 

Származtatott tartalomtípus oszlopok nélkül

Amikor saját SharePointos tartalomtípust készítünk, az kötelezően származik egy szülő tartalomtípusból és örökli annak oszlopait. Hogyan lehet mégis olyan tartalomtípust létrehozni, amelynek egyetlen oszlopa sincs?

A kérdés még inkább fordítva szokott előfordulni, főleg workflow fejlesztéskor: készítünk egy saját tartalomtípust a feladatok kezelésére, származtatunk a WorkflowTask (0x010801) típusból, az öröklés rendben van, mégsem jelennek meg a szülő típus oszlopai. A jelenség oka, hogy úgy hoztuk létre a feature-ben a ContentType elemet, hogy kihagytuk belőle a FieldRefs tag-et. Ez az elem mindenképpen szükséges, még akkor is, ha üres:

<?xml version="1.0" encoding="utf-8"?>
<Elements Id="43c7826b-e8ed-434c-bc48-a321094caee3" xmlns="http://schemas.microsoft.com/sharepoint/">
    <ContentType ID="0x01010088d402e587cb46258a6cdbec0ad318e7"
               Name="Szerződés"
               Group="Saját tartalomtípusok"
               Description="Szerződést leíró tartalomtípus."
               Version="0">
        <FieldRefs />
    </ContentType>
</Elements>

Technorati Tags: ,,

Beépített mező és tartalomtípusok

SharePoint programozása során gyakori feladat, hogy kódból kell hivatkoznunk egy adott mezőre vagy tartalomtípusra. Ha nyelvfüggetlen módon szeretnénk mindezt megtenni, akkor a mező vagy tartalomtípus neve helyett annak azonosítóját kell használnunk.

Ha olvasható kódot szeretnénk gyorsan írni, akkor a GUID-ok bedrótozása helyett inkább használjuk a Microsoft.SharePoint névtérben található SPBuiltInFieldId és SPBuiltInContentTypeId osztályokat. Akkor is jól jöhetnek ezek az osztályok, ha éppen adatbázist vagy naplófájlokat kell elemeznünk, ugyanis közvetlenül megtalálható az osztály forráskódjában az összes azonosító, amely Reflectorral prímán kinyerhető. Az egyszerűség kedvéért mellékeltem is a két fájlt.

A tartalomtípusokkal kapcsolatban előfordulhat, hogy meg kell állapítanunk, hogy egy adott típus egy másikból származik-e. Ez persze “ránézésre látszik”, ha egymás alá tesszük a két típus azonosítóját, a gyermek azonosítója ugyanis a szülő azonosítójával kezdődik. Példaként itt egy öröklési hierarchia:

Item: 0x01

Document: 0x0101

BasicPage: 0x010109

WebPartPage: 0x01010901

Ha ezt a vizsgálatot nem akarjuk mi elvégezni, akkor használhatjuk az SPContentTypeId típust, például így:

    SPContentTypeId doc = SPBuiltInContentTypeId.Document;
    SPContentTypeId item = SPBuiltInContentTypeId.Item;

    Console.WriteLine( doc.IsChildOf( item ) );  // true
    Console.WriteLine( item.IsParentOf( doc ) ); // true

    SPContentTypeId custom = new SPContentTypeId( "0x0105" );
    Console.WriteLine( custom.IsChildOf( item ) );  // true
    Console.WriteLine( custom.IsChildOf( doc ) );   // false

    Console.WriteLine( custom.Parent );  // 0x01

Az SPContentTypeId osztály belül csak egy byte tömbnyi információt tárol a tartalom típusról, azaz gyakorlatilag csak az azonosítóját. Név nincs sehol (legalábbis az SDK és a Reflector szerint), így a Parent tulajdonság kiolvasásakor nem kapunk értelmes nevet, mindössze egy azonosítót. Az SPBuiltInContentTypeId.Contains(contentTypeId) meghívásával még megtudhatjuk, hogy a kapott szülő standard-e, de a nevét nem tudja ez az osztály visszaadni, még a ToString() hívásakor is csak az azonosítót kapjuk.

 

Létrehozási, fordítási és hibakeresési problémák VS 2008 SharePointos projekteknél

Hosszú listát lehet összeírni arról, hogy a SharePoint mi mindenben egyedi. Íme egy újabb tétel a listába: a Visual Studio 2008-ban található SharePointos projekt sablon létrehozás után nem fordul, még ha nem is írunk bele semmit, vagy éppen debug módban nem indítható el.

Először is tisztázzuk, mitől lesznek SharePointos projekt sablonok a Visual Studio 2008-ban: a telepítéskor ki kell választanunk, hogy Office alkalmazásokat is szeretnénk fejleszteni. Ennek hatására két SharePointos projekt típus jelenik meg: SharePoint 2007 Sequential Workflow és SharePoint 2007 State Machine Workflow:

SharePointos projekt típusok Visual Studio 2008-ban

Előfordulhat, hogy hiába kattintunk bármelyikre, a Studio nem képes létrehozni a projektet:

Could not load file or assembly ‘Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c’ or one of its dependencies. The system cannot find the file specified.

Ezek után még felkínálja a Studio, hogy adminként indítsuk újra, de ettől ne várjunk csodát, ugyanis a hibaüzenetnek nagyon egyszerű oka van: valószínűleg nem telepítettünk a gépünkre SharePointot. Egy újabb ok arra, hogy a SharePointos fejlesztéseinket Windows Serverre telepített SharePoint és helyi Visual Studio környezetben végezzük.

Amikor a projekt típusok közül bármelyiket létrehozzuk és le akarjuk fordítani, az alábbi hibaüzenetekket kapjuk:

Could not resolve this reference. Could not locate the assembly "Microsoft.Office.Workflow.Tasks". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.

The type or namespace name ‘Office’ does not exist in the namespace ‘Microsoft’ (are you missing an assembly reference?)

Ha jobban megnézzük a Solution Explorer ablakban a References ágat, azt vehetjük észre, hogy négy SharePointos szerelvényre van hivatkozás, melyek közül a Microsoft.Office.Workflow.Tasks nem található:

Solution Explorer: References

Ennek valószínűleg az az oka, hogy WSS-sel dolgozunk, ezt a szerelvényt viszont csak a MOSS tartalmazza. A hibaüzenet megszűntethető, ha eltávolítjuk ezt a szerelvény referenciát. A hivatkozás egyedül azért szerepel itt, mert a Workflow1.cs fájlban megtalálható az alábbi using sor, amit szintén törölhetünk:

using Microsoft.Office.Workflow.Utility;

A projektünk ezek után vígan fordulni fog. Amikor azonban az F5-re bökve debug módban indítanánk, jön egy újabb hibaüzenet, ezúttal nem fordítási, hanem deployment error:

Failed to install the workflow template to Microsoft Office SharePoint Server.

Feature ’86d1ee3b-9966-40a0-a16f-c366e8a5f302′ could not be installed because the loading of event receiver assembly "Microsoft.Office.Workflow.Feature, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" failed: System.IO.FileNotFoundException: Could not load file or assembly ‘Microsoft.Office.Workflow.Feature, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c’ or one of its dependencies. The system cannot find the file specified.
File name: ‘Microsoft.Office.Workflow.Feature, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c’

Ennek az oka, hogy a feature.xml-ben található hivatkozás a Microsoft.Office.Workflow.Feature szerelvényre, amely szintén csak a MOSS-ban található meg. Bátran töröljük a ReceiverAssembly és a ReceiverClass sorokat és máris menni fog a telepítés:

    <?xml version="1.0" encoding="utf-8" ?>
    <Feature  Id="86d1ee3b-9966-40a0-a16f-c366e8a5f302"
                Title="SharePointWorkflow1 feature"
                Description="My SharePoint Workflow Feature"
                Version="12.0.0.0"
                Scope="Site"
                ReceiverAssembly="Microsoft.Office.Workflow.Feature, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
                ReceiverClass="Microsoft.Office.Workflow.Feature.WorkflowFeatureReceiver"
                xmlns="http://schemas.microsoft.com/sharepoint/">
        <!-- ... -->

A Visual Studio 2008 egyik újdonsága, hogy egy projekt létrehozásakor megadhatjuk a cél .NET Framework verziószámot. A szóban forgó projektek azonban csak akkor jelennek meg, ha a létrehozáskor 3.5-t választunk. Mivel tudjuk, hogy a SharePointnak a .NET 3.0 is elég, ezért a projekt létrehozása után a projekt tulajdonságai között bátran állítsuk át a Target Framework opciót .NET Framework 3.0-ra.

Ezek után megint fordítási hibákat fogunk kapni, aminek megoldásához töröljük a LINQ-es hivatkozásokat. A References ágból töröljük a System.Data.DataSetExtensions és a System.Xml.Linq szerelvényeket, a workflow1.cs fájlból pedig a using System.Linq; sort.

 

Informatika Tisztán – letöltések

Javában zajlik az Informatika Tisztán rendezvénysorozat, akit érdekel a csoportmunka, még van lehetősége megtekinteni az előadásokat valamelyik helyszínen.

A Windows SharePoint Services v3 üzemeltetéssel kapcsolatos prezentáció letölthető innen:

WSSv3_rendszergazda_szemmel_(Balassy_Gyorgy)_v15.ppt (23946 kB)

Az előadáshoz kapcsolódó screencastok is elkészültek:

  1. A telepítés előkészítése (13:57) Lejátszás »
  2. Telepítés utáni első lépések (24:06) Lejátszás »
  3. Extranet publikálás (11:31) Lejátszás »
  4. Monitorozás (8:25) Lejátszás »
  5. Mentés és visszatöltés (12:03) Lejátszás »
  6. Külső gyártótól származó megoldás telepítése (9:51) Lejátszás »

Ráadásként pedig készült egy olyan felvétel is, amely az Internet Information Services és az ASP.NET webalkalmazások üzemeltetésével kapcsolatos legfontosabb alapismereteket foglalja össze:

ASP.NET bevezető üzemeltetőknek (32:21) Lejátszás »

A videó fájlok közvetlenül is letölthetőek vagy a Lejátszás linkre kattintva böngészőben is megtekinthetőek egy Silverlight alapú lejátszónak köszönhetően 800×600 felbontásban.

Sajnos nagyon kevés visszajelzést kapunk az előadásokkal kapcsolatban, aki ott volt és van véleménye, kérem írja meg, hogy tudjuk, mi volt jó és mit csináltunk rosszul. Köszönjük!