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 уязвимости это норма для таких приложений.
