Структура навигации WSS 3.0 - PullRequest
0 голосов
/ 26 марта 2010

Я новичок в WSS 3.0 и у меня возникли некоторые проблемы с настройкой навигации. Я не могу найти какую-либо документацию, которая явно рекомендует лучшие практики в этой области.

Я пытаюсь создать интранет, пользовательский внешний вид и структуру, которая должна иметь структуру, подобную:

Компания - Новости - Тип новостей 1 - Тип новостей 2 - Органограмма - ...

Сотрудники - Сотрудники 1 - Сотрудники 2 - Сотрудники 2_1 - ...

Как правильно настроить это? Компания, Новости, сайты / подсайты? А новости типа 1 и 2 являются страницами внутри сайта?

Я создал, как описано выше, и на главной странице основного сайта я добавил несколько сценариев, которые будут использоваться веб-частями, например, jquery. Дочерние сайты будут иметь свою собственную главную страницу и не будут распознавать сценарии, мне нужно добавить их туда, что раздражает.

Есть какие-нибудь рекомендации? Или какой-нибудь ресурс, который предоставляет лучшие практики по настройке этих структур?

Спасибо заранее

Ответы [ 3 ]

1 голос
/ 31 марта 2010

Я не могу рекомендовать лучший способ сделать это, но на самом деле есть несколько соображений о том, как разбить вещи:

Самое важное: Ознакомьтесь с Информационным центром по лучшим практикам Microsoft SharePoint . Он содержит массу полезной информации и гораздо больше, чем можно реально описать здесь.

Во-первых, , основной единицей хранения в бэкэнде является база данных контента, и обычно считается, что рекомендуется иметь одно семейство сайтов на базу данных контента. В вашем случае может иметь смысл иметь два или более семейства сайтов - одно для компании и одно для сотрудников (и все остальное).

Второй , охрана. Большинство вещей отчасти наследуют дерево от сайта, но я легко могу представить необходимость предоставления другого набора разрешений для разделов «Компания» и «Сотрудник», и, возможно, даже для Сотрудников 1 и 2 (принимая во внимание, что они могут означать такие вещи, как HR, Услуги и т. Д.). В идеале было бы неплохо изложить вещи таким образом, чтобы логически следовать иерархии или процессу вашей компании.

http://Server/Company/News
http://Server/Company/Blog
http://Server/Employees/HR
http://Server/Employees/Facilities
http://Server/Divisions/IT
http://Server/Divisions/Sales
http://Server/Divisions/Management

В приведенном выше макете вы создадите «Управляемые пути» в инструменте «Центральный администратор» для компании, сотрудников и подразделений, а затем создадите семейства сайтов для новостей, блога и т. Д. *

Третий , нужно ли сайтам обмениваться информацией? Немного сложнее обмениваться информацией через границы семейства сайтов - хотя, конечно, не невозможно. Хотя это поможет вам лучше масштабироваться и расширяться, это может не стоить дополнительных усилий.

В-четвертых , функции публикации - это то, что вы обязательно должны изучить, чтобы получить контент на сайте. Он предоставляет множество приятных функций, которые позволяют конечным пользователям легко добавлять контент для публикации, присоединять его к рабочему процессу для утверждения, и вы даже можете указать время, когда вы хотите, чтобы новые страницы были запущены (хотя это может быть только функция MOSS) ,

0 голосов
/ 29 марта 2010

Я бы сделал каждую тему сайтом, новостями, компанией и т. Д.

Но вместо того, чтобы делать 100 страниц, классифицируйте их на своем сайте. Вот так:

Сотрудники: Отдел (отдел кадров): Подотдел (фонд заработной платы): Employee1_page

Новости: Местные новости: май2010: Local_News 1_page

Новости: Новости рынка: февраль2010: Market_News 1_page

Создайте главную главную страницу локального сайта и примените главную страницу к каждому сайту, предполагая, что они будут одинаковыми. Вы можете использовать SP Designer для копирования / вставки мастер-страниц для дополнительного разочарования в качестве крайней меры, но, конечно, это плохая практика.

0 голосов
/ 29 марта 2010

Это действительно зависит от организации, для чего вы хотите использовать свои сайты, какова будет ваша структура безопасности и т. Д., Поэтому нет однозначного ответа. Любая лучшая практика пойдет только на вашу уникальную ситуацию.

Просто дикий удар в темноте, я бы сделал все подсайты, кроме:

  • Все, что является автономным сайтом, например, «сайт проекта» - и может расти очень-очень-очень большим (например, их общий объем будет превышать 40-50 ГБ) или действительно нуждается в собственной сложной структуре безопасности. Я бы создал их как свои семейства сайтов.
  • Новости. Вы можете создать сайт 1 News и добавлять разные типы новостей, используя другой тип контента (и макет страницы). Если у вас нет 2 групп пользователей, добавляющих эти новости, в этом случае я бы сделал отдельный сайт новостей для каждой группы.

Вы можете добавить .js или .css к каждой странице, используя делегированный элемент управления. Смотрите этот пост.

...