Разве это легитимно? Их работа ведь никак не связана с тем, что некоторые пользователи заливали нелегальные файлы. Это всё равно что преследовать сторителей здания магазина за то, что его хозяин позволял торговать просроченными продуктами. Или они все были совладельцами?
Именно поэтому мне строгий синтаксис xml и нравится больше. С ним проще работать как интерпретатору, так и программисту. Как побочный эффект свободы нестрогого синтаксиса html, разные браузеры генерируют разный текст в режиме визуального редактирования, например. И w3c не запрещает использовать xml-совместимые теги.
Это да, но я имел в виду соответствие html -> xhtml, а не наоборот :) Другими словами, если писать всегда <br/> и <div> </div>, все парсеры будут довольны.
Моё мнение, что кавычки в атрибутах, указание типа скрипта и соответствие xhtml еще никому не повредили, а начинающим верстальщикам нужно в первую очередь учиться верстать независимыми минималистичными блоками и глубже изучать CSS. А то иногда оказывается, что начинающий верстальщик может много рассказать о достоинствах html5, а как взаимодействуют margin-ы не знает.
Согласен. Найти причину кризисности надо обязательно. В частности, в веб-проекте: пожирающий время перфекционизм разработчиков и лидера; поток хотелок и отсутствие времени на них, что ведет к костыльным тупиковым решениям; экономия на квалификации разработчиков, дизайнеров или менеджеров в ключевых ролях проекта; недостаточное внимание рекламе и продвижению… Не уничтожив причину, из кризиса не выбраться.
Согласен, главная страница сайта компании во многом аналогична входной двери этой компании с табличкой. Название, режим работы, логотип, адрес, телефоны, скайпы. А все подробности, каталоги, прайсы — за дверью.
Те врачи с компьютерами, что мне встречались, не писали ничего на клавиатуре, они просто шустро вставляли одной кнопкой мышки текстовые блоки из каталога в историю болезни, и выбирали что-то в селектбоксах. К сожалению, далеко не во всех больницах используется такой подход, и время пациентов и врачей уходит на записи в тетрадки. Авторам от души хочу пожелать успехов и поменьше бюрократических препятствий.
Определяет место в шаблоне компонента, куда вставляется верстка дочернего (вложенного) компонента, содержащегося в указанной параметром переменной. Он имеет свой собственный шаблон. Эта и другие специальные инструкции могут «прийти» в шаблон из $this->instructions.
Задача была — убрать уровень компиляции шаблонов после каждого редактирования, а не написать новый шаблонизатор. Когда мы с коллегами обсуждали мысль заменить шаблонизатор, синтаксис php воспринялся исполнителями шаблонов намного радостнее, чем синтаксис twig, потому что не требует поддержки дополнительных знаний и нюансов. И конечно, код шаблона не будет работать на хостингах, где поддержка коротких тегов запрещена по каким-либо причинам.
В функцию рендера приходит ассоциативный массив параметров, которые для удобства превращаются в переменные (чтобы писать "$V($item)" вместо "$V($data['item'])", например). Чтобы эти переменные отличались от остальных, таких как скин, например, остальные имеют префикс "_". При подготовке шаблона они воспринимаются как «системные», «специальные» или «внутренние».
Как я уже писал ранее, в верхнем регистре названы только лямбда-функции, опять же с целью повысить отличимость, визуально выделить на фоне HTML в шаблоне, и исключить пересечения с параметрами шаблона (для параметров шаблона декларировано, что они должны быть всегда в стандартном формате camelCase). Это ситаксический «сахар» для тех, кто программирует шаблоны. В целом, сами конечные шаблоны смотрятся весьма неплохо и читаемо, на уровне классических шаблонов вроде Smarty, php-вставки не режут глаз и воспринимаются как часть HTML. Если у вас есть идея как еще сильнее понизить «эффект присутствия php», буду рад, если поделитесь.
Пробелы между аргументами и условные операторы в одно действие — это вечно спорный вопрос стилистики и выбранных стандартов форматирования для группы разработчиков.
Для большего понимания, не могли бы вы привести пример ситуации, когда надо процессинг CSS делать на стороне браузера, вместо того, чтобы один раз прогнать через скрипт-сборщик на сервере?
Я не против классического подхода к шаблонам на php, но хотелось сделать почище.
Как я уже писал ранее, в верхнем регистре названы только лямбда-функции, опять же с целью повысить отличимость, визуально выделить на фоне HTML в шаблоне, и исключить пересечения с параметрами шаблона (для параметров шаблона декларировано, что они должны быть всегда в стандартном формате camelCase). Это ситаксический «сахар» для тех, кто программирует шаблоны. В целом, сами конечные шаблоны смотрятся весьма неплохо и читаемо, на уровне классических шаблонов вроде Smarty, php-вставки не режут глаз и воспринимаются как часть HTML. Если у вас есть идея как еще сильнее понизить «эффект присутствия php», буду рад, если поделитесь.
Пробелы между аргументами и условные операторы в одно действие — это вечно спорный вопрос стилистики и выбранных стандартов форматирования для группы разработчиков.