Он работает по-разному, вот в чем беда. В двух разных состояниях он может дать два разных результата. Если всё так просто, как вы говорите, неужели никто не написал какой-то анализатор благозвучности? Ну чисто профессиональный интерес уже =)
А вообще странно. Вот если написать технический пост с использованием какого-то ЯП и допустить в листинге синтаксические ошибки — никто же не будет говорить: «О да, ты гавнокодер, пишешь пост про Джаву, а её не знаешь. А вот я уже с закрытыми глазами лучше пишу!»
Имхо, проблема грамар-наци, в том, что они флудят и уводят разговор от сути. Укажите автору на ошибки, он поправит. Но зачем унижать его, да ещё публично состязаться в грамотности? Честно, ваши перепалки с «ться-тся» «достаточно-достаточного» никому не интересны. Придирайтесь к сути, пожалуйста. А то орфографию легко исправить, а суть — нет.
Кстати, есть вопрос. По пункту 2 хотелось бы узнать, каким именно анализатором можно проверить то самое «благозвучие». А то я как-то не вижу пока объективных критериев и где бы о них узнать.
Вау! Это замечательно. Функциональное программирование на PHP это круто ) А ещё круто, что ваше решение очень компактно и синтаксически вкусно. Есть конечно, небольшая проблема с тем, что юзаются функции, но думаю в 90% это не вызовет проблем.
Ну я не обращался лично к вам. Многим людям понравится зендовский роутинг.
Но решая рутинные задачи вроде писать массив и вставлять туда регексовые значения в нужные скобочки, я не вижу никаких творческих или интеллектуальных задач. Роутер Зенда из средины 2000-ых. Осиливать там нечего, скорее нужно вспоминать.
Если про плюсы-минусы в Зенде.
— поддержка кода. Когда в проекте 100 роутов, то задавая каждый таким массивом вы закопаетесь. Будет легко что-то сломать, сложно добавить, сложно найти и исправить.
— избыточность данных с тем же регексом.
— слабая защищенность от ошибок в рантайме (IDE не подскажет, что тот или иной конфиг-ключ написан не так)
— кол-во кода которое нужно написать для решения элементарной задачи.
Чем больше кода, тем сложнее его поддерживать, развивать, читать. Это для меня главное правило.
В рельсах есть как и прикольные шорткаты в виде ресурсов, так и возможности по кастомизации. Проблема Зенда в том, что предоставляя все наборы кастомизации можно было предложить и пару типичных решений типичных проблем. Имхо за тем и нужны фреймворки. Чтобы решать типичные проблемы.
А теперь, если возьмем средний рейт разработчика 20 долларов в час и посчитаем сколько стоит «В зенде вы точно так же можете написать свой тип маршрута». Вам не кажется что, это такой древний русский подход, предусматривающий фазу тщательной обработки напильником?
Просто это частный случай решения проблемы и за пределами рельсов, видимо, мало кому нужный (например для меня это довольно не удобный способ).
Мнение основано на личных стереотипах.
Ну если так, посмотрите ещё на симфоневский роутинг. Он тоже лучше.
Да. но просто читабельность теряется. Да и как говорится: если вы решаете проблему с помощью регулярных выражений, то у вас уже две проблемы ) Но вцелом, на вкус и цвет…
Ага, добавлять можно, но по скорости всё равно лучше делать все в массивых. Или как-то настраивать кеширование.
Суть в том, что по дефолту, всё это сложно, и необходимо допиливать, как в старом анекдоте.
На больших я и сам бы не рискнул, но как-то товарищ показал полноценный REST-сервер (обработка, валидация и сохранение в БД нескольких ресурсов) в один файл и я офигел. Не знаю как там со сложными штуками типа Hypermedia, или HATEOS, но для простых json выглядит круто.
Если честно, с REST в Symfony2 не работал, но реализация REST серверов на той же ноде в свое время просто поразила своей простотой. Может я не прав, но учитывая, что json это нативный формат для js, то таких проблем с сериализацией там впринципе нет. Не смотрели ли вы в сторону ноды?
А вообще странно. Вот если написать технический пост с использованием какого-то ЯП и допустить в листинге синтаксические ошибки — никто же не будет говорить: «О да, ты гавнокодер, пишешь пост про Джаву, а её не знаешь. А вот я уже с закрытыми глазами лучше пишу!»
Имхо, проблема грамар-наци, в том, что они флудят и уводят разговор от сути. Укажите автору на ошибки, он поправит. Но зачем унижать его, да ещё публично состязаться в грамотности? Честно, ваши перепалки с «ться-тся» «достаточно-достаточного» никому не интересны. Придирайтесь к сути, пожалуйста. А то орфографию легко исправить, а суть — нет.
Кстати, есть вопрос. По пункту 2 хотелось бы узнать, каким именно анализатором можно проверить то самое «благозвучие». А то я как-то не вижу пока объективных критериев и где бы о них узнать.
Но решая рутинные задачи вроде писать массив и вставлять туда регексовые значения в нужные скобочки, я не вижу никаких творческих или интеллектуальных задач. Роутер Зенда из средины 2000-ых. Осиливать там нечего, скорее нужно вспоминать.
Если про плюсы-минусы в Зенде.
— поддержка кода. Когда в проекте 100 роутов, то задавая каждый таким массивом вы закопаетесь. Будет легко что-то сломать, сложно добавить, сложно найти и исправить.
— избыточность данных с тем же регексом.
— слабая защищенность от ошибок в рантайме (IDE не подскажет, что тот или иной конфиг-ключ написан не так)
— кол-во кода которое нужно написать для решения элементарной задачи.
Чем больше кода, тем сложнее его поддерживать, развивать, читать. Это для меня главное правило.
В рельсах есть как и прикольные шорткаты в виде ресурсов, так и возможности по кастомизации. Проблема Зенда в том, что предоставляя все наборы кастомизации можно было предложить и пару типичных решений типичных проблем. Имхо за тем и нужны фреймворки. Чтобы решать типичные проблемы.
Мнение основано на личных стереотипах.
Ну если так, посмотрите ещё на симфоневский роутинг. Он тоже лучше.
Суть в том, что по дефолту, всё это сложно, и необходимо допиливать, как в старом анекдоте.
в рельсах задается одной строчкой:
Всё! Если это не преимущество, а круто писать многомерные массивы с кучей конфиг-значений, то скорее всего вам платят за кол-во строчек кода.
Заметьте, это ещё только Getting Started.
А ведь и правда, получается: «We hear Symfony doesn't have this problem».
Ок.
Если честно, с REST в Symfony2 не работал, но реализация REST серверов на той же ноде в свое время просто поразила своей простотой. Может я не прав, но учитывая, что json это нативный формат для js, то таких проблем с сериализацией там впринципе нет. Не смотрели ли вы в сторону ноды?