@FanatPHP: да нет, max/min и чуть чуть упороться по математике + range для генерации массивов и у нас ни одного условия для простой пагинации) Ну как, одно условие будет - текущая ли страница или нет. Опять же хелпер для этого можно сделать. В любом случае это не проблема, в контексте вопроса ничего не поможет.
Nick Murzin: да... я забыл что еще так можно писать на PHP... у меня пропало желание разбираться, извините.
А по поводу ошибок из контроллера. что вы имеете в виду? Крутые ребята выкидывают из контроллера исключения которые обрабатываются во фронт-контроллере и вызывается отдельный метод который рендрит страничку с ошибкой. Или опять же какие-то хелперы типа flashMessages и т.д.
@FanatPHP: я понимаю что такое пагинация и не припомню что бы мне приходилось делать массу условий для пагинации. Массив со ссылками готовить не нужно. Достаточно простых операций деления и всякие min/max что бы упростить логику.
Подготовку данных в контроллере выполнять пожалуй не стоит... иначе мы перекладываем обязанность по формированию представления частично на контроллеры. Так что мне больше импонирует вариант с хелперами.
@uaKorona: извините, в потоке нотификаций упустил ваш комментарий. Можете привести пример одной из ваших 3К директив?
Если я правильно понимаю задачу, вы хотите что бы формы можно было настраивать на сервере и генерить на клиенте. Если это так, то я бы делал так: на сервере конфиг для директивы в формате json, у нас есть сервис который умеет по id нашей формы или еще как-то загружать эти настройки и формировать темплейт формы. Этот сервис использует директива myForm или что-то в этом духе, которая в зависимости от значений атрибутов дергает сервис. В итоге контроллеры нам не нужны. Либо этот контроллер будет к myForm директивы.
@nepster09: То о чем вы говорите это не Yii vs Symfony а ActiveRecord vs DataMapper или если хотите RAD vs ООП. Видели шутку про три самых важных слова? Инкапсуляция, наследование и полиморфизм. Так вот, публичные поля, которые доступны на запись откуда угодно, это нарушение инкапсуляции. В php7 хотят вот ввести readonly модификатор доступа и эта проблема для Yii будет решена. Да и вам никто не мешает сделать для ваших сущностей базовый класс с __get/__set атрибутами которые имеют доступ к protected полям. Хотя я опять же не рекомендую так делать так как возникнут проблемы с формами и вообще.
На самом деле это вообще не проблема а только плюс. Вы проектируете не базу данных а классы, сущности которыми будет оперировать бизнес логика вашего приложения. Есть такая штука, DDD называется. Domain Driven Design (не development). То есть мы начинаем проектировать систему не с сервисов/контроллеров/баз данных, а именно с наших доменных моделей. Формируем связи между ними, суровые дядьки делают это при помощи UML и т.д. Причем то как данных хранятся можно решить потом, когда выстроится структура приложения и описать в мэппинге. А в сеттерах/геттерах проводить какую-то минимальную валидацию и конвертацию данных. Делать параметризованные сеттеры, делать нормальные конструкторы (например класс Post принимает в конструктор объект типа User и не дает нам создать пост не указав автора).
Это позволяет добиться того, что мы уменьшаем количество потенциальных ошибок а так же если проект реально серьезный, мы можем обеспечить ему статический анализ (если это можно так назвать, все же без статического тайпхинтинга сложно это сделать) и в автоматическом режиме искать места потенциальных ошибок (например инстанцирования того же Post без передачи ему пользователя, или неверный порядок аргументов или что-то в этом духе).
Если же вы не паритесь, нормальная IDE умеет генерить геттеры и сеттеры для полей класса. Я жалею немного что в 2012-ом не приняли RFC сокращенного синтаксиса геттеров/сеттеров... тогда было бы как в c# или js... и код был бы няшнее... и readonly не нужны были... но видимо на то были причины, я если честно не разбирался почему отказались.
Если active record вам нравится больше, можете посмотреть в сторону Propel-а или переключиться на Laravel - на нем можно писать такой же качественный код как на symfony (с оговорками конечно)... правда если учиться по их документации и статьям по этому фреймворку шансов на это малова-то...
Что до xml vs json - ой как вы не правы. json тупой формат. xml - универсальный. XML имеет одно огромное преимущество перед json - атрибуты. У JSON у вас на вооружении только массивы и объекты. Если вы в поле объекта храните строку, а в один прекрасный день строка заменилась на массив строк, то клиент парсящий этот json и обрабатывающий данные сломается, так как он все еще ожидает увидеть строку. С XML у нас был один элемент со строкой - а стало несколько. XPath выберет первый элемент как выбирал до этого и все будет хорошо. Это решает огромную проблему с версионизацией API сервисов... но всем пофиг, json же проще парсить. Так же за счет отсутствия атрибутов в JSON люди придумывают кучу кастылей для реализации штук типа hateous и т.д. Короче... зачем использовать XML? Во славу REST конечно! Проблему версионизации конфигов оно так же решает...
В любом случае json и xml это форматы для машин, yaml - для людей. Опять же в IDE для них есть автокомплит в контексте конфигов Symfony2. Ну и опять же - просто вам нужно привыкнуть.
assetic меня тоже напрягает... потому не использую его, собираю все gulp-ом. Как в прочем и на yii когда-то grunt-ом собирал асеты ибо терпеть не мог этот ущербный AssetManager.
Что до того что контроллер всегда должен возвращать ответ - это логично. Как работает клиент-сервертая архитектура? Клиент отправляет запрос на сервер и хочет получить ответ. Объект Response инкапсулирует в себе HTTP ответ а Request - HTTP запрос. Что это нам дает? Мы обстрагируемся от SAPI которое использует разработчик. Все унифицировано и т.д. Более того, если вы используете php-fpm, то Symfony после того как получит объект Response отдаст его и скажет php-fpm-у что ответ отправлен, больше ничего не жди. И php-fpm отправит это в вэб сервер а тот клиенту, то есть запрос завершен. НО PHP все еще продожлает работать, например отправлять почту, генерить превьюшки для постов и т.д. То есть все тежелые операции которые не влияют на ответ можно отложить на событие kernel.terminate. Собственно swiftmailer почту там отправляет и время отправки почты не влияет на время запроса с клиента.
Так же есть такая вещь как middlewares. То есть мы можем делать слоеный пирог из приложения. Один слой берет запрос, добавляет к нему что-то или забирает и передает другому слою. Скажем мы можем выделить в отедльный слой все что связано с проверкой прав доступа и авторизации (в symfony оно так и работает но в рамках одного слоя и на ивентах). То есть контроллеру вообще об этом париться не нужно. Ну или типичный пример для API - добавить поддержку CORS можно просто подключив одной строчкой middleware (ну или поставить бандл... не суть).
В Yii же у вас была абстракция над запросом... и то она просто брала данные из SAPI PHP и верило ему наслово. Никакого изыска. Так как все выводится простым echo перехватить и обрабоать запрос можно было только кастылями и тд. Короче ад... особенно в плохих руках.
По поводу именования actionIndex и indexAction - открою вам маааленький секрет. Это имеет какое-то значение только если вы конфиги маршрутизации в yaml храните для этих экшенов. А так называйте метод как хотите, правило маршрутизации за ним всерано закрепится. Так что называйте хоть так хоть эдак хоть megaSuperIndexAction.
Что до шаблонизаторов - я в одном из вопросов описывал, можете почитать. Вообще если вы научитесь пользоваться Twig-ом писать на plain-php шаблоны вам больше никогда не захочется. Наследование, фильры, автоэскейпинг... ух... И вы не представляете какой я испытал восторг в свое время когда смог всего за пару часов разобраться как расширять парсер своим синтаксисом, блоки свои делать, какую-то свою хитрую логику сборки и компиляции шаблонов... И да, зная twig вы автоматом сможете выучить шаблонизатор jinja для python в случае если вам когда-нибудь придется столкнуться с ansible.
Опять же миграции - это фича доктрины и только ее. Для меня это жирнющий плюс, то что я могу добавить сущность или поле у сущности, сделать migration:diff и просто слегонца поправить миграцию... и все будет хорошо... и у всех все будет хорошо. Я если честно начинаю подзабывать SQL-ые ALTER TABLE с такими делами...
В Yii все проще с формами и валидацией... потому что форм там нет... а валидация совмещена с сущностями. Я помню меня немного напрягало что в Yii1 почти никто не использовал форм билдер, хоть он там и был. А потом я поработал с Symfony Forms и понял почему никто им не пользовался - он ущербный и бесполезный в большинстве случаев. А на Symfony Forms вы можете реализовать вообще любую форму, покрыть это дело тестами и не вставлять кастылей. Правда этот компонент пожалуй самый сложный и может порвать ваш мозг пока вы вьедите во всю прелесть оного... Для простеньких форм в принципе ничего страшного там нет. В случае с валидацией все довольно просто - не вижу смысла останавливаться на ней. Просто это логично что за валидацию должен отвечать отдельный компонент. Более того, он очень гибок за счет того что он отдельный. Короче все проблемы именно изза того что вы не разобрались пока. Валидацию думаю вы быстро освоите, а от форм будете плеваться пока не постигните дзен.
Виджет это просто название. У вас есть HMVC, который намного более гибкий. А добавьте к этому наследование шаблонов и блоки и проблем с масштабированием шаблонов вообще не будет. В YIi при помощи виджетов решали проблему дублирования кода при формировании страницы. В Symfony нашли более качественное решение.
Я сам когда-то в 2011-ом был вынужден пересесть на Symfony2, первый месяц мне было некомфортно после Yii1 который я знал вдоль и поперек, излазил все исходники и досканально знал как работает большая часть его компонентов. И тут на тебе... новый фреймворк (ну как новый... я как-то тыкал Symfony1 так что что-то уже понимал но на тот момент не понимал полностью) и все сложное и нужно много думать... Но вот прошли три года и я низачто не хочу переходить на какой либо другой фреймворк. Еще на Laravel могу посмотреть, на Zend... а так если уж не SYmfony то пойду колупать RoR или Django, который я забросил лет 6 назад.
Короче подытожим. Yii это хорошо для того что бы клепать сайтики. ПРоблема в Yii в том что если у разработчика это один из первых фреймворков и еще не сложилось какое-то понятие о культуре разработки, то он будет писать говнокод и будет крайне медленно из этого дела выплывать (все зависит от характера конечно).
Вот... Словом, просто соберитесь и переростите этап Yii. Просто гарантирую вам что если вы хотя бы год поработаете с Symfony то работать с чем угодно вам будет намного проще.
@vasIvas: просто забейте. Вам лучше стоит сконцентрироваться на том что же там происходит, что такое reflow/repain, уяснить как работать с асинхронными функциями (колбэки и промисы) и что такое event loop.
JS очень быстрый язык. Очень. Если мы говорим об обычных web приложениях, то тут нужно только разобраться с тем как работать с DOM. Обычно это 99% всех узких мест и лагов. Если говорить о серверном JS - то это IO и база данных.
Если же вы делаете какие-то вычисления в JS, работаете с большими массивами и т.д. то можете например посмотреть вот этот доклад: https://www.youtube.com/watch?v=tCG0aPNvkTs - я думаю что вы большую часть не поймете и думаю что вам это не пригодится скорее всего.
@vasIvas: я сомневаюсь что вам и во flash надо было все подряд мерять... А что у вас за проекты? Я так понимаю что-то с графикой связано? Так там мерять то нечего... нужно просто делать все через GPU или стараться делать все через GPU. Собственно как и на flash. Если что-то посложнее - алгоритмы оптимизировать, профилирование то тут ни причем. Нужно так же знать некоторые особенности JIT-компилятора JS, как он инлайнит все, что оптимизирует, как оптимизирует и т.д.
Но это все нужно только для разработки каких-то графических/физиеских/аудио движков.
@ByKraB: скорее всего событие вызывается вместе с $apply. Или предыдущий цикл еще не закончил обрабатываться (если у вас действие проиходит по ng-change/ng-click то там тоже запускается $apply. Каждая итерация $digest цикла запускается с setTimeout. То есть выполнение откладывается до тех пор пока JS не прекратит работу дат текущими делами.
Не видя кода директивы или всего кода сложно сказать. Но факт остается фактом - $apply или $digest должны быть запущены.
@vasIvas: смотря что вам нужно. И да, забыл сказать... преждевременные оптимизации - зло, занимайтесь оптимизациями только когда видите проблему и только при помощи профайлера. Если просто любопытно какой вариант быстрее - jsperf. Если хотите в лог выводить какая операция что делала - console.time вам хватит.
