Комментарии 18
Интересный подход. В случае ошибки можно отследить цепочку вплоть до номера стоки в html?
Ловля ошибок несколько другая. Есть три места, где могут возникнуть ошибки.
1. Сценарий. Тут тупняк, зачастую ошибок нет
2. Обработчики. Они зачастую настолько просты, что процесс отладки их производится на момент написания
3. Выполнение обработчиков. Тут весь дебаг заключается в визуальном просмотре HTML кода, попадает ли данная нода в заданную зону видимости нужного события, или нет. Смешно, но это именно так.
1. Сценарий. Тут тупняк, зачастую ошибок нет
2. Обработчики. Они зачастую настолько просты, что процесс отладки их производится на момент написания
3. Выполнение обработчиков. Тут весь дебаг заключается в визуальном просмотре HTML кода, попадает ли данная нода в заданную зону видимости нужного события, или нет. Смешно, но это именно так.
Александр, а почему бы вам не выложить исходники и документацию не github? Тем более вы пишете на форуме: «Бесплатное коммерческое использование, распространение, изменение и все остальное тоже». Как-то зело ломает качать зипы, распаковывать, редактор открывать.
И еще такой вопрос: в первой части вы пишите «Так появился StateController v2», а на форуме заголовок «StateController v5» — где правда? (:
И еще такой вопрос: в первой части вы пишите «Так появился StateController v2», а на форуме заголовок «StateController v5» — где правда? (:
У меня после прочтения двух ваших статей возникла пара вопросов:
1. Где это применяется (если вообще применяется)? Теория она штука хорошая, но без реальных работающих проектов созданных на основе предлагаемого вами подхода, это просто не работает…
2. Некоторые ваши доводы, создают противоречивые чувства (а именно: хранение всего в DOM, инлайн обработчики в аттрибутах HTML — элементов и т. п.), не обижайтесь, но создается ощущение что все мы когда — то уже проходили эту стадию когда все кажется таким простым и понятным, когда только начинали изучать JavaScript…
1. Где это применяется (если вообще применяется)? Теория она штука хорошая, но без реальных работающих проектов созданных на основе предлагаемого вами подхода, это просто не работает…
2. Некоторые ваши доводы, создают противоречивые чувства (а именно: хранение всего в DOM, инлайн обработчики в аттрибутах HTML — элементов и т. п.), не обижайтесь, но создается ощущение что все мы когда — то уже проходили эту стадию когда все кажется таким простым и понятным, когда только начинали изучать JavaScript…
5 лет используется в реальных проектах.
Я понимаю, что вызываю противоречивые чувства, и иногда решения кажутся нелогичными. Но все решения делались с каким-то учетом определенных требований, о которых я и пытался описать в первых двух частях. Самое большое отторжение вызывает сама событийная логика, она, скажем мягко, странная.
Я понимаю, что вызываю противоречивые чувства, и иногда решения кажутся нелогичными. Но все решения делались с каким-то учетом определенных требований, о которых я и пытался описать в первых двух частях. Самое большое отторжение вызывает сама событийная логика, она, скажем мягко, странная.
Вот в каких конкретно проектах? Могли бы вы привести ссылки?
Событийная логика сама по себе отторжения у меня лично не вызывает и ничего странного я в ней не вижу. В частности похожий принцип применяется в механизме под названием Progressive Enhancement.
Событийная логика сама по себе отторжения у меня лично не вызывает и ничего странного я в ней не вижу. В частности похожий принцип применяется в механизме под названием Progressive Enhancement.
1. Сразу видно что вы технический специалист) Вы не умеете преподнести информацию так, чтобы топик вообще кого то заинтересовал.
2. Вы не предлагаете людям продукт.
Вообще, вы копаете в правильном направлении, я тем же самым занимаюсь и прекрасно знаю чем все это закончится. Только без красивой обертки это никому не интересно. То, о чем знаете вы и я — не известно остальным.
2. Вы не предлагаете людям продукт.
Вообще, вы копаете в правильном направлении, я тем же самым занимаюсь и прекрасно знаю чем все это закончится. Только без красивой обертки это никому не интересно. То, о чем знаете вы и я — не известно остальным.
я смотрю мы делаем что-то похожее)
распространять события на потомков — это слишком жёстко. а ограничения вида «распространяем событие на детей до второго колена» — слишком негибкие. я выбрал другой путь — родитель, если ему надо, отслеживает появление и исчезновение нужных ему детей и посылает события сразу тем, кому надо. при этом кастомные события имеют дефолтное поведение — сообщение об ошибке, что гарантирует, что никто не будет кричать в пустоту и кто-нибудь его обработает. ну и автоматический каскадный дестрой объектов позволяет решить проблему утечек. у меня еще было фолбэк для ие старых версий, но… ну его нахрен, выпилил эти костыли)
если интересно глянь модуль отслеживания виджетов github.com/nin-jin/jin/blob/master/component/jin_component.env%3Dweb.jam.js
почему ноды обрабатываются в обратном порядке?
пс, на самом деле w3-шный валидатор умеет подтягивать кастомные дтд, я когда то игрался, но хз где те исходники… и нафиг оно надо в dtd слишком не гибкие правила.
ппс, либо для кроссбраузерной работы с xml+xpath+xslt на клиенте: github.com/nin-jin/jin/blob/master/domx/jin_domx.env%3Dweb.jam.js
распространять события на потомков — это слишком жёстко. а ограничения вида «распространяем событие на детей до второго колена» — слишком негибкие. я выбрал другой путь — родитель, если ему надо, отслеживает появление и исчезновение нужных ему детей и посылает события сразу тем, кому надо. при этом кастомные события имеют дефолтное поведение — сообщение об ошибке, что гарантирует, что никто не будет кричать в пустоту и кто-нибудь его обработает. ну и автоматический каскадный дестрой объектов позволяет решить проблему утечек. у меня еще было фолбэк для ие старых версий, но… ну его нахрен, выпилил эти костыли)
если интересно глянь модуль отслеживания виджетов github.com/nin-jin/jin/blob/master/component/jin_component.env%3Dweb.jam.js
почему ноды обрабатываются в обратном порядке?
пс, на самом деле w3-шный валидатор умеет подтягивать кастомные дтд, я когда то игрался, но хз где те исходники… и нафиг оно надо в dtd слишком не гибкие правила.
ппс, либо для кроссбраузерной работы с xml+xpath+xslt на клиенте: github.com/nin-jin/jin/blob/master/domx/jin_domx.env%3Dweb.jam.js
С первого взгляда действительно, кажется нелогичным или негибким распространять события на детей. Но приведу простой пример — табы. Давайте нарисуем абстрактную структуру этого компонента
При нажатии на любой switcher, мы должны вернуться по дереву на несколько парентов вверх, пока не найдем tabber, и после этого запустить событие переключения на нужный таб всем чайлдам на глубину в 2 уровня. Не более того.
Дополнительный плюс — любое вложение других компонентов табов в контейнеры текущего будут работать без переделок. Главное — сохранять структуру. Это очень похоже на БЭМ.
Ноды обрабатываются в обратном порядке, чтобы при удалении нод не выхватывать проблему пропуска следующего элемента из списка. Да и по скорости итерирования в ИЕ можно было получить прирост производительности.
DTD имеет очень неплохую кастомизацию, потому что это основа SGML, но он несколько заумен. Хотя читать его проще, чем XSD
<tabber>
<switchers>
<switcher />
<switcher />
...
</switchers>
<containers>
<container />
<container />
...
</containers>
</tabber>
При нажатии на любой switcher, мы должны вернуться по дереву на несколько парентов вверх, пока не найдем tabber, и после этого запустить событие переключения на нужный таб всем чайлдам на глубину в 2 уровня. Не более того.
Дополнительный плюс — любое вложение других компонентов табов в контейнеры текущего будут работать без переделок. Главное — сохранять структуру. Это очень похоже на БЭМ.
Ноды обрабатываются в обратном порядке, чтобы при удалении нод не выхватывать проблему пропуска следующего элемента из списка. Да и по скорости итерирования в ИЕ можно было получить прирост производительности.
DTD имеет очень неплохую кастомизацию, потому что это основа SGML, но он несколько заумен. Хотя читать его проще, чем XSD
Я как раз делаю наоборот непохожее, но примерно с тем же результатом.
Дело тут вот в чем. По сути любой разработчик при желании может сделать удобное одностраничное приложение, было бы желание. Но ведь соль не в этом. Предложить разработчикам не писать все с нуля, а просто пропатчить уже существующие проекты, чтобы они стали одностраничными — это первоцель моей работы. А так как большой процент приложений написан на php, то и отталкиваться пришлось от этого. Нужно было просто научить php «чувствовать», чтобы php знал обо всем, что происходит на клиенте. Для этого был написан «датчик» чувств (js-код) и «драйвер» «датчика» (серверный код). Подключив эти компоненты к уже работающему проекту, нужно лишь немного подправить код в нескольких местах, используя некоторые новые константы. Помогает в этом специальный отладочный механизм, сообщающий о пропущенных местах. А так как код не писался с нуля, а модифицировался уже работающий, то остается совместимость со старой версией, и если у клиента отключен js, то все работает как и раньше, так как «датчик» просто не срабатывает. На самом деле все чуть сложнее, и не все проекты подвергаются легкой модификации. Сейчас работаю над API к «драйверу», чтобы можно было пощупать руками.
Дело тут вот в чем. По сути любой разработчик при желании может сделать удобное одностраничное приложение, было бы желание. Но ведь соль не в этом. Предложить разработчикам не писать все с нуля, а просто пропатчить уже существующие проекты, чтобы они стали одностраничными — это первоцель моей работы. А так как большой процент приложений написан на php, то и отталкиваться пришлось от этого. Нужно было просто научить php «чувствовать», чтобы php знал обо всем, что происходит на клиенте. Для этого был написан «датчик» чувств (js-код) и «драйвер» «датчика» (серверный код). Подключив эти компоненты к уже работающему проекту, нужно лишь немного подправить код в нескольких местах, используя некоторые новые константы. Помогает в этом специальный отладочный механизм, сообщающий о пропущенных местах. А так как код не писался с нуля, а модифицировался уже работающий, то остается совместимость со старой версией, и если у клиента отключен js, то все работает как и раньше, так как «датчик» просто не срабатывает. На самом деле все чуть сложнее, и не все проекты подвергаются легкой модификации. Сейчас работаю над API к «драйверу», чтобы можно было пощупать руками.
btw, все та же система, что и 4 года назад? (или когда там была та интересная беседа)
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
StateController. Событийная модель в разработке интерфейсов. Часть 2