Незачто, для вас и делался. Перетащить несколько можно уже в собранном состоянии. Я думаю, чуть позже просто добавится виджет выделения группы для перемещения.
Эм… Вы уж простите за оффтопик, но первое, что бросилось в глаза — это отсутствие FOREIGN KEY's во всех таблицах БД и, соответственно, использование MyISAM.
Вы действительно настолько уверенны в PHP и konaha, что готовы переложить на него полностью всю заботу о синхронизации данных в БД? Не страшно?
1. Этот тест показывает, что в скорости работы МОЖНО выиграть путем работы с mod_rewrite БЕЗ PHP-парсера URL'ов. Это важно для очень критичных к нагрузкам приложений. И это обозначено в первом пункте статьи.
Выложил тест. Он не уповает на объективность, но сходу что-то более объективное мне не придумалось. Если у вас есть еще какие-либо варианты Test Case'ов — описывайте, с удовольствием протестирую и их.
Таким образом разработчик сам себе роет могилу. Точнее не себе, а другим разработчикам, которые прийдут после него и которым заказчик будет говорить «а я вот тут с СЕО общался, а они мне посоветовали, а я сделал — и все сломалось! Поправь пожалуйста, а то все умрем!».
Без нормальной карты перемещений по сайту вы будете долго понимать и разбирать, где в скрипте и что должно куда вести и как, с какими параметрами и т.д. и т.п.
А так заглянул в htaccess, нашел нужный реврайт и смотришь, куда ушло обращение.
Хм. Мне кажется такой путь решения неправилен. Т.е. возлагать такие задачи на скрипт — неуместно. Я могу ошибаться, но я бы так никогда не поступил. И такое решение, да, имеет право на жизнь, но я бы не стал им пользоваться. Я всегда привык видеть перед глазами карту сайта и понимать, куда мой пользователь может пойти, а не разбираться, что же где и куда положено, и как это в конце концов нас привело не к товару, а на порносайт… ^_^
Вы немного неправы. Здесь не факт, что PHPшный intval($var) будет работать быстрее — это раз. Хотя тут, исправьте меня, я могу ошибаться. Второе — будет необходимо городить механизм фильтрации, в котором именно будет присутствовать этот intval() и в соответствии с которым будет определяться, что именно этому $var нужно сделать intval().
В случае «горожения регулярок» нужда в механизме фильтрации для управляющих GET-запросов отпадает.
Т.е. вы этих плюсов не видите?
Универсальные рулесы — зло ^_^ И, снова таки, использование универсальных реврайтов «на все случаи жизни» — скорее от незнания, чем от желания перенести все в одно место и управлять всем из скрипта.
На самом деле идеология проста — использовать инструменты для того, для чего они предназначены.
1. В случае крупного проекта это уже не ошибка идеологов mod_rewrite, это скорее ошибка идеологов проекта. Я больше склоняюсь к такой позиции. Ибо при нормальном архитектурном планировании задач с регуляркой на сотню правил можно избежать.
2. Сейчас как раз занят тестами.
3. Я не говорил, что это правильный путь ^_~. Но он тоже возможен.
4. POST — данные и их фильтрация — отдельная задача, совершенно к mod_rewrite никак не относящаяся. И о фильтрации я говорил в плане управляющего GET-запроса. Соответственно, весь POST через mod_rewrite всегда проходил и будет проходить незатронутым.
Резюмируя, могу сказать, что это не «вынесение» скриптовой логики. Это разумное разделение управляющих конструкций, по которым ваш пользователь будет обращаться к сайту и конечной логики, которая запрос пользователя будет обрабатывать. При том, при просмотре того же .htaccess становится вполне понятно, почему у юзера вылезла кракозябла при обращении к такому-то URL. Соответственно, программист сотни раз не возвращается к URL-парсеру и не пытается понять, каким шаманским бубном этот параметр привел совершенно в другой модуль.
Вы действительно настолько уверенны в PHP и konaha, что готовы переложить на него полностью всю заботу о синхронизации данных в БД? Не страшно?
Остальные — 5 секунд.
Я бы сказал — не менее запутанную, а более понятную ^_^
Без нормальной карты перемещений по сайту вы будете долго понимать и разбирать, где в скрипте и что должно куда вести и как, с какими параметрами и т.д. и т.п.
А так заглянул в htaccess, нашел нужный реврайт и смотришь, куда ушло обращение.
В случае «горожения регулярок» нужда в механизме фильтрации для управляющих GET-запросов отпадает.
Универсальные рулесы — зло ^_^ И, снова таки, использование универсальных реврайтов «на все случаи жизни» — скорее от незнания, чем от желания перенести все в одно место и управлять всем из скрипта.
1. В случае крупного проекта это уже не ошибка идеологов mod_rewrite, это скорее ошибка идеологов проекта. Я больше склоняюсь к такой позиции. Ибо при нормальном архитектурном планировании задач с регуляркой на сотню правил можно избежать.
2. Сейчас как раз занят тестами.
3. Я не говорил, что это правильный путь ^_~. Но он тоже возможен.
4. POST — данные и их фильтрация — отдельная задача, совершенно к mod_rewrite никак не относящаяся. И о фильтрации я говорил в плане управляющего GET-запроса. Соответственно, весь POST через mod_rewrite всегда проходил и будет проходить незатронутым.
Резюмируя, могу сказать, что это не «вынесение» скриптовой логики. Это разумное разделение управляющих конструкций, по которым ваш пользователь будет обращаться к сайту и конечной логики, которая запрос пользователя будет обрабатывать. При том, при просмотре того же .htaccess становится вполне понятно, почему у юзера вылезла кракозябла при обращении к такому-то URL. Соответственно, программист сотни раз не возвращается к URL-парсеру и не пытается понять, каким шаманским бубном этот параметр привел совершенно в другой модуль.