Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > Vingrad CMS > ЧПУ


Автор: Opik 20.6.2005, 18:34
mod_rewrite адназначна.

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

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

Автор: Mal Hack 20.6.2005, 19:11
Пооисковикам лучше html ки гнать. К тому же это просто строка которая разбивается по / и последний по .

Автор: Irokez 20.6.2005, 19:14
Цитата(Mal @ 20.6.2005, 19:11)
Пооисковикам лучше html ки гнать

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

Автор: Mal Hack 20.6.2005, 19:18
Цитата(Irokez @ 20.6.2005, 20:14)
по-моему им уже давно пофигу..

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

Цитата(Irokez @ 20.6.2005, 20:14)
просто ссылка www.example.com/en/about/ на мой взгляд выглядит лучше чем www.example.com/en/about.html и набирать легче

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

Автор: IZ@TOP 20.6.2005, 19:20
Мне кажется что лучше все же не по 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


и т.п.

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

Автор: skalex 21.6.2005, 14:12
В своей 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

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

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

Автор: Dexter 25.6.2005, 11:09
Цитата
Мне нравится вариант Mace


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

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

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

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

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

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

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

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

А зачем это?

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

А зачем это?

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

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

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

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

Автор: CyClon 8.12.2005, 20:17
Не люблю я ваши ЧПУ ЖПУ и т.д.
По мне так:

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_4em_ero_edyat/index.html
Или что тов этом роде... Нада по id делать ссылки на контент...

Автор: Mal Hack 8.12.2005, 21:26
Ну мало ли что тебе не нравится.
Ты кодишь не для себя, а для пользователей.
Им легче запоминать без ?...

Автор: borisvolfson 15.1.2006, 19:46
CyClon
При сохранении файла будет не удобно искать файл по id...

Автор: IZ@TOP 23.1.2006, 00:09
По теме http://forum.vingrad.ru/index.php?showtopic=77474&view=findpost&p=624575

Автор: rMaveric 9.8.2006, 16:00
Прошу прощения, но вроде вы немного не стого конца начали. Должно быть представлено любыми способами, у каждого есть свои плюсы и у людей есть свои предпочтения. Главное как это будет внутри.

Основная "проблема" - как человеку показать, то что он хочет и дать удобный механизм работы с системой.

Иными словами требований 3:

1. Удобное добавление различных разделов и их администрирование
2. Создание разделов на основе различных обработчиков
3. Удобное создание самих обработчиков (модулей)

Но при этом каждый из параметров должен быть независимым. пример общей схемы и принципов обработки.

Пример трех ссылок которые должны отобразиться обсалютно одинаково

http://www.articles.sitename.domain/pc-tech/programing/php/new-zend-optimiser.001374.html
http://www.sitename.domain/pc-tech/articles/programing/php/new-zend-optimiser.001374.html
http://www.sitename.domain/articles/pc-tech/programing/php/new-zend-optimiser.001374.html

и CMS должна отобразить все три ссылки одинаково (при наличии всех нужных настроек).

З.Ы.
Если кого интересует могу описать подробно свое видение парсинга URL, а также связать с имеющимся механизмом вызова обработчиков (модулей), также могу предложить свой механизм с нуля.

Автор: Wowa 22.10.2006, 14:34
Цитата(IZ@TOP @  20.6.2005,  18:20 Найти цитируемый пост)
Мне кажется что лучше все же не по id гнать категории и документы, а по алиасам, хотя можно учесть и тот и тот метод, кому как нравится.


Цитата(IZ@TOP @  20.6.2005,  18:20 Найти цитируемый пост)
/index.html
/my_category.html
/my_category/my_category_document.html
/sub_category/my_document_name.html

А нагрузка? ИМХО выборка по ИД из базы будет намного быстрее, чем выборка по алиасу.

