Так тогда у вас как раз первый случай: "роутинг с привязкой по правилам маршрутизации компонентов"
Получается можно роутить вообще без БД (Добавление)
Впрочем переделывать роутинг будет смысл только тогда, когда вы сами почувствуете, что он дает просадки в скорости или не удовлетворяет каким-нибудь специфическим задачам
Так я и роутил изначально без БД по правилам, но мне это не подходит как выяснилось позже, так как добавился функционал, где удобнее именно так, как сделал роутить)
Скорость с роутингом из БД практически никак не влияет, 0.003 секунды разве можно ощутить?) А тестировал на 400к. записей в другой таблице по строковому полю, но думаю и с миллионом записей скорость не на много упадёт, раз на 400к все нормально, тут же не все правила подгружаются, а только одно на документ.
А еще не очень хорошо если есть страница site.ru/catalog/items/page/2/
но при этом нет например страницы site.ru/catalog/items/
На сколько я знаю поисковики это не сильно любят (Добавление)
А отсюда вытекает, что иметь роутинг с привязкой по правилам маршрутизации компонентов лучше, чем иметь "свободно редактируемый" роутинг
так структуру ЧПУ можно выстроить правильно, у меня во всяком случае она правильно выстраивается, на уровне компонента ссылки генерируются так: catalog, на уровне категории: catalog/cat, на уровне подкатегории: catalog/cat/subcat, и на уровне документа: catalog/cat/subcat/docname, так что всё правильно и по уровню вложенности.
Мне удобнее иметь именно такой роутер, нагрузок на базу никаких почти нет, поле с ЧПУ в таблице алиасов сделал индексируемым, запрос выполняется 0.003 сек
не должно быть подчеркиваний после каждой строки, да и лишние | после последнего столбца не нужны, но это не критично, а вот подчеркиваний быть не должно.
мой пример на основе файла, который привёл выше формирует запрос так:
miketomlin я уже решил то, что мне надо было, на входе получаю ЧПУ урл, вытаскиваю из базы json объект по этому улру, и работаю с ним, на мой взгляд это куда удобнее, чем работать с параметрами из ЧПУ пути, так как отпадает необходимость привязываться к структуре ЧПУ урл, урл может иметь такой, например, вид: blalba/blabla/catname/subcatname /articleblabla для любого компонента и, например, параметра id документа, а если работать с параметрами в самом ЧПУ урла, то нужно было бы эксплодить его и быть привязанным к явному обозначению в первом параметре, как к компоненту (blalba/), во втором к опции компонента (blalba/) и т.д., а с моим примером нет этой необходимости, урл может быть любым для любого компонента, опции, параметров.
И проблему дублей страниц тоже предусмотрел, в случае если не находится запись по ЧПУ, отдаю хедер 404 и показываю страницу ошибки, а ЧПУ и json объект формируется еще при добавлении/редактировании документа, поэтому там изначально никаких ошибок нет, и если ЧПУ найден, то значит всё в порядке и дальше. Но благодарю!
В начале файла подключения к базе
"config.php"в котором прописано подключения, здесь все работает. Только ошибку теперь выдает
Notice: Undefined offset:1 ...
Чего то ему не нравиться в $srt[1] в Insert?
А если страниц будет много, например, 10 к и более, запрос же будет долго выполняться...
Ну а в JoomlaSEF разве не по такой же логике работает?
Я, конечно, не знаю, что у вас за велосипед и какие задачи он(а) должна решать... Но я бы для удобства использования таблиц - использовал отдельное поле для хранения GET в виде json, отдельно ЧПУ линк, отдельно линк без ЧПУ. + может какие-то служебные данные типа кастомных мета-данных или еще что-либо... И конечно кэшировал бы всё, что существенно влияло бы на скорость обработки таких url.
JoomSEF не знаю все ли правила сразу подгружает, если все, то это не логично конечно.
А на счёт вашего совета, благодарю, так и поступлю, нет смысла по идее хранить линк с гет параметрами, можно всё в json объекте хранить, и ЧПУ в отдельном поле, можно было бы и титлы, кейвордсы с дескрипшн хранить тут же, но смысла не вижу, так как они уже хранятся в таблицах компонентов, и в шаблон из компонента подставляются. Сделаю в общем отдельную таблицу алиасов, и буду все правила хранить в ней, обращаться по 1-му запросу на документ, парсить json, его, кстати, можно загнать и в массив GET, чтобы получилось то, как в JoomSEF реализовано)) но не буду, смысла в этом не вижу, просто с объектом json и буду дальше работать. Плюсанул бы вам, но форум говорит, что недостаточно для этого отправленных сообщений.
Палка о 2 концах: либо используйте БД (но тогда будут просадки при большом кол-ве страниц), и JoomlaSEF не застрахована от этого как и любое приложение работающее с ЧПУ через БД. (а сама реализация - уже дело вашей фантазии)
Либо использовать правила роутинга для вашей CMS (будет выигрывать в скорости перед БД) (Добавление)
А у вас получается задача:
Хочу чтобы сайт грузился за 1 сек, при этом там 5 слайдров с неограниченным числом картинок с разрешением в 4к, и все это работало на бесплатном хостинге при посещении 100к уников
Ну в общем аллегорию вы поняли...
Ну в JoomSEF вроде не возникает проблем с большим количеством страниц, думаю, что правила перенаправлений нет смысла грузить сразу все, зачем это, когда можно при обращении по ЧПУ вытащить 1 правило, и уже с ним работать?
Сейчас пришла мысль, вытаскивать по ЧПУ из базы ссылку с гет параметрами, парсить их, и заносить в массив, и уже с ним работать в компонентах, буду пробовать в общем)
перенаправления ссылок с параметрами на ЧПУ, но при этом, чтобы в скриптах были доступны GET/POST переменные
Однако, для того, чтобы GET/POST переменные были доступны в скриптах, сервер должен получить соответствующую ссылку с параметрами и/или post-форму...
Иначе, в случае с семантическим URL - параметры определяются при обработке этого URL и пишутся в соответствующие 'хранилища' (параметры вызываемой далее функции, переменные, объекты, сессии, базу, etc).
Не писать же их в глобальные массивы $_GET и $_POST, в самом-то деле...
Я тоже это так понимаю, но вот в случае с JoomSEF всё как-то иначе реализовано, вызываешь документ по ЧПУ урлу, и при этом GET становится доступным внутри компонентов) (Добавление)
NeuroZ пишет:
1. POST доступен только если он был передан на конкретную страницу
2. GET доступен аналогично (но тогда рушится сам ЧПУ). Т.е. будет site.ru/catalog/page?id=3¶m=somedata&...
3. Чтобы избежать проблем в пункте 2 нужно создать с вой роутинг с правилами. Я могу расписать пример работу роутинга J! может это наведет вас на какие-то идеи, касательно вашей CMS.
Итак,
-При выключенном ЧПУ в url содержится весь GET запрос страницы и ее параметров.
-При включенном ЧПУ подключается файл router.php который переопределяется для каждого компонента.
А. Если такого файла нет, то действует стандартный J! роутинг.
В. Если нет пунктам меню (ItemID в GET), то первой частью url будет /component/
С. Далее (точно не помню) подставляется значения option из GET /option/
Д. Затем значение view из GET
Е. Все остальные GET переменные либо обрабатываются согласно правилам router.php либо идут как обычные GET параметры (как я описал выше в п.2)
Если надо отправить POST- то ничего общего с роутингом он не имеет. Есть опредленные правила парсинга переменных. Если в POST есть option и task разделенный точкой, то это значит, что запрос пойдет на контроллер с именем (первая часть task (до точки)) компонента option и вызовет там метод task (после точки).
Для наглядности
в action можно также подставить строку index.php?option=com_test&task=user.create - а в метод добавить переменную отвечающую за способ отправки get/post. И таким образом, если будет выбран get, то функционировать код не перестанет.
Но возвращаясь к описанию:
будет вызван метод create контроллера user.php из компонента com_test. Вот и все)
Благодарю конечно, но это тоже знаю, хотелось бы избежать создания роутинга для каждого компонента, и добиться того, как это реализовано в JoomSEF) а в нём при обращении к документу по ЧПУ урлу доступен GET со всеми сохраненными в нём переменными. Ладно, буду пробовать раскурить всё-таки JoomSEF изнутри, и ждать, может кто-то подскажет тут, как это реализовано в JoomSEF)
В Joomla 1.0 есть такой замечательный компонент JoomSEF, который позволяет делать именно подобное, в нём можно настроить переадресацию, в поле "Внутренняя сылка" занести любой внутренний URL с GET параметрами, а в поле "Новая SEF-ссылка" занести произвольный ЧПУ URL, и при обращении по этому произвольному ЧПУ URL в компоненте будут доступны те самые GET параметры.
1. В современной J! есть компонент SH404SEF но и он не панацея.
2. Как один из простых вариантов - можно еще попробовать использовать REQUEST вместо GET (но это не самый лучший выход при работе с ЧПУ)
nooblamer пишет:
в своей самописной CMS
А при чем тут тогда J! и его расширения? Или может имеется в виду самописный компонент?
nooblamer пишет:
Не понятно, как JoomSEF с этим справляется, пока не хватает уровня знаний, чтобы разобрать его осознанно)
Зато хватает, чтобы написать свою CMS ))) по-моему не с того вы начали))
А теперь самое главное: зачем все эти БД и прилюдии? Придумайте правило роутинга. У J! помимо сторонних компонентов есть своя система роутинга, которая прекрасно работает вообще без БД
Компонент не для Joomla, а для своей CMS)
Она полностью написана, на это действительно хватило знаний))
И есть роутинг более-менее приемлемый, но хотелось бы реализовать что-то подобное, как в JoomSEF, а цель этой реализации в том, чтобы автоматом генерировать ЧПУ для разных компонентов из генератора компонентов, который уже тоже дописал, и чтобы не быть привязанным к структуре генерируемых ЧПУ.
На мой взгляд это очень удобно, генерировать внутреннюю ссылку, и ЧПУ ссылку, вопрос только в том, как сделать перенаправления ссылок с параметрами на ЧПУ, но при этом, чтобы в скриптах были доступны GET/POST переменные.
Создаете табличку с алиасами, получаете на вход произвольный сео урл, ищете по нему в БД рабочий урл с гет параметрами, с ним и работаете.
Я примерно так и хочу сделать, но не понятно, как это реализовать в самих скриптах, нужно роутер какой-то писать, в котором подгружать все правила перенаправлений?
А если страниц будет много, например, 10 к и более, запрос же будет долго выполняться...
Не понятно, как JoomSEF с этим справляется, пока не хватает уровня знаний, чтобы разобрать его осознанно)
Может, подскажите, как это в коде именно реализовать, в htaccess я так понял, все запросы надо переадресовывать на индексный файл так:
Но еще, видимо, в коде, что-то нужно дописать мудреного, а что, пока не понимаю( Наверняка же не все правила роутинга вытаскивать из базы, если страниц будет много, то загружаться правила будут долго, что не есть хорошо.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 18
