Yaroslav Lyzlov: если просто выводить коллекцию то можно вообще не париться. Другой вопрос что выводить на одной страница сразу 10 000 рядов например не слишком умная затея. Для этих целей есть отдельные директивы, которые выводят только то что сейчас видно.
В целом же track by помогает когда коллекции постоянно переформировываются, например при фильтрации, или один массив заменяется на другой... тогда track by уже сильно спасает так как angular может реюзать уже имеющийся DOM.
Что до webworkers - было пару раз но там как бы... просто нужно было обсчитать картинки, эффекты поприменять и все такое. Если вам интересно - у angular2 возможность полностью все приложение отделить в webworker (что бы логика и представление в разных потоках были) имеется из коробки.
imelos: грубо говоря вам надо сформировать коллекцию рядов таблицы (по сути это таблица, без разницы что это дивами выводится) так как вам того хочется. Перед этим отфильтровав через array.filter.
s0ci0pat: я лишь пытаюсь сказать что если человек не знает предметной области и только делает то что ему говорят - то грош цена такому программисту.
Без хотя бы минимального погружения в предметную область (даже если большая часть бизнес анализа была сделана аналитиками), работа программиста будет происходить крайне не эффективно.
банки - человек должен знать о предметной области что бы делать свои дела. Он во всяком случае должен все это учитывать.
крупные организаци и корпорации - это в основном легаси проекты (попадался проектик где использовалась легаси система написанная аж в 79-ом году на ассемблере, которая за 35 лет просто обрасла оберткой на java). Там много проблем и хороший процент оных как раз таки в плохих процессах.
Заводы - разработчик так же должен быть вкурсе предметной области.
Космическое агенство - разработчик должен быть вкурсе предметной области. Там обычно программисты либо моделируют какие-то системы, что подразумевает о том что человек знает что моделирует, либо еще чего. Есть еще обработка цифровых сигналов и прочие забавности где разработчик опять же знает предметную область разрабатываемого проекта.
Если человек не знает что он делает, то он работает крайне не эффективно. Это существенно увеличивает риски и т.д. По сути это яркое подверждение того что процессы в таких командах работают очень не эффективно.
Собственно лет 15 назад на этой волне появилось сообщество BDD и DDD, которые на разных уровнях пытаются устранить проблему стоимости перевода требований из языка бизнеса в код. Так же есть другие подходы, в той же космической отрасли или военной промышленности V-model используется или подобные вещи, и там хочет разработчик или не хочет, но ему придется ознакомиться с предметной областью.
Денис Иванов:
1) ну так а я предлагаю богомерзский смарти? Есть twig, он покрывает все нужды. + его очень легко расширять под проект. А шансы что разработчик с php шаблонами забудет заэкранировать какие-то вещи сильно повышается, повышаются риски. Так же стоимость поддержки так же может существенно возрасти. Если вы знаете о рисках - то нет проблем, но большинство не знает.
2) сильное связывание компонентов (для версии 1, для второй все чуть получше), откровенно слабое комьюнити. В принципе для простых проектов и для быстрой разработки норм, но.... вот у меня сейчас перед глазами проектик... ~3000 коммитов, 70К строк кода. За счет отсутствия контейнера зависимостей - фреймворк потворствует нарушени принципа инверсии зависимостей, все связано друг с дружкой и т.д. В итоге масса регрессий на пустом месте.
На Yii можно писать хорошо, и многие пишут на нем хорошо. Я работал с Yii со времен 1.0. Но для этого должен быть недюжий опыт, годы хождения по граблям и т.д. Именно это для меня является основным показателем "хорошести" фреймворка. Yii потворствует плохому дизайну (та же проблема например у angular1). Хоть во второй версии Yii получше все стало, но на фоне Laravel я реально не вижу в нем смысла (зачем плодить сущности?). Он принципиально от него не отличается и часть решений банально хуже. Комьюнити существенно меньше. Риски выше.
В целом же основная болезнь людей пишущих на Laravel/Yii и других RoR подобных PHP фреймворках, является то, что они пытаются перенести философию RoR в пых, без принятия любви рубистов к тестам. Ну и да, типичная проблема - высокая связанность бизнес логики и фреймворка. Люди пишут на фреймворках а не на php. У Symfony/zend тоже есть эта проблема но чуть меньше выражена.
s0ci0pat: он должен понимать о чем говорит бизнес, иначе мы имеем дело не с большим проектом а с плохо построенными процессами. Это было актуально лет 20 назад, когда подругому как бы и не принято было. А сейчас в моде маленькие команды которые пилят свои кусочки большого проекта.
привидите цитату, возможно это правила конкретного регистратора. В целом же политика регистрации доменных имен одинакова для всех. И контролирует это все организация под названием ICANN.
1) откуда у нас Yii?
2) виджеты это как раз таки кастыли в виде инклудов, в контексте Yii это недо-реализация HMVC.
Не вижу смысла в шаблонизаторах.
Я не вижу смысла в Yii, но судя по всему вам оно нравится.
Сергей Жуков: да, находятся кадры. И имено код таких чуваков (любители Yii и нелюбители шаблонизаторов) я сейчас наблюдаю и делаю аудит... и там все грустно.
Денис Иванов: не совсем. Скажем у twig (как и у многих других шаблонизаторов нынче) есть наследование шаблонов и система блоков. В PHP реализация оного приводит к куче дополнительного кода, шаблоны становятся менее читабельными и единственный вариант как это все разруливать - инклуды и функции выплевывающие html в буфер вывода. Имхо это не слишком читабельно и не слишком удобно. За те 20 лет что существует шаблонизатор PHP люди понавыдумывали намного более гибкие решения которые больше подходят для этих задач.
Стас: да, требования выше. С тремя месяцами на руби после php я не думаю что вы основательно прониклись философией ruby (в частности я не думаю что вам уже привита сильная любовь к тестам).
Денис Иванов: "проектировался как шаблонизатор" это то да, да только повторюсь. Очень плохой шаблонизатор, не слишком гибкий, увеличивающий дублирование и сложность поддержки и т.д. Но для Си это был хороший шаблонизатор, да, на то время.
И опять же, времена PHP3 уже думаю прошли давным давно.
Денис Иванов: шаблонизаторы не панаценя, согласен, но они сильно снижают такие риски. Ну и повторюсь - php так себе шаблонизатор с точки зрения поддержки шаблонов.
Sayber ☠: я вообще не понимаю людей которые не используют шаблониазторы... Буквально на днях делал аудит одного проектика где люди так же отказались от оных... XSS уязвимости это норма для таких приложений.