Автор: Semenov 23.10.2006, 09:03
По id будет быстрее, но, имхо, надо думать не только о скорости, также и о юзабильности. Еще нужно url`ы точить под поисковики, т.к. у яндекса и гугла в планах урлы их транслитизировать, для улучшения поиска. Т.е. , к примеру, /o_nas.html - это есть "о нас", но это, как уже сказал, в будущем. Но нужно быть далновидными. Если уж взяли xslt, то почему же ссылки не делать под будущее?

Автор: redlinesoft 24.1.2007, 20:23
Возвращаясь к вопросу о вариантах с .html  или без онного, то стоит взглянуть на сайты того же Лебедева - все ЧПУ прописываются без .html... А раз уж он напрямую сотрудничает с Яндексом, то сомневаться в верности данного подхода не приходиться.

Автор: IZ@TOP 5.2.2007, 15:59
Цитата(Wowa @  22.10.2006,  15:34 Найти цитируемый пост)
А нагрузка? ИМХО выборка по ИД из базы будет намного быстрее, чем выборка по алиасу. 

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

Автор: Wedmer 16.1.2009, 06:28
{domain}/{langcode}/{param1}/{param ....x}/

причем индексный скрипт должен обрабатывать $_SERVER['REQUEST_URI'] а не составной запрос.
Так мы избавимся от головной боли при использовании других httpd.

Автор: awers 14.2.2009, 09:14
Вот кусочек документа.

Цитата

Роутинг URL

Часть №1. «Порядок»

А. Регламентом определяется тип роутинга для каждого конкретного проекта
Б. Согласно регламенту реализуется роутинг


Часть №2. «Средства реализации»

А. Apache HTTP server. Подразумевается использование файла .htaccess
Б. PHP. Нежелательно использование в «чистом виде»
В. Смешанный тип (Apache + PHP)


 Часть №3. «Глобальные типы роутинга»

А. Роутинг отсутствует. Т.е. для получения страницы параметры передаются открытым GET запросом. К примеру — www.example.org/index.php?module=shop&catalog=64554
* Замечание: этот тип устарел и является наиболее уязвимым с точки зрения безопасности

Б. Каталожный роутинг. К примеру — www.example.org/shop/catalog/64554

В. Односложный роутинг. К примеру — www.example.org/shop-catalog-64554.html
В. 1. К минусам данного типа можно отнести ограничение в используемых именах модулей, названиях страниц и пр.
В. 2. Для этого типа роутинга необходимо дополнительно регламентировать «разделитель»

Часть №4. «Дополнительный тип роутинга»

Самым предпочтительным типом роутинга автор считает гибридный. Роутинг делится на два этапа:
1)    Первичный роутинг: на основании глобального роутинга выделяется вызываемый модуль
2)    Вторичный роутинг: модуль сам оперирует дальнейшей обработкой запроса

Преимущества данного способа заключаются в максимальной гибкости в рамках конкретного проекта.



В заключении этого документа автор считает нужным предложить использование следующей модели:

В качестве средств использовать «смешанные», в качестве основного глобального типа роутинга использовать «каталожный». При этом используя схемы «дополнительного роутинга».


За сим откланяюсь, Адам Адамович Четвёркин.
14.02.2009



ВотЪ )

Автор: fesor 17.7.2009, 12:05
Можно изложить свои идеи касательно реализации чпу?

Не проще ли реализовать систему маршрутов (по аналогии скажем с YII Framework). Это возможно не такой быстрый способ как mod_rewrite (хотя кто знает) однако появляется позможность проверять $_GET данные или формировать этот массив самостоятельно что должно повысить уровень безопасности.

Также это даст возможность пользователям изменять шаблоны путей.

По поводу того что доступ к страницам должен быть организован по алиасам - тут вопрос спорный. Доступ к категориям без сомнений должен быть по алиасам. Также как и к статическим страницам. Но допустем в новостной ленте использовать это имхо бред. НИРАЗУ невидел чтобы кто-то вводил название топика. Возможно такие люди и есть но назвать это дружелюностью для пользователя я не могу. Если имеются большие объемы контента то навигацию проще производить исключительно по ID.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)