Денят започна с интересни работи – лекция относно промените в интерфейса и въвеждането на Ribbon Toolbar в SharePoint 2010. Wouter посочи проблемите в SP 2007 – команди навскъде, различни екрани за всичко, излизане от контекст, зареждане и post-back за всеки нов екран.
Отделно, крайните потрябители искат да подменят „страниците“ на своя портал. За да се случи това е необходимо да се мине в Edit mode, да се добави “web part”, и примерно да, се посочи URL на картинка. Процесът е сложен и в никакъв случай приятен за работа на потребители, за които SharePoint e нещо ново. A и какво е това „web part” или „URL”??
Веднага си пролича и инвестицията на Майкрософт в този проблем. SharePoint 2010 предлага плавен интерфейс с по-свободни преходи и по малко екрани.
· SharePoint 2010 предлага Ribbon Toolbar като този в останалите продукти от Office пакета. Този Ribbon е познат на потребителите, еднакъв е навсякъде и е на познато място – няма нужда да се тръсят команди в различните кътове на страницата.
· Опциите в този Ribbon се променят и според контекста – ако крайният потребител редактира страница, ще се появят опции за пормяна на шрифта и т.н. А ако работи със списък от данни ще се появят опции за редактиране на данните.
· Dialog Framework – всички нови екрани са под формата на диалогови прозорци и pop-ups. Така крайният потребител на губи фокус от страницата на която работи. Като се затвори прозорецът информацията се подменя чрез AJAX повиквания, и всичко става по приятно за работа.
Следващото нещо, което научих, е въвеждането на „страници“ навсякъде в SharePoint. Майкрософт вярва, че крайните потребители си представят своя портал като колекция от страници, а не колекция от списъци. В SharePoint 2010 се въвежда идеята за страници, които са лесни за промяна и редактиране със съдържание. Редактирането е подобно като в Microsoft Word, и добавянето на картинки е улеснено – потребителят посочва картинка и тя се качва в Site Assets библиотека.
Други интересни неща, които научих относно интерфейса:
· Всеки сайт може да бъде конфигуриран да се зарежда със стария интерфейс (v3), но се губи плавният начин на работа и е без Ribbon. Това е за потребители на SharePoint 2007, които искат да преминат на 2010, но не са готови да подменят интерфейса на своите решения.
· Application pages вече може да се редактират от гледна точка на дизайн – това не беше официално в 2007
· Нещо важно за нашата сцена – инвестиция относто многоезична функционалност. Всеки сайт може да се разглежда в различни езици според избор на крайният потребител. В 2007 всеки сайт се създава за определен език.
· Нов web part за визуализиране на информация в списъци – XsltListViewWebPart.В 2007 дефинирането на HTML markup в списъците ставаше чрез CAML и ASP.NET Rendering templates. Този нов web part въвежда XSLT за генерирането на HTML markup.
След кратка пауза запоянахме лабораторно упражнение, в което създавахме нови менюта в новият Ribbon.
Денят продължи с разглеждането на промените в дефинициите на списъците. Нещата, които запомних са следните:
· Списъци вече поддържат връзки с други списъци – Joins и Relationships между списъци
· Projected fields – полета от parent списък видими в child списъка. Пример: ако foreign key е ID, да се добави Name, така че да има смисъл за крайните потребители. За съжаление, projected fields са read-only…
· SPQuery обекта има .Join и .ProjectedFields притежания
· Подобрени възможности за списъци с много данни, като системата вече има горни граници на броя на редовете върнати от завки. Тази настройка се конфигурира от нашите IT PRO колеги.
· Полетата в списъците вече може да се конфигурират, така че да съдържат само уникални стойности. Проверката става на SQL collation ниво.
· Полета също могат да имат и валидация, min max и т.н.
· Валидация също може да се конфигурира на ниво списък – примерно, да няма резултат с цифри в заглавието след определена дата, освен ако не е създаден от управител.
Според мен подобренията в списъците са значителни, и много от проблемите в 2007 са преодолени. Струва си да кажа, че горните граници на списъците ще променят начините, по които създаваме решения на база на списъци. Кода така трябва да се напише, че да работи когато броят на редовете достигне границата. SharePoint ще хвърли exception… Ще имам едно на ум когато пиша и разглеждам код за проверка. Едно качествено решение трябва да ги вземе тези неща в предвид.
Последната тема за денят беше LINQ to SharePoint. Трябва да си признаем, работата с CAML не е от най-лесните. Създаването на CAML Queries в код е досадно – работи се с много String обекти, синтаксисът на самия CAML е опасен, всичко е текст който описва обекти, вместо истински обекти в IDE-то.
LINQ решава подобни проблеми като генерира proxy обекти. В случая с SharePoint, LINQ to SharePoint започва с генерирането на обекти от списъци. След като тези обекти са генерирани може да се създаде DataContext и да се пишат заявки директно в кода на база на LINQ синтаксис. Работата със списъци се улеснява, като и Update операциите са покрити.
Обекти се генерират с SPMetal. Това е малка програмка за конзоли, на която се посочва списък и изходен файл. SPMetal поддържа и свързани списъци.
След лабораторното упражнение и тежкият ден, десетина от нас ентусиазти се почерпихме с жива вира и мазно ядене…
Линкове към останалите дни:
SharePoint 2010 Ignite Training – Понеделник
SharePoint 2010 Ignite Training – Вторник
SharePoint 2010 Ignite Training – Сряда
SharePoint 2010 Ignite Training – Четвъртък
SharePoint 2010 Ignite Training – Петък
