подозреваю что при отправлении запроса в БД комментарии вырезаются автоматически.
а если даже и нет, то их можно вырезать перед отправкой вручную с помощью простого регекспа. но это уже дело вкуса.
в любом случае намешивать для запроса такую кучу конкатенаций как предлагает автор, для меня например — громоздко
непонял зачем так усложнять. почему вы не используете стандартные комментарии SQL:
— комментарий
ведь так еще проще:
$sql = "SELECT m.id, m.text --Выбираю ID и текст сообщения
, u.name, u.email -- Выбираю имя и email пользователя
FROM messages m -- Таблица сообщений
LEFT JOIN users u ON u.id=m.user_id
WHERE m.status=0 -- Со статусом 0 (прочитанные)
AND u.id='".$user_id."' -- Пользователя с указанным ID
ORDER BY m.date -- Сортировка по дате добавления сообщения
LIMIT 10 -- Выбираем 10 записей
";
и таже свобода в быстром отключении кусков запроса и комментировании
вы правы конечно.
просто в процессе написания алгоритма, с короткими переменными было проще, так как постоянно его менял и рефакторил) а в итоговом не додумался исправить
обновил код. теперь более длинные и осмысленные названия )
truecrypt — создает шифрованные диски
audacity — продвинутый аудио редактор, с кучей плагинов
mozilla songbird — аналог itunes :)
foxit reader — легкая и быстрая читалка pdf
MediaCoder — продвинутый видео-конвертор
cdex — аудио граббер
process explorer — продвинутый taskmanager, показывает запущенные процессы даже вирусов и троянов
tightvnc — аналог radmin
download master — аналог ReGet
…
>Начиная с 26 Октября 2007 г. юникодная разрабатываемая версия Far Manager 2.0 (ранее Far Manager 1.80) распространяется вместе с исходным кодом под модифицированной лицензией BSD.
ORM удобная весч. Но я бы вам не советовал привыкать его использовать в контроллерах или моделях Публичной части сайта.
Может быть только в реализации Админки сайта.
ORM в своей работе, обычно, ОЧЕНЬ активно посылает SQL-запросы, и даже для простых задач число запросов может исчисляться десятками… Для меня это много…
Может я старомоден ) но если при генерации страницы мой Движек делает более 7-10 запросов, то я начинаю нервничать и искать где что можно оптимизировать или закешировать…
в случае использования ORM такая гибкость исчезает, к сожалению…
в чем-то согласен.
Но использовать имеющиеся технологии и возможности надо на всю катушку.
Если щас сайт сидит на Апаче и там есть Реврайт, то какой смысл не использовать этот Реврайт? только потому что когда нибудь, через годик, может быть, сайт переедет на Нгинкс? )))
А вдруг он переедет на LightHttp?
А вдруг он вообще не переедет? )))
Зачем ограничить себя в возможностях?…
Если даже придется переехать, значит есть причины, значит необходима реорганизация структуры сервера, балансировка нагрузки, разделение динамики и статики… тут и без Реврайта очень много проблем и вопросов встанет. И переписать правила под Нгинкс или найти другое решение — это уже решит разработчик в момент когда столкнется с этими проблемами…
и скорее всего он в этом случае вообще уйдет в сторону Java, Django… которые в нагруженных проектах лучше себя показывают…
>А зачем переделывать красивые УРЛы, если их пхп и так поймет (после обработки в index'е)?
вот именно. Чтоб Пхп понял ему еще нужно будет запускать написанный вами парсер и роутер ( функционал которых значительно уступает модулю Реврайт)
и только потом начнет работать Скрипт отрабатывающий Бизнес-логику.
налицо велосипед!
> Ведь по сути, mod_rewrite делает просто разбор введенных параметров
Не только разбор! Реврайт может делать еще кучу нужных нужных действий над Урлами. Ваш самописный скрипт нуждо будет постоянно дописывать, при возникновении новых требований и условий для Урлов сайта. А с Реврайтом будет достаточно добавлять правила И ВСЕ! дописывать или переписывать чтото для этого не надо будет.
Реврайт не должен знать и он незнает )))
Он просто транслирует — красивые Урлы переделывает — В понятные и родные для ПХП…
что происходит далее, его неволнует…
>добавили контроллер -> надо переделать htaccess
не надо. Контроллеры работают по общему принципу. Именование разделов и Роутинг «на нормальном сайте» подчиняется логике.
Поэтому — ОДИН РАЗ пишется 10 правил в htaccess
а потом добавляйте хоть сотни Контроллеров… htaccess трогать уже не надо…
согласен. Но вы еще забываете о том что Реврайт помимо простого реврайта Урлов может делать еще очень многое! Такое, что в самописном фронт-контроллере реализация этого будет очень трудна и громоздка…
например:
1) на определенных Урлах — делать редирект
2) отдавать другие заголовки
3) перестраивать или заменять куски Урлов…
это бывает часто нужно при работе сайта. Да, это можно написать и самому, но ЗАЧЕМ?
Я несколько раз тоже пытался написать свой, Гибкий и Мощный Реврайтер в скрипте… И в процессе написания понял что у меня получается двойник mod_rewrite, причем значительно более примитивный…
я понял что теряю время )
#ORDER BY field1
или
--ORDER BY field1
а если даже и нет, то их можно вырезать перед отправкой вручную с помощью простого регекспа. но это уже дело вкуса.
в любом случае намешивать для запроса такую кучу конкатенаций как предлагает автор, для меня например — громоздко
— комментарий
ведь так еще проще:
и таже свобода в быстром отключении кусков запроса и комментировании
это и натолкнуло на создание еще одного велосипеда )
там как раз требуется суммы писать прописью
просто в процессе написания алгоритма, с короткими переменными было проще, так как постоянно его менял и рефакторил) а в итоговом не додумался исправить
обновил код. теперь более длинные и осмысленные названия )
но адекватных названий я придумать не смог — для временных переменных с индексами и флагами
truecrypt — создает шифрованные диски
audacity — продвинутый аудио редактор, с кучей плагинов
mozilla songbird — аналог itunes :)
foxit reader — легкая и быстрая читалка pdf
MediaCoder — продвинутый видео-конвертор
cdex — аудио граббер
process explorer — продвинутый taskmanager, показывает запущенные процессы даже вирусов и троянов
tightvnc — аналог radmin
download master — аналог ReGet
…
а как известно, BSD лицензии не ограничивают коммерческое использование продукта. ru.wikipedia.org/wiki/BSD_license
Может быть только в реализации Админки сайта.
ORM в своей работе, обычно, ОЧЕНЬ активно посылает SQL-запросы, и даже для простых задач число запросов может исчисляться десятками… Для меня это много…
Может я старомоден ) но если при генерации страницы мой Движек делает более 7-10 запросов, то я начинаю нервничать и искать где что можно оптимизировать или закешировать…
в случае использования ORM такая гибкость исчезает, к сожалению…
Но использовать имеющиеся технологии и возможности надо на всю катушку.
Если щас сайт сидит на Апаче и там есть Реврайт, то какой смысл не использовать этот Реврайт? только потому что когда нибудь, через годик, может быть, сайт переедет на Нгинкс? )))
А вдруг он переедет на LightHttp?
А вдруг он вообще не переедет? )))
Зачем ограничить себя в возможностях?…
Если даже придется переехать, значит есть причины, значит необходима реорганизация структуры сервера, балансировка нагрузки, разделение динамики и статики… тут и без Реврайта очень много проблем и вопросов встанет. И переписать правила под Нгинкс или найти другое решение — это уже решит разработчик в момент когда столкнется с этими проблемами…
и скорее всего он в этом случае вообще уйдет в сторону Java, Django… которые в нагруженных проектах лучше себя показывают…
вот именно. Чтоб Пхп понял ему еще нужно будет запускать написанный вами парсер и роутер ( функционал которых значительно уступает модулю Реврайт)
и только потом начнет работать Скрипт отрабатывающий Бизнес-логику.
налицо велосипед!
> Ведь по сути, mod_rewrite делает просто разбор введенных параметров
Не только разбор! Реврайт может делать еще кучу нужных нужных действий над Урлами. Ваш самописный скрипт нуждо будет постоянно дописывать, при возникновении новых требований и условий для Урлов сайта. А с Реврайтом будет достаточно добавлять правила И ВСЕ! дописывать или переписывать чтото для этого не надо будет.
пришли к консенсусу )
Он просто транслирует — красивые Урлы переделывает — В понятные и родные для ПХП…
что происходит далее, его неволнует…
>добавили контроллер -> надо переделать htaccess
не надо. Контроллеры работают по общему принципу. Именование разделов и Роутинг «на нормальном сайте» подчиняется логике.
Поэтому — ОДИН РАЗ пишется 10 правил в htaccess
а потом добавляйте хоть сотни Контроллеров… htaccess трогать уже не надо…
например:
1) на определенных Урлах — делать редирект
2) отдавать другие заголовки
3) перестраивать или заменять куски Урлов…
это бывает часто нужно при работе сайта. Да, это можно написать и самому, но ЗАЧЕМ?
Я несколько раз тоже пытался написать свой, Гибкий и Мощный Реврайтер в скрипте… И в процессе написания понял что у меня получается двойник mod_rewrite, причем значительно более примитивный…
я понял что теряю время )