Да я согласен, из того с чем я плотно сталкивался, Самсунг наиболее приятный в разработке. Ту проблему которую я описал наверно проявляется не всегда и не увсех — там все зависит от архитектуры приложения… Если исключить вероятность случайного использования удаленных элементов методом — putInnerHTML, то проблем не должно быть.
А что касается навигации в филипсе — у меня все впринципе более или менее:
1) Content-Type: application/ce-html+xml;charset=«UTF-8»
2) css3 spatial Navigation
и фокус ведет себя вполне корректно и дизайн вполне оправдывает ожидания
Но вот на динамической странице (где элементы навигации проподают/появляются или перемещаются) управлять этим spatial Navigation еще тот геморрой — но есть мысль написать API для этого — чтоб както автоматизировать процесс.
а вот при JS навигации, не используя css3 — тормоза при навигации оч заметные
Для меня — вопрос окупаемости не важен — у меня ЗП. Но закзчику прибыль приносит. Но ТВ приложение для них — это во первых источник доп дохода (основной доход с ПК версии сайта), и как реклама ПК версии, поскок пользователь может не знать ПК версию сайта, но наткнуться на приложение в телике…
я просто скину часть внутренней переписки в чем беда(как я смог выяснить — хотя конечно могу ошибаться):
если гденить в приложении есть это:
var element = $('#e1');
а потом гденить вызывается 'putInnerHTML' который удаляет этот '#e1', и поскок все это происходит в обход сборщика мусора, то значение переменной element — становится непонятным :)
и короче все начинает тупить и вылетать… поскольку повсеместно используется Jquery и прочие библиотеки. а они и не разрабатывались чтоб работать когда чтото будет удаляться в обход сборщика мусора
> Кошмар ТВ фрагментации
'Никто из разработчиков не может работать сразу на всех платформах'
от себя добавлю, что разрабатывать все равно приходится под разные платформы.
И к сожалению нет возможности разработать одно приложение работающее на нескольких платформах одновременно. Тут либо идти на упрощения (отходить от ТЗ и менять его), либо для каждой писать свое приложение (такой вариант в краткосрочной перспективе лучше и быстрей получается результат).
И если с серверной частью приложения все более или менее гладко, то с клиентской (HTML + JS) все довольно уныло.
К примеру на филипсе(NET-TV) туго обстоят дела с производительностью — и JS должно быть по минимум — иначе возникают тормоза в работе приложения — медленный отклик на попытку навигации с ПДУ. Сложно разрабатывать интерактивные приложения.
На Самсунге беда с нехваткой памяти (очень сложно добиться стабильной работы AJAX приложения), и из-за беды со сборщиком мусора затруднено использование сторонних библиотек, типа Jquery.
Везде используются разные стандаты: Philips — это CE-HTML, operaTV — обычный HTML5(даже с поддержкой тега VIDEO), SAMSUNG и LG — HTML4 (+ у каждого свой API для видео объекта).
на Philips перемотка в видеоплеере реализуется резким переходом на другой время 'seek(newTime)'
на Samsunge же есть возможность реализовать перемотку изменением скоростью воспроизведения (х2, х4)
практически везде беда с эмуляторами (а на каждую платформу получить тестовое устроиство — не всегда возможно):
в эмуляторе Philips не работает видеоплеер (не реализовано по лицензионным причинам… ) изза чего проблемно отлаживать этот видеоплеер
Эмулятор Самсунга нестабилен — и при использовании некоторых возможностей API приводит к крэшу эмулятора.
Уже молчу про то что поведение на эмуляторе не всегда аналогично устоиству.
Прежде чем начинать разработку для TV устроиства — лучше день-неделю потратить на изучение спецификации, а не читать ее по ходу разработки — иначе приходится порой все переделывать, по причине что чтото неучел и/или незнал.
Ну и малое кол-во информации в сети по данному вопросу затрудняет решение возникающих сложностей. методом тыка пытаешся решить проблему…
В общем высказался что наболело за последние месяцы активной разработки под TV платформы… :)
поправлюсь
stopPropagation() — не совсем дополнительная фишка событийности в zf2. А очень даже необходимый функционал.
Обработчикам нужен такой функционал, к примеру при проверки прав доступа: Если обработчик решит что недостаточно прав для доступа к какому-то ресурсу — то он вполне может захотеть прервать обработку события.
>мы сами назначаем когда закончить отдавать обработчикам несчастное событие и вернуть результат, тоже считаю что не совсем верно, это должно осуществляться в обработчике
Где-то это может и верно (JacaScript может,...), но идея событийности в zf2 (точнее в разрабатываемом прототипе MVC), заключается в том что обработчик ничего не знают о других обработчиках. И он не может знать нужно ли прерывать обработку других событий. Прерывание обработчиков — обязанность того — кто инициировал событие — инициатор события заинтересован в получении каких-то результатов от событий, а не наоборот (в этом смысле stopPropagation() — добавляет дополнительный функционал, а рабочей лошадкой является именно triggerUntil() ).
К примеру при выполнении ActionController::dispatch()
инициируется событие:
т.е. метод dispatch исполняет всех обработчиков, пока какой-нибудь обработчик не вернет объект Response.
На событие 'dispatch' могут быть подписаны разные обработчики — кто то занимается кэшированием, ктото ведением логов, проверкой прав доступа, еще чтото. Но методу dispatch() это не важно, он всего лишь хочет, чтоб хоть ктонибуть вернул Response.
Ну и соответственно обработчикам тоже все равно кто инициировал событие, и чего он хочет — они просто делают свою работу.
както так :)
1) Везде и во всем следовать ЛСП (для всего создавать базовый класс/интерфейс) довольно сложное занятие, и зачастую лишнее. Стараются эти интерфейсы определять для ключевых элементов фрэймворка.
2) Есть интерфейс EventDescription — если вы про него — оно и представляет собой событие (в статье про него не упоминается вроде)
3) есть класс ResponseCollection — он агрегирует результаты работы обработчиков.
4) Если вся претензия к «return ($r instanceof SomeResultClass)» то тут нет никаких противоречий.
Это говорит Менеджеру событий исполнять все обработчики, подписанные на событие, до тех пор, пока один из них не вернет результат работы типа SomeResultClass. Что это за класс (а результат работы обработчика не обязательно должен быть объектом, скалярные тоже пойдут) фрэймворк не описывает.
— Если опять не в тему — то сорри — не понимаю :)
Не уловил где противоречие… Есть интерфейс EventCollection, описывающий поведение объектов, способных к агрегации обработчиков событий и «запуск» выполнения этих обработчиков.
EventManager — объект реализующий этот интерфейс, и соответственно он может агрегировать и исполнять обработчики.
И если Вас не устраивает реализация EventManager, вы можете написать свой объект, реализующий интерфейс EventCollection — со своей логикой — и использовать его заместо EventManager. Главное условие, чтобы:
«Поведение наследуемых классов не должно противоречить поведению, заданному базовым классом, т.е. поведение наследуемых классов должно быть ожидаемым для кода, использующего переменную базового типа.» (с) Wiki
Только базовый класс здесь — интерфейс EventCollection.
PS.: метод triggerUntil объявлен в интерфейсе EventCollection
c beta1, имхо, поторопились. Документацию грубо говоря, собрали из набросков, часть которой была написана за пару дней до офф релиза beta1. Да и вообще .dev4 переименовали в beta1, просто для рекламы на ZendCon (Zend PHP Conference for Developers) — чтоб было что показать…
А что касается навигации в филипсе — у меня все впринципе более или менее:
1) Content-Type: application/ce-html+xml;charset=«UTF-8»
2) css3 spatial Navigation
и фокус ведет себя вполне корректно и дизайн вполне оправдывает ожидания
Но вот на динамической странице (где элементы навигации проподают/появляются или перемещаются) управлять этим spatial Navigation еще тот геморрой — но есть мысль написать API для этого — чтоб както автоматизировать процесс.
а вот при JS навигации, не используя css3 — тормоза при навигации оч заметные
если гденить в приложении есть это:
var element = $('#e1');
а потом гденить вызывается 'putInnerHTML' который удаляет этот '#e1', и поскок все это происходит в обход сборщика мусора, то значение переменной element — становится непонятным :)
и короче все начинает тупить и вылетать… поскольку повсеместно используется Jquery и прочие библиотеки. а они и не разрабатывались чтоб работать когда чтото будет удаляться в обход сборщика мусора
'Никто из разработчиков не может работать сразу на всех платформах'
от себя добавлю, что разрабатывать все равно приходится под разные платформы.
И к сожалению нет возможности разработать одно приложение работающее на нескольких платформах одновременно. Тут либо идти на упрощения (отходить от ТЗ и менять его), либо для каждой писать свое приложение (такой вариант в краткосрочной перспективе лучше и быстрей получается результат).
И если с серверной частью приложения все более или менее гладко, то с клиентской (HTML + JS) все довольно уныло.
К примеру на филипсе(NET-TV) туго обстоят дела с производительностью — и JS должно быть по минимум — иначе возникают тормоза в работе приложения — медленный отклик на попытку навигации с ПДУ. Сложно разрабатывать интерактивные приложения.
На Самсунге беда с нехваткой памяти (очень сложно добиться стабильной работы AJAX приложения), и из-за беды со сборщиком мусора затруднено использование сторонних библиотек, типа Jquery.
Везде используются разные стандаты: Philips — это CE-HTML, operaTV — обычный HTML5(даже с поддержкой тега VIDEO), SAMSUNG и LG — HTML4 (+ у каждого свой API для видео объекта).
на Philips перемотка в видеоплеере реализуется резким переходом на другой время 'seek(newTime)'
на Samsunge же есть возможность реализовать перемотку изменением скоростью воспроизведения (х2, х4)
практически везде беда с эмуляторами (а на каждую платформу получить тестовое устроиство — не всегда возможно):
в эмуляторе Philips не работает видеоплеер (не реализовано по лицензионным причинам… ) изза чего проблемно отлаживать этот видеоплеер
Эмулятор Самсунга нестабилен — и при использовании некоторых возможностей API приводит к крэшу эмулятора.
Уже молчу про то что поведение на эмуляторе не всегда аналогично устоиству.
Прежде чем начинать разработку для TV устроиства — лучше день-неделю потратить на изучение спецификации, а не читать ее по ходу разработки — иначе приходится порой все переделывать, по причине что чтото неучел и/или незнал.
Ну и малое кол-во информации в сети по данному вопросу затрудняет решение возникающих сложностей. методом тыка пытаешся решить проблему…
В общем высказался что наболело за последние месяцы активной разработки под TV платформы… :)
stopPropagation() — не совсем дополнительная фишка событийности в zf2. А очень даже необходимый функционал.
Обработчикам нужен такой функционал, к примеру при проверки прав доступа: Если обработчик решит что недостаточно прав для доступа к какому-то ресурсу — то он вполне может захотеть прервать обработку события.
Где-то это может и верно (JacaScript может,...), но идея событийности в zf2 (точнее в разрабатываемом прототипе MVC), заключается в том что обработчик ничего не знают о других обработчиках. И он не может знать нужно ли прерывать обработку других событий. Прерывание обработчиков — обязанность того — кто инициировал событие — инициатор события заинтересован в получении каких-то результатов от событий, а не наоборот (в этом смысле stopPropagation() — добавляет дополнительный функционал, а рабочей лошадкой является именно triggerUntil() ).
К примеру при выполнении ActionController::dispatch()
инициируется событие:
$result = $this->events()->trigger('dispatch', $e, function($test) {
return ($test instanceof Response);
});
т.е. метод dispatch исполняет всех обработчиков, пока какой-нибудь обработчик не вернет объект Response.
На событие 'dispatch' могут быть подписаны разные обработчики — кто то занимается кэшированием, ктото ведением логов, проверкой прав доступа, еще чтото. Но методу dispatch() это не важно, он всего лишь хочет, чтоб хоть ктонибуть вернул Response.
Ну и соответственно обработчикам тоже все равно кто инициировал событие, и чего он хочет — они просто делают свою работу.
както так :)
1) Везде и во всем следовать ЛСП (для всего создавать базовый класс/интерфейс) довольно сложное занятие, и зачастую лишнее. Стараются эти интерфейсы определять для ключевых элементов фрэймворка.
2) Есть интерфейс EventDescription — если вы про него — оно и представляет собой событие (в статье про него не упоминается вроде)
3) есть класс ResponseCollection — он агрегирует результаты работы обработчиков.
4) Если вся претензия к «return ($r instanceof SomeResultClass)» то тут нет никаких противоречий.
$results = $this->events()->triggerUntil(__FUNCTION__, $this, $params, function ($r) {
return ($r instanceof SomeResultClass);
});
Это говорит Менеджеру событий исполнять все обработчики, подписанные на событие, до тех пор, пока один из них не вернет результат работы типа SomeResultClass. Что это за класс (а результат работы обработчика не обязательно должен быть объектом, скалярные тоже пойдут) фрэймворк не описывает.
— Если опять не в тему — то сорри — не понимаю :)
EventManager — объект реализующий этот интерфейс, и соответственно он может агрегировать и исполнять обработчики.
И если Вас не устраивает реализация EventManager, вы можете написать свой объект, реализующий интерфейс EventCollection — со своей логикой — и использовать его заместо EventManager. Главное условие, чтобы:
«Поведение наследуемых классов не должно противоречить поведению, заданному базовым классом, т.е. поведение наследуемых классов должно быть ожидаемым для кода, использующего переменную базового типа.» (с) Wiki
Только базовый класс здесь — интерфейс EventCollection.
PS.: метод triggerUntil объявлен в интерфейсе EventCollection