mod_rewrite адназначна.

Причем...
/index.html главная странца.
/1.html и т.д. - страницы материала (тоже надо делаьть)
/print.html -версия дл печати.
И еще одна фишка.
Вот есть главная категория, в ней ссылки на подкатегории:
/subcat1.html
/subcat2.html
А уже в категориях сслки на материалы:
/subcat2/mat1.html
/subcat2/mat2.html

а может просто:

Цитата

/ главная странца. /1/ - страницы материала (тоже надо делаьть) /print/ -версия дл печати. И еще одна фишка. Вот есть главная категория, в ней ссылки на подкатегории: /subcat1/ /subcat2/ А уже в категориях сслки на материалы: /subcat2/mat1/ /subcat2/mat2/

Пооисковикам лучше html ки гнать. К тому же это просто строка которая разбивается по / и последний по .

Цитата(Mal @ 20.6.2005, 19:11)

Пооисковикам лучше html ки гнать

по-моему им уже давно пофигу..
просто ссылка www.example.com/en/about/ на мой взгляд выглядит лучше чем www.example.com/en/about.html и набирать легче

Цитата(Irokez @ 20.6.2005, 20:14)

по-моему им уже давно пофигу..

Большинству - да.

Цитата(Irokez @ 20.6.2005, 20:14)

просто ссылка www.example.com/en/about/ на мой взгляд выглядит лучше чем www.example.com/en/about.html и набирать легче

А мне вот наоборот с html более, так сказать циыильной кажется.

Мне кажется что лучше все же не по id гнать категории и документы, а по алиасам, хотя можно учесть и тот и тот метод, кому как нравится.

Код

/index.html /my_category.html /my_category/my_category_document.html /sub_category/my_document_name.html

Если где то в документах идет постраничная разбивка, тогда нумеруем все это дело

Код

/my_category/sub_category/my_document_name-1.html /my_category/sub_category/my_document_name-2.html /my_category/sub_category/my_document_name-3.html

и т.п.

а вообще будет круто, если можно будет настраивать вид ЧПУ.. к примеру:
{domain}/{cat}/{subcat}/{doc}.html или
{domain}/{cat}/{subcat}/{doc}/

В своей CMF я делаю так:

1. через mod_rewrite все запросы на направляются на index.php (его я называю HTTP-контроллером)

2. есть xml-файл описания всех урлов и соответсвующий им последовательный процесс работы контроллеров:

Пример такого xml-файла:

Код

<scheme>    <url regexp="^(index\.htm)?$">       <process name="index" />       <process name="skin">          <var name="name" value="main" />       </process>    </url>    <url regexp="^news/([1-9][0-9]*)\.htm$">       <process name="news">          <var name="news_id" value="$1" />       </process>       <process name="skin">          <var name="name" value="work" />       </process>    </url>    <url regexp="^desktop/(.+?)\.htm$">       <process name="auth" />       <process name="desktop" />       <process name="skin">          <var name="name" value="work" />       </process>    </url>    <!-- ... ... ... -->    <url regexp="^(.+)$">       <process name="static">          <var name="path" value="$1" />       </process>       <process name="skin">          <var name="name" value="work" />       </process>    </url> </scheme>

process - это контроллер. Имея соответсвующий метод он сам знает как генерировать URI, поэтому я вообще никогда не задумываюсь об этом.

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

Например, все URL для реального сайта будут иметь вид:
http://www.example.com/контроллер/режим[-par1-par2-...-parN].htm
или
http://www.example.com/режим[-par1-par2-...-parN].htm

Я считаю такой подход крайне удобным.

Mace
index.php показать можешь?)
Добавлено @ 10:48
Мне нравится вариант Mace, кому то есть что добавить?

Цитата

Мне нравится вариант Mace

Имхо, в таком варианте проще добавить индивидульные свойства и настройки каждому разделу...

Opik, а в index.php собственно ничего и нету, кроме подключения "ядра", его создания, запуска метода обработки запрошенного URL. Код показывать не имеет смысла, т.к. надо прикладывать код всего ядра. Могу рассказать как все это работает в моей реализации.

Физически ядро веб-приложения представляет собой экземпляр класса (Core), главной задачей которого является обеспечение интерфейсов хранения и обмена данных. Данные в основном складываются из конфигурационных переменных и переменных, создаваемых в процессе работы компонентов. Для управления ядром служит специальный класс CoreController (контроллер ядра). Этот класс статический и все его методы доступны из любого места веб-приложения.

Вся работа веб-приложения происходит по этапам:

1. Инициализация
Создание ядра, анализ (парсинг) конфигурационного XML-файла и сохранение его данных, подключение дополнительных модулей и пр.

2. Обработка запроса
Последовательный поиск нужной ветки в схеме URL веб-приложения (в блоке <scheme/>) в зависимости от запрашиваемого URL. Имя ветки (атрибут regexp) - это регулярное выражение. С помощью него можно организовать удобную передачу параметров компонентам. Далее происходит последовательная отработка контроллеров (<process/>). Контроллер в связке с необходимыми компонентами может либо генерировать контент, либо произвести переадресацию, либо еще что-нибудь (в зависимости от конкретных задач). Как правило последним в этой цепочке идет контроллер, который получает сгенерированный ранее контент и выводит его в контексте обвязки сайта, за которую сам собственно и отвечает.

3. Завершение работы
Формальный этап, где отрабатывают деструкторы компонентов и уничтожение ядра.

Цитата(Mace @ 21.6.2005, 15:12)

2. есть xml-файл описания всех урлов и соответсвующий им последовательный процесс работы контроллеров:

А зачем это?

Цитата(Mal @ 25.6.2005, 15:21)

Цитата(Mace @ 21.6.2005, 15:12) 2. есть xml-файл описания всех урлов и соответсвующий им последовательный процесс работы контроллеров: А зачем это?

Зачем что ?
Зачем xml-файл или зачем вся эта городушка ?

Когда пользователь запрашивает страницу нам надо знать какие контроллеры будут формировать ему ответ. Классический случай - два контроллера: первый - генерирует контент, второй - макет страницы. Но контроллеры могут и не генерировать контент, а производить какие-либо действия в зависимости от условий (например, перенаправлять пользователя на определенную страницу). Поэтому цепочка может состоять из любого кол-ва контроллеров.

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

Или имелось в виду что то другое ?

Не люблю я ваши ЧПУ ЖПУ и т.д.
По мне так:

http://site.ru/?page=about
http://site.ru/?page=conent&id=1
http://site.ru/?news=1 (Пага)
http://site.ru/admin.php?op=users

Вот это хорошо... Кстати, ненавижу, мля, когжа что-то вроде этого:
http://site.ru/stories/4to_takoe_html_i_s_...dyat/index.html
Или что тов этом роде... Нада по id делать ссылки на контент...