ЗАМЕТКА: книга "Внутреннее устройство Microsoft Windows SharePoint Services 3.0", Глава 3. Страницы и дизайн

1. Я понял в чем соль использования "призраков" страниц. "Призрак" единожды загружается в пул приложения в виде DLL. "Без призрака" хранится в базе и вытаскивается из базы при каждом запросе. Если бы все страницы были бы в памяти пула, то они занимали бы очень много памяти. Однако нельзя обходиться "призраками", т.к. они совсем не гибки.
2. Все файлы (aspx страницы, css таблицы и пр.) можно получить из SPWeb при помощи метода GetFile(string FileName), который имеет методы OpenBinary и OpenBinaryStream позволяющие прочитать файл.
3. Иерархия файлов в SPWeb организована аналогичной файловой системе. Есть корневой каталог RootFolder, который содержит в себе подкаталоги и файлы, доступ к которым осуществляется через свойства SubFolders и Files
4. Шаблоны страниц, на основе которых делаются "страницы с призраком", можно создавать программно.
5. По умолчанию все страницы "без призрака" обрабатываются в безопасном режиме. Это означает, что нельзя использовать inline коды. К кастомизации страниц могут иметь доступ простые пользователи и если они смогут писать inline коды, то будет открытая возможность для взлома злоумышленниками. По мимо этого, минус inline кодов - необходимость компиляции страницы. А после компиляции и внесения в пул, DLL вытащить из пула (из оперативной памяти) без перезагрузки процессов нельзя. Однако, не смотря на эти минусы, через web.config можно разрешить обработку страниц в небезопасном режиме.
6. Для того, чтобы на страницу можно было занести элементы управления и обрабатывать страницу в безопасном режиме, их нужно занести в блок SafeControls в web.config. Любая веб часть может быть использована только если её DLL внесена в этот блок.
7. Пользовательские элементы управления компилятся в DLL и заносятся в GAC или папку bin корневого сайта. При их создании невозможно использовать визуальный редактор Visual Studio. Они более легкие.
8. Элементы управления пользователя представляют собой ASCX файлы, обрабатываемые аналогично ASPX страницам. Хранятся они в файловой системе веб-сервера и компилируются при каждом запросе к ним. Специально отведенная виртуальная директория для них: TEMPLATES/CONTROLTEMPLATES или _controltemplates.
9. Страница веб частей - это страница с призраком. Она содержит в себе лишь WebPartZone, а информация о том, какие там вебчасти и кастомизации вебчастей хранится в базе.
10. Элементы управления делегирования - это элементы, на месте которых устанавливаются контролы. В ЭУД указывается ControlID. Control с соответствующим ID заменяет ЭУД через активацию специфичной фичи. Замена может происходит на разных scope активации: ферма, веб-приложение, семейство сайтов, сайт.
11. master page также может быть "с призраком". При её изменении, она становится "без призрака". Поэтому лучше делать её на основе шаблона.
12. ~masterurl/default.master ссылается на _catalogs/masterpage/ + SPWeb.MasterUrl, ~masterurl/custom.master ссылается на _catalogs/masterpage/ + SPWeb.CustomMasterUrl. Для смены master page семейства сайтов необходимо рекурсией пройтись по всем узлам и поменять свойство MasterUrl
13. core.css лучше не менять и не использовать для создания брендинга. Этот файл может быть перезаписан при обновлении sharepoint. Для брендинга нужно использовать темы. Они представляют собой css файлы и графику, причем css файлы подключаются после core.css. Таким образом стили будут отрисовываться из css файла стилей, а не core.css. Все эти файлы хранятся в TEMPLATE\THEMES\THEMENAME. Когда пользователь выбирают тему узла, эти файлы копируются на узел и с ними можно работать как с любыми другими файлами, т.е. версионность и прочие плюшки. 
14. AlternateCssUrl в книги не объяснен. Следующие вопросы: Если назначить это свойство, то будет браться css по нему или будет браться "не alternate"(оригинальная css). Как после установки AlternateCssUrl вернуть все в зад? Ясно только одно - css файлы тем перекрывают AlternateCss