если ты знаешь Ruby то PHP ты не знаешь например так как языки очень сильно различаются. Мне вот кажется что если хорошо знаешь один язык то переключиться на другой не составляет проблемы. Всех особенностей не выяснить без практики но в общих чертах...
FanatPHP: вы думаете дело только в поддержке наследования? Если не брать в расчет синтаксис (ибо это очень субъективно) код смарти просто ужасен. Расширять синтаксис довольно тяжко. В twig же можно определять свои ноды, расширять парсер как вздумается, покрывать все это тестами без кастылей... Словом... помимо того что из коробки он поддерживает почти все что нужно, можно добавлять свой синтаксический сахар по мере необходимости без адской боли.
Я пользовался твигом в последний раз где-то 5 лет назад... Посмотрев код 3-ей версии я особо изменений не увидел. Считаю это решение относящимся к рудементарной ветви PHP, PHP старых дней.... Словом... как-то так.
Александр Марченко: еще нужно отметить что сервис $http является низкоуровневым и у вас по хорошему должна быть какая-то обертка над ним для своей API. При покрытии оной тестами мы можем при помощи $httpBackend входящей в ngMock проверять точно ли он конструирует запросы, как реагирует на ответы и т.д. При покрытии юнит тестами других ваших сервисов, мы мокаем уже наш сервис прослойку, нашу высокоуровневую обертку.
При e2e и реализации из ngMockE2E уже можно описывать именно реализацию сервера, это тупо стаб. Там нет разницы в каком порядке вы что вызываете.
Для начала давайте определимся, есть 2 реализации $httpBackend. Одна относится к ngMock а вторая к ngMockE2E. Первая используется для юнит тестов а вторая для E2E тестов.
Начнем с того что обе реализации должны использоваться только для тестов. То есть если вы ведете разработку через тестирование то все ок. Но если вы захотите проверить результат в браузере без апишки у вас всеравно ничего не будет работать. Можно эту проблему решить застабив данные на уровне какого-нибудь прокси сервера на node.js Если вы используете gulp то подобное можно сделать при помощи gulp-webserver (для grunt тоже есть что-то подобное наверное) довольно легко, сделав внутри проверку, что мол если у нас такой-то запрос туда-то то мы вернем тупо свой ответ, а если нет - отправим дальше на бэкэнд. В этом случае мы можем использовать реальный API и стабить только отсутствующие методы.
Suntechnic: мне больше нравится идея что красота должна быть внутри... исходники должны быть прекрасны словно эльфы первых дней, а при деплое их ловит Мелькор и превращает в уродливых орков... зато эффективных.
Suntechnic: ну и опять же, вас никто не заставляет так делать, просто все что подключается в head будет блокировать отрисовку страницы. Если у вас цель загрузить страничку, открыть исходный код и радоваться - то да, эти советы плохие. Если же вам нужно что бы до момента отображения контента проходило минимум времени - приходится понять и простить.
asd111: человеку достаточно заменить mysql_* функции на PDO и делать вывод данных через twig для начала. Ну и да, для начала лучше уж что-то типа Silex что бы не обременять человека новыми вещами. Там и так будет достаточно новых вещей, просто не будет награмождения знаний о тонких контроллерах, DI и т.д.
А когда человек разберется с маршрутизацией и twig и возможно еще с парой вещей, можно будет уже переходить на штуки типа Symfony2, которые введут еще очень много понятий. Если же брать сразу Symfony2 и подходить к процессу обучения нормально, пройдет довольно много времени между "начал изучать" и "что-то получилось". И за это время человек может потерять мативацию и забить. Ну или нужно что бы кто-то постоянно над душой стоял.
kirill-93: ну можно тогда для верности через array_values прогнать. Но это уже автору вопроса решать. Я в принципе против использования for для подобных вещей.
