Установил. Aдминка понятная и для целевого пользователя, наверное, удобная. Есть ограничения по макету страницы: через админку пользователь не может создать несколько произвольных колонок, область куда можно дропнуть контент задаётся жестко в шаблоне.
Сверстал шаблон. Посмотрел код внутри — всё вперемешку, в некоторых местах html печатается прямо из php кода виджетов, в некоторых через шаблоны. В итоге чтобы расставить нужные мне css классы (я использовал twitter bootstrap) приходилось править не только код шаблонов-виджетов, но и какие-то фрагменты внутри «движка».
Повсюду глобальные переменные и eval.
Во фронтенде тянет много js кода, который реально используется только при просмотре сайта через админку. А если его вырезать из шаблона, где он явно прописан, админка перестаёт работать.
Виджет «HTML фрагмент», который можно дропнуть на страницу в админке, не поддерживает кирилицу. Один раз набрать текст и сохранить можно, но при попытке отредактировать получаем иероглифы (в обычных текстовых виджетах всё нормально).
Резюме: проект не только сырой, но и архитектурно очень кривой. Заявлено использование PHP 5.3, а по сути спагетти-код в стиле PHP 4.
Вопросик про инициализацию компонентов. Подход при котором компоненты помечаются определённым классом, а данные храняться в onclick (или кому-то больше нравится data-*) понятен.
Какие недостатки у варианта 2: сразу после html кода компонента в вёрстке вставляется тег script с вызовом функции ядра (которая точно уже загружена) initComponent(htmlId, data)?
Может это устарело или имеет очевидные недостатки? Спрашиваю, т.к. хочу понять best practice на сегодняшний день. Если дадите ссылку, что почитать про современные паттерны программирования клиентской части на JavaScript — спасибо.
Распределение рынка между различными версиями Windows мы все примерно знаем (то тут, тот там проскакивают разные статистики и аналитические отчёты). А кто-нибудь видел статистику с учётом установленных Service Pack'ов? Какова текущая доля «чистого» XP и XP SP1?
Да, припоминаю, читал об этом. Кажется, эти «скрытые» комиты будут почищены сборщиком мусора через 30 дней (поправьте, если я что-то перепутал).
Тогда еще вопрос: а если до того как я запушил свой rebase, кто-то успел сделать pull этой пачки комитов, поработать над ними и сделать push обратно (по времени, допустим, после моего rebase-push) — куда теперь будет указывать master? Должен возникнуть конфликт указателя master?
Поясню природу своего вопроса: в mercurial такая ситуация не вызывает у меня проблемы, получатся анонимные ветки и их может быть сколь угодно много и они не будут однажды внезапно подчищены сборщиком мусора.
Попробуйте наоборот:
1. работаю, много комичу
2. rebase (на локальной машине)
3. push на «центральный» реп
Заодно задам вопрос по git:
если сначала запушить много комитов на удалённый репозиторий, потом локально сделать rebase, и запушить новый результат на удалённый репозиторий — не уже ли на удалённом репозитории исчезнет пачка комитов запушеная в первый раз? Если да, значит git при пуше передаёт не только сами комиты, но и другую мета-информацию, в частности структуру поделанного локально rebase? Как-то сложно получается… Как на самом деле в git?
Из моего опыта: глобальные ветки, такие как develop и stable — это hg branch.
Для короткоживущих и хотфиксов можно было бы использовать bookmarks, но как-то мне всё время лень создавать эти букмарки и я обхожусь анонимными ветками внутри develop (или в stable, если это очень горячий фикс).
Следующий вопрос, что потом делать с этими анонимными ветками? В большинстве случаев делаю обычный merge. Иногда, перед merge причёсываю свои комиты через mq import/fold.
Пробовал пользоваться и rebase, но мне приятнее видеть историю моих анонимных веток-фичей в виде отдельных комитов рядом с основной develop веткой. Кстати, какую из анонимных develop веток называть «основной» если все они анонимные? Выбрать любую условную, можно на неё даже отдельный bookmark повесить. Но сложность моих проектов не так велика, чтобы запутаться в 2-5 анонимных ветках в develop бренче.
Наконец, самая большая трудность возникает тогда, когда кто-то из команды внезапно сделает pull с моего репозитория. По умолчанию в mercurial pull и push синхронизирует все бренчи, все ветки. После такой глобальной синхронизации с соседом, причесать свои анонимные ветки используя mq import/fold не получится, т.к. непричёсанная история вернётся ко мне при следующей синхронизации с соседом. Вот тут есть некое преимущество у git с его приватными бренчами. Обходной путь в mercurial — это ветвление через клонирование. Можно наделать клонов в разных папках и не бояться, что их кто-то случайно стянет. Но это создаёт больше проблем, чем удобств — придётся настраивать IDE и другое окружение на несколько папок.
Однако реальная практика показывает, что особой проблемы с отсутствием приватных бренчей в mercurial нет. Просто так никто не делает pull с моего репозитория. Обычно коллеги делают pull непосредсвенно с моего компьютера, если я сам кому-то говорю «сделай с меня pull, я внёс важные фиксы».
Боюсь, вы не совсем правильно себе представляете смысл приоритета в терминах разбора выражения. В парсере нет такой логики «найди оператор X и выполни его, а затем найди оператор Y..»
Да, с парсерами не работал, поэтмоу в терминах разбора выражений всё может выглядеть несколько иначе, чем я себе представляю. Тогда спора нет.
Но разговорной или письменной речи относительно программирования я бы говорил «тернарный оператор имеет больший приоритет операции, чем присваивание». Кстати, заглянул в официальную документацию PHP — там такой же подход php.net/manual/en/language.operators.precedence.php (тернарный оператор на одну строку выше чем присваивание в таблице приоритетов).
Но имхо, это срабатывает оптимизатор, поэтому это не аргумент за или против приоритетов операций.
Согласен, эта моя придирка к формулировкам никак не относилась к основной теме приоритета операций :)
С логикой работы php согласен, мы оба правильно её понимаем. Но с формулировкой не согласен. Моё понимание формулировок следующее:
(рассматриваю всю строку, а не только правую часть после $a)
1. Формулировка "тернарный оператор в PHP имеет приоритет ниже операторов присваивания" эквивалентна следующей логике: сначала выполняем все присваивания: $a = true, $b = 'new b', $c = 'new c', затем вычисляем выражение тернарного оператора, который сводится к сроке «true? 'new b': 'new c'», что в итоге будет эквивалентно 'new b', но, к сожалению, этот результат никуда не будет записан или выведен.
2. Формулировка "тернарный оператор в PHP имеет приоритет выше операторов присваивания" эквивалентна следующей логике: найдём в строке тернарный оператор и «выполним» его, затем перейдём к присваиваниям, оставшимся за скобками тернарного оператора. В данном случае интерпретатор языка php определит фрагмент «true? $b = 'new b': $c = 'new c';» как выражение тернарного оператора. Далее, следуя логике этого оператора, нужно вычислить выражение перед знаком "?", а затем одно из выражений после знака "?". Это суть механизма тернарного оператора, а не приоритет присваивания над тернарным оператором.
Таким образом, продалжаю настаивать, что правильно говорить "тернарный оператор в PHP имеет приоритет выше операторов присваивания" в php.
Кстати, в вашем комментарии закралась ещё одна неточность:
Сначала вычисляются присваивания в каждом узле тернарного оператора
Выражения вычисляются не в каждому узле тернарного оператора, а только в том узле после знака "?", который должен быть возвращён как результат тернарного оператора. Другой узел не вычисляется.
Установил. Aдминка понятная и для целевого пользователя, наверное, удобная. Есть ограничения по макету страницы: через админку пользователь не может создать несколько произвольных колонок, область куда можно дропнуть контент задаётся жестко в шаблоне.
Сверстал шаблон. Посмотрел код внутри — всё вперемешку, в некоторых местах html печатается прямо из php кода виджетов, в некоторых через шаблоны. В итоге чтобы расставить нужные мне css классы (я использовал twitter bootstrap) приходилось править не только код шаблонов-виджетов, но и какие-то фрагменты внутри «движка».
Повсюду глобальные переменные и eval.
Во фронтенде тянет много js кода, который реально используется только при просмотре сайта через админку. А если его вырезать из шаблона, где он явно прописан, админка перестаёт работать.
Виджет «HTML фрагмент», который можно дропнуть на страницу в админке, не поддерживает кирилицу. Один раз набрать текст и сохранить можно, но при попытке отредактировать получаем иероглифы (в обычных текстовых виджетах всё нормально).
Резюме: проект не только сырой, но и архитектурно очень кривой. Заявлено использование PHP 5.3, а по сути спагетти-код в стиле PHP 4.
Какие недостатки у варианта 2: сразу после html кода компонента в вёрстке вставляется тег script с вызовом функции ядра (которая точно уже загружена) initComponent(htmlId, data)?
Может это устарело или имеет очевидные недостатки? Спрашиваю, т.к. хочу понять best practice на сегодняшний день. Если дадите ссылку, что почитать про современные паттерны программирования клиентской части на JavaScript — спасибо.
Я обычно делаю публичной не всю папку репозитория, а какую-нибудь www внутри. Т.о. репозиторий оказывается на один уровень выше.
Тогда еще вопрос: а если до того как я запушил свой rebase, кто-то успел сделать pull этой пачки комитов, поработать над ними и сделать push обратно (по времени, допустим, после моего rebase-push) — куда теперь будет указывать master? Должен возникнуть конфликт указателя master?
Поясню природу своего вопроса: в mercurial такая ситуация не вызывает у меня проблемы, получатся анонимные ветки и их может быть сколь угодно много и они не будут однажды внезапно подчищены сборщиком мусора.
1. работаю, много комичу
2. rebase (на локальной машине)
3. push на «центральный» реп
Заодно задам вопрос по git:
если сначала запушить много комитов на удалённый репозиторий, потом локально сделать rebase, и запушить новый результат на удалённый репозиторий — не уже ли на удалённом репозитории исчезнет пачка комитов запушеная в первый раз? Если да, значит git при пуше передаёт не только сами комиты, но и другую мета-информацию, в частности структуру поделанного локально rebase? Как-то сложно получается… Как на самом деле в git?
Для короткоживущих и хотфиксов можно было бы использовать bookmarks, но как-то мне всё время лень создавать эти букмарки и я обхожусь анонимными ветками внутри develop (или в stable, если это очень горячий фикс).
Следующий вопрос, что потом делать с этими анонимными ветками? В большинстве случаев делаю обычный merge. Иногда, перед merge причёсываю свои комиты через mq import/fold.
Пробовал пользоваться и rebase, но мне приятнее видеть историю моих анонимных веток-фичей в виде отдельных комитов рядом с основной develop веткой. Кстати, какую из анонимных develop веток называть «основной» если все они анонимные? Выбрать любую условную, можно на неё даже отдельный bookmark повесить. Но сложность моих проектов не так велика, чтобы запутаться в 2-5 анонимных ветках в develop бренче.
Наконец, самая большая трудность возникает тогда, когда кто-то из команды внезапно сделает pull с моего репозитория. По умолчанию в mercurial pull и push синхронизирует все бренчи, все ветки. После такой глобальной синхронизации с соседом, причесать свои анонимные ветки используя mq import/fold не получится, т.к. непричёсанная история вернётся ко мне при следующей синхронизации с соседом. Вот тут есть некое преимущество у git с его приватными бренчами. Обходной путь в mercurial — это ветвление через клонирование. Можно наделать клонов в разных папках и не бояться, что их кто-то случайно стянет. Но это создаёт больше проблем, чем удобств — придётся настраивать IDE и другое окружение на несколько папок.
Однако реальная практика показывает, что особой проблемы с отсутствием приватных бренчей в mercurial нет. Просто так никто не делает pull с моего репозитория. Обычно коллеги делают pull непосредсвенно с моего компьютера, если я сам кому-то говорю «сделай с меня pull, я внёс важные фиксы».
Да, с парсерами не работал, поэтмоу в терминах разбора выражений всё может выглядеть несколько иначе, чем я себе представляю. Тогда спора нет.
Но разговорной или письменной речи относительно программирования я бы говорил «тернарный оператор имеет больший приоритет операции, чем присваивание». Кстати, заглянул в официальную документацию PHP — там такой же подход php.net/manual/en/language.operators.precedence.php (тернарный оператор на одну строку выше чем присваивание в таблице приоритетов).
Согласен, эта моя придирка к формулировкам никак не относилась к основной теме приоритета операций :)
(рассматриваю всю строку, а не только правую часть после $a)
1. Формулировка "тернарный оператор в PHP имеет приоритет ниже операторов присваивания" эквивалентна следующей логике: сначала выполняем все присваивания: $a = true, $b = 'new b', $c = 'new c', затем вычисляем выражение тернарного оператора, который сводится к сроке «true? 'new b': 'new c'», что в итоге будет эквивалентно 'new b', но, к сожалению, этот результат никуда не будет записан или выведен.
2. Формулировка "тернарный оператор в PHP имеет приоритет выше операторов присваивания" эквивалентна следующей логике: найдём в строке тернарный оператор и «выполним» его, затем перейдём к присваиваниям, оставшимся за скобками тернарного оператора. В данном случае интерпретатор языка php определит фрагмент «true? $b = 'new b': $c = 'new c';» как выражение тернарного оператора. Далее, следуя логике этого оператора, нужно вычислить выражение перед знаком "?", а затем одно из выражений после знака "?". Это суть механизма тернарного оператора, а не приоритет присваивания над тернарным оператором.
Таким образом, продалжаю настаивать, что правильно говорить "тернарный оператор в PHP имеет приоритет выше операторов присваивания" в php.
Кстати, в вашем комментарии закралась ещё одна неточность:
Выражения вычисляются не в каждому узле тернарного оператора, а только в том узле после знака "?", который должен быть возвращён как результат тернарного оператора. Другой узел не вычисляется.
Хотелось бы уточнить, тренарный оператор имеет приоритет ниже или выше?
Проверяем:
$a = 'old a';
$b = 'old b';
$c = 'old c';
$a = true ? $b = 'new b' : $c = 'new c';
Результат: $a === 'new b', $b === 'new b', $c === 'old c';
Второй эксперимент при тех же начальных условиях:
$a = false ? $b = 'new b' : $c = 'new c';
Результат: $a === 'new c', $b === 'old b', $c === 'new c';