Sencha добавила в ExtJs 5 крайне удобную концепцию — ViewModel. Она позволяет динамически связывать данные с представлением. Причём данные могут зависеть друг от друга и вычисляться по сложным алгоритмам. Результат кешируется, и до тех пор, пока исходные данные не поменяются, конечный результат пересчитываться и обновляться не будет. Обязательно посмотрите, если ещё не сталкивались, — очень удобная штука.
Но, к сожалению, есть случаи, когда вселенская гармония нарушается и ViewModel перестаёт вести себя как подобает. Например, когда исходные данные — Store. ViewModel не умеет подписываться на события изменения ни Store, ни вложенных объектов. И как назло, разработчики не предусмотрели метода, который позволил бы заставить ViewModel пересчитать какое-нибудь значение. В таких случаях приходится лезть в дебри реализации и искать обходные пути.
Делюсь заклинанием:
viewModel.getRoot().descend(['info']).formula.react();Эта конструкция заставит ViewModel пересчитать значение info и обновить все связанные View. Просто подставьте название вашей формулы вместо info.
Проверено на ExtJS версий 5.0 и 5.1. Пользуйтесь и не позволяйте мелочам портить настроение.
Наверняка вы уже слышали, что Яндекс разрабатывает совершенно новый интерфейс для своего браузера (скачать), в котором содержимое страницы должно занимать всё пространство окна, от верхней границы до нижней. Для элементов управления отдельного пространства не запланировано, они просто выводятся поверх основного контента. Конечно, сайт должен поддерживать новый интерфейс, иначе ведь элементы управления браузера могут случайно перекрыть нужные ссылки и кнопки.
Обновил парсер CommonMark, написанный на Dart. Теперь он соответствует версии 0.12 спецификации. Правда один из тестов не проходит, но исключительно из-за ошибки в самом тесте. Ошибку уже поправили, так что следующая версия спецификации выйдет без неё.
Сама спецификация несколько поменялась со времени публикации предыдущей версии парсера. Самое крупное изменение: теперь можно использовать вложенные emphasis и strong. Например:
*Это *вложенный* emphasis*
**Это **вложенный** strong**Не знаю, насколько это применимо на практике, но, видимо, изменению спецификации предшествовало продолжительное обсуждение.
В общем, милости прошу за библиотекой на GitHub или pub.dartlang.
Самое время продолжить эпопею с IDE для Haskell (первая часть, вторая часть). Дело в том, что в IntelliJ Platform обнаружился новый Haskell-плагин. И, в отличие от старого, он работает.
Все началось с того, что мне понадобился парсер для Markdown, который строит AST, а не пытается сразу выдавать готовый HTML. А ещё было желательно, чтобы парсер был написан на Dart, так как проект я собирался писать именно на этом языке. Но, к сожалению, обнаружился только один парсер для Markdown, написанный на Dart. Поэтому идею пришлось отложить до лучших времён и сесть за написание своего велосипеда парсера.
Примерно через неделю после начала появилась спецификация CommonMark, которая помогла избавиться от некоторых вопросов, правда ценой полного переписывания: некоторые концепции из спецификации никак не хотели ложиться на уже написанный код.
И вот, спустя месяц, я рад вам представить свою реализацию, которая проходит все тесты CommonMark. И да, она позволяет получить AST для последующей обработки.
Библиотека md_proc на GitHub, pub.dartlang.
В самых ближайших планах реализовать восстановление Markdown обратно из AST, а также поддержка самых распространённых и нужных расширений, вроде TexMath, Footnotes, Smart punctuation и других. Ну и, конечно, поддержка совместимости с CommonMark тоже обязательно будет, тем более, что CommonMark ещё должен немного поменяться до того, как будет опубликована официальная версия 1.0. И уже после этого можно будет вернуться к первоначальному проекту.