Если я правильно все понял, то в первой части правила надо использовать что-то похожее на:
^/([a-z]+)\.html$ index.php?B=product&id=$1
правда в [a-z] надо указать все допустимые символы. Но это слишком упрощенное правило, если направление мысли я понял правильно, то его надо будет слегка подправить
вообще постановка вопроса с произвольным url - это в корне неправильно. ЧПУ изначально - приведение строки запроса в понятный юзеру вид. Да и проблемы потом возможны с дублями страниц и т.п.
Сам получаю все параметры из урл в скрипте - удобнее намного.
revered: VHS-1980, вы только что сказали минусы, хотя до этого, другие писали ссылки на уже существующие такого типа магазинов - и не чего, они же живут как-то и я думаю, что не плохо живут:)
Ни одной ссылки не увидел. Дайте ссылки на успешные магазины "обо всем", с такой же системой работы, которую Вы предлагаете.
Я поверю в возможную успешность проекта в том случае, если всем заниматься будете Вы сами, лишь беря за заказы с людей определенный процент. А вот если они сами должны будут заниматься наполнением магазина, сео, юзабилити... вообщем это будет бред. Но в этом случае никто не мешает Вам найти не компанию, которой за процент Вы будете сливать заказы, а поставщиков и отдел доставки + управляющего направлением, которые будут приносить Вам в разы больше прибыли.
- Проблема с сео (если не на поддоменах - то вообще лажа) - адаптация очень тяжелая будет под ПС.
- Проблема с наполнением - каждый товар по своему продается. Одному надо кучу характеристик, второму - определенную подачу, третий продается комплектом с еще десятком приблуд
- Проблема с пересечениями ассортимента магазинов - она вообще не решаема.
- Развитие - отдельная проблема. За Вас развивать никто не будет, а со стороны магазинов - ну кто будет всерьез вкладывать пусть даже и трудоресурсы в то, что он не контролирует, и ему не принадлежит.
Вообщем на мой взгляд слишком много минусов, слишком тяжело будет в реализации, очень тяжело будет в маркетинговом продвижении, чрезвычайно тяжело будет в поисковом продвижении и очень (ИМХО) скуден будет выхлоп. Имхо опять же, но за это время с многократно меньшими вложениями и денег и времени можно наштамповать с десяток своих магазинчиков и наслаждаться жизнью. По крайней мере отдача будет обязательно.
Busgame: При помощи чего можно запоминать посещенные ссылки?
Сразу прошу прощения, если задаю вопросы, ответы на которые очевидны.
При помощи записи в базу данных, записи в файл, наконец накопления в памяти (вариант для мазахистов, но все же). Все обработанные ссылки пишем куда надо, потом при проверке необходимости получения страницы сверяем ее url с записями в базе(файле, памяти) и если такой записи нет - заходим на страницу.
При этом не забудьте учитывать возможное добавление идентификатора сессий, иначе бродить придется до бесконечности.
Ссылку я дал. Интеграция еще проще, чем раньше - на том же сайте есть примеры. Работает очень быстро, переваривает очень большие объемы.
Но в главном я поддержу отписавшихся тут - если на Вас работает программист, если у Вас нет человека, администрирующего сервер - то и убить базу врядли у Вас получится, поэтому надобность в этом стремиться к нулю. В сложных ситуациях обойтись бэкапом из админки тоже врядли получится, поэтому придется прибегать пусть к единичным, но обращениям к специалисту.
nikonlay, мне кажется что Вы просто искали работу по интересам =) А то что Ваши навыки небыли бы востребованы полностью - это нормально. Покажите выпускника любого высшего учебного заведения, который в работе использует все знания, которые давались ему по программе обучения....
Просто у меня таких полей несколько, из трех таблиц надо выбрать.
---------- Добавлено 28.12.2012 в 18:38 ----------
Да нет, просто не хотелось городить кучу запросов к базе.
Не знаю для чего это Вам... На всякий случай можете проверить все запросы, по которым идут обращения при генерации страницы. В CMS зачастую запросы дублируются в различных модулях - возможно обойтись и без доп.запроса. Иногда проще сохранить в массив выборку и использовать ее глобально по всему коду генерации страницы.
Я для таких целей пользовался классом работы с БД и выводил все запросы с временем их генерации в отладочное окно. Потом проверял обращения к таблицам, выявлял избыточные, дублирующиеся запросы, тяжелые...
Но скажу точно - JOIN очень медленный и ресурсоемкий - лучше бОльше легких запросов использовать.
Не ломайте голову.
Во-первых нужно экранировать точку перед html.
Во-вторых для Вашей цели с перечисленными адресами регулярка будет работать.
Если действие выражения нужно ограничить только псевдокаталогом catalog - нужно немного ее модифицировать.
как то так, но я не спец по регуляркам - по идее должно работать
Если я правильно все понял, то в первой части правила надо использовать что-то похожее на:
правда в [a-z] надо указать все допустимые символы. Но это слишком упрощенное правило, если направление мысли я понял правильно, то его надо будет слегка подправить
вообще постановка вопроса с произвольным url - это в корне неправильно. ЧПУ изначально - приведение строки запроса в понятный юзеру вид. Да и проблемы потом возможны с дублями страниц и т.п.
Сам получаю все параметры из урл в скрипте - удобнее намного.
ИМХО чем короче url - тем лучше.
Редирект или перенаправление запроса на исполняемый скрипт с параметрами?
VHS-1980, вы только что сказали минусы, хотя до этого, другие писали ссылки на уже существующие такого типа магазинов - и не чего, они же живут как-то и я думаю, что не плохо живут:)
Ни одной ссылки не увидел. Дайте ссылки на успешные магазины "обо всем", с такой же системой работы, которую Вы предлагаете.
Я поверю в возможную успешность проекта в том случае, если всем заниматься будете Вы сами, лишь беря за заказы с людей определенный процент. А вот если они сами должны будут заниматься наполнением магазина, сео, юзабилити... вообщем это будет бред. Но в этом случае никто не мешает Вам найти не компанию, которой за процент Вы будете сливать заказы, а поставщиков и отдел доставки + управляющего направлением, которые будут приносить Вам в разы больше прибыли.
Я обозначу минусы (топик не читал):
- Проблема с сео (если не на поддоменах - то вообще лажа) - адаптация очень тяжелая будет под ПС.
- Проблема с наполнением - каждый товар по своему продается. Одному надо кучу характеристик, второму - определенную подачу, третий продается комплектом с еще десятком приблуд
- Проблема с пересечениями ассортимента магазинов - она вообще не решаема.
- Развитие - отдельная проблема. За Вас развивать никто не будет, а со стороны магазинов - ну кто будет всерьез вкладывать пусть даже и трудоресурсы в то, что он не контролирует, и ему не принадлежит.
Вообщем на мой взгляд слишком много минусов, слишком тяжело будет в реализации, очень тяжело будет в маркетинговом продвижении, чрезвычайно тяжело будет в поисковом продвижении и очень (ИМХО) скуден будет выхлоп. Имхо опять же, но за это время с многократно меньшими вложениями и денег и времени можно наштамповать с десяток своих магазинчиков и наслаждаться жизнью. По крайней мере отдача будет обязательно.
Вот схема таблиц
Получаем из формы материал.
Каждое поле, будь то GET или POST
Проверяем на нужное значение.
Может это и не очень удачное решение.
Фиг его знает..
if(preg_match('/[^0-9a-z_AZ]/',$_GET['category'])){ exit('<h1>Err. </h1>');}
if(preg_match('/[^0-9]/',$_GET['id'])){ exit('<h1>Err. </h1>');}
if(preg_match('/[^0-9a-z_AZ]/',$_GET['cpu'])){ exit('<h1>Err. </h1>');}
К стати возможно ли иницилизировать все переменные сразу в массив либо по другому, дабы не делать кучу isset ?
Можно. $_REQUEST.
При помощи чего можно запоминать посещенные ссылки?
Сразу прошу прощения, если задаю вопросы, ответы на которые очевидны.
При помощи записи в базу данных, записи в файл, наконец накопления в памяти (вариант для мазахистов, но все же). Все обработанные ссылки пишем куда надо, потом при проверке необходимости получения страницы сверяем ее url с записями в базе(файле, памяти) и если такой записи нет - заходим на страницу.
При этом не забудьте учитывать возможное добавление идентификатора сессий, иначе бродить придется до бесконечности.
Ссылку я дал. Интеграция еще проще, чем раньше - на том же сайте есть примеры. Работает очень быстро, переваривает очень большие объемы.
Но в главном я поддержу отписавшихся тут - если на Вас работает программист, если у Вас нет человека, администрирующего сервер - то и убить базу врядли у Вас получится, поэтому надобность в этом стремиться к нулю. В сложных ситуациях обойтись бэкапом из админки тоже врядли получится, поэтому придется прибегать пусть к единичным, но обращениям к специалисту.
nikonlay, мне кажется что Вы просто искали работу по интересам =) А то что Ваши навыки небыли бы востребованы полностью - это нормально. Покажите выпускника любого высшего учебного заведения, который в работе использует все знания, которые давались ему по программе обучения....
Ясно, сделаем 2 запроса.
Просто у меня таких полей несколько, из трех таблиц надо выбрать.
---------- Добавлено 28.12.2012 в 18:38 ----------
Да нет, просто не хотелось городить кучу запросов к базе.
Не знаю для чего это Вам... На всякий случай можете проверить все запросы, по которым идут обращения при генерации страницы. В CMS зачастую запросы дублируются в различных модулях - возможно обойтись и без доп.запроса. Иногда проще сохранить в массив выборку и использовать ее глобально по всему коду генерации страницы.
Я для таких целей пользовался классом работы с БД и выводил все запросы с временем их генерации в отладочное окно. Потом проверял обращения к таблицам, выявлял избыточные, дублирующиеся запросы, тяжелые...
Но скажу точно - JOIN очень медленный и ресурсоемкий - лучше бОльше легких запросов использовать.