← All posts tagged mate

yzh44yzh
mate Насчет модульности — карты либо в глобальной области видимости, либо в локальной, но при этом так изолированной, что оттуда никак не добраться до инфы вне этой области. Приходится добираться в обход Матэ. Что делает локальную карту непригодной. Ну а глобальная карта — какая уж тут модульность.
yzh44yzh
mate Вот есть одна вещь, которая конкретно раздражает в Матэ — он скрывает исключения. Из-за чего приходится все содержимое метода, вызываемого из карты, оборачивать в try catch, чтобы все-таки увидеть, а что там за исключение было.

Может и от Матэ отказаться? Вон Фарата пропагандируется вообще не юзать архитектурные фреймворки, и при этом с модульностью у них все в порядке. (А в Матэ, вообще-то, с модульностью не все в порядке :)
yzh44yzh
as mate Erlang Вот есть себе два изолированных модуля, взаимодействие с которыми идет через карту Матэ. Внезапно возникает задача сделать так, чтобы эти модули оказались в разных swf файлах и взаимодействовали через LocalConnection (ну или через JavaScript).

Вспоминается, что в эрланге такое было бы плевым делом. И хочется замутить что-такое и для AS. Что-то типа карты Матэ, но позволяющее разным swf обмениваться событиями точно также, как разные модули в одной swf.

Надо поискать, может есть где готовые JS мосты общего назначения для взаимодействия между swf
yzh44yzh
mate Опять повторилось — MethodInvoker из Mate, в методе срабатывает исключение, матэ его проглатывает и вызывает метод повторно.

Коварная вещь, и про нее нужно тупо знать. Ну я-то ужо знаю )
yzh44yzh
mate Матэ хорош, пока дело ограничивается глобальными картами. Ну или изолированными локальными, которые работают в своей песочнице. Когда дело доходит до того, что одни и те же объекты юзаются в разных картах, и должны уметь посылать события в разные карты, то простота и красота фреймворка продадает.

В конечно итоге все решаемо, но ценой избыточного кода и неуклюжих конструкций. О легкочитаемом коде речь уже не идет, и стороннему разработчику придется потрудится, чтобы понять, что к чему.
yzh44yzh
RtmpService mate Ух, поимел сча гемору. Ежели у нас два сервера и два RtmpService, то нужно, чтобы они работали изолировано друг от друга. А для этого нужно, чтобы у каждого было свой отдельный dispatcher, а не GlobalDispatcher (который в scope.dispatcher глобальной карты). Значит нужно каждому сервису свою отдельную локальную карту.

Но, в этих локальных картах будут использоваться всякие разные менеджеры, которы будут реагировать на события сервиса. Ну и ему посылать события. Менеджеры должны быть глобальные. Поэтому их нужно явно создать в глобальной карте прежде, чем к ним начнут обращаться локальные. И менеджерам нужно передать соотвествующие диспатчеры, позволяющие кидать события в нужные локальные карты нужным сервисам.

И еще был затык с CallbackRegistrator. Ему нужен и экземпляр сервиса, и экземпляр слушателя. А оные экземпляры лежат в разных кэшах. Пришлось доделать так:
<rtmp:CallbackRegistrator action="onUserJoin"
target="{UserListManager}"
serviceCache="local" targetCache="global"
method="onUserJoin"/>
yzh44yzh
RtmpService mate до сих пор во всех проектах RtmpService у меня был синглетоном, ибо клиент коннектился только к одному серверу. Сейчас понадобилось, чтобы клиент работал в двумя (или больше серверами). Пришлось чутка допилить rtmp-service-mate-ext.

В принципе работает, но надо работу с разными серверами делать в разных картах (но это по-любому так надо было бы просто с точки зрения здравого смысла). И везде, где в узлах встречается RtmpService и другие объекты из этой библиотеку, нужно пихать cache="local". А вот это уже потенциальный источник проблем, ибо об этом легко забыть.

Допилил логгинг в RtmpService, чтобы было видно, из какого экземпляра класса идут логи.

Ну и зарелизил версию 1.3
github.com
yzh44yzh
mate Бывают весьма нетривиальные случаи с исключениями. Допустим, есть такой код:
<mate:EventHandlers type="someEvent" debug="true">
<mate:MethodInvoker generator="{SomeManager}"
method="someMethod" arguments="{[event.prop]}"/>
</mate:EventHandlers>
Обычно, если внутри someMethod срабатывает исключение, то Mate корректно показывает его в консоли. Но, увы, это бывает не всегда. Я уже трижды сталкивался с ситуацией, когда это исключение не выводилось, код продолжал выполняться и давал загадочные побочные эффекты.

Но все три раза был один признак — метод someMethod вызывался дважды.

function ChangeMode()
{
trace("ChangeMode called");

// some code where exception is invoked
}

<EventHandlers (started) type="PublishModeEvent.CHANGED" (PublishModeChanged) scope="[object Scope]" useWeakReference="true" priority="0" dispatcherType="inherit" useCapture="false">
<MethodInvoker arguments="[ 1 ]" cache="inherit" registerTarget="true" generator="[class PublishManager]" method="ChangeMode"/>
ChangeMode called
ChangeMode called
</EventHandlers (end) type="PublishModeEvent.CHANGED" (PublishModeChanged)>

Что выглядит очень загадочно.

Но стоит обернуть тело метода в try-catch, как потеряное исключение становится видно.
function ChangeMode()
{
trace("ChangeMode called");
try
{
// some code where exception is invoked
}
catch(e : Error)
{
trace(e.getStackTrace());
}
}

<EventHandlers (started) type="PublishModeEvent.CHANGED" (PublishModeChanged) scope="[object Scope]" useWeakReference="true" priority="0" dispatcherType="inherit" useCapture="false">
<MethodInvoker arguments="[ 1 ]" cache="inherit" registerTarget="true" generator="[class PublishManager]" method="ChangeMode"/>
ChangeMode called
TypeError: Error #1009: Cannot access a property or method of a null object reference.
at bla-bla-bla
</EventHandlers (end) type="PublishModeEvent.CHANGED" (PublishModeChanged)>

Будьте бдительны :)
yzh44yzh
mate Матэ только снаружи кажется простым, белым и пушистым. Когда копаешься во внутренностях, там все не так просто :)
yzh44yzh
mate Это хорошо:
<mate:Injectors target="{TargetA}">
<mate:PropertyInjector source="{SourceA}" targetKey="prop" sourceKey="prop"/>
<mate:PropertyInjector source="{SourceB}" targetKey="prop" sourceKey="prop"/>
<mate:PropertyInjector source="{SourceC}" targetKey="prop" sourceKey="prop"/>
<mate:PropertyInjector source="{SourceD}" targetKey="prop" sourceKey="prop"/>
</mate:Injectors>

А это не очень хорошо:
<mate:Injectors target="{TargetA}">
<mate:PropertyInjector source="{SourceA}" targetKey="prop" sourceKey="prop"/>
</mate:Injectors>
<mate:Injectors target="{TargetB}">
<mate:PropertyInjector source="{SourceA}" targetKey="prop" sourceKey="prop"/>
</mate:Injectors>
<mate:Injectors target="{TargetC}">
<mate:PropertyInjector source="{SourceA}" targetKey="prop" sourceKey="prop"/>
</mate:Injectors>
<mate:Injectors target="{TargetD}">
<mate:PropertyInjector source="{SourceA}" targetKey="prop" sourceKey="prop"/>
</mate:Injectors>

Хочу так:
<mate:Injectors source="{SourceA}">
<mate:PropertyInjector target="{TargetA}" targetKey="prop" sourceKey="prop"/>
<mate:PropertyInjector target="{TargetB}" targetKey="prop" sourceKey="prop"/>
<mate:PropertyInjector target="{TargetC}" targetKey="prop" sourceKey="prop"/>
<mate:PropertyInjector target="{TargetD}" targetKey="prop" sourceKey="prop"/>
</mate:Injectors>

А ведь такое можно, наверное, сделать с помощью PropertySetter. Надо попробовать.
yzh44yzh
mate сделал расширение для Матэ для работы с медиа серверами (FMS, Red5, Wowza)
выложил на гугл-код code.google.com
пока не документировал (на днях напишу подробную статью в блоге от этом), но добавил туда небольшой sample project, в котором наглядно видно, как это расширение юзается.

Если кто-то заглянет в код одним глазом, и даст какой-нибудь фидбэк, буду очень благодарен.
yzh44yzh
mate отладка бывает очень коварной. Полдня возился с одним багом, в консоли полная фигня — какие-то сообщения, для которых я никак не могу построить гипотезу. trace, которые я пишу в коде, не работают, ничего не выводят.

Ребутал браузер, даже ребутнул ОС, Наконец, догадался заглянуть в .marcomedia/Flash_Player/Logs/flashlog.txt
А там все то, что отладчик никак не хотел мне показывать:

MATE Error: Argument type mismatch, turn on the debugger for more information
EventType:joinRoomSuccess. Error was found in a EventHandlers list in file ChatEventMap

И вот почему этого не было в консоли? хз (
yzh44yzh
mate Начал делать mate-extention для работы с медиа-серверами (FMS, Red5, Wowza). Прочитал доку ( mate.asfusion.com ), покопался в сорцах mate. Оказалось несложно.

Сделал RtmpServiceInvoker, который будет работать из карты событий так же, как HttpServiceInvoker и иже с ним.
<rtmp:RtmpServiceInvoker generator="{RtmpService}"
methodName="sendMessage" params="{['3', '4']}">
<rtmp:resultHandlers>
<mate:MethodInvoker generator="{MainManager}"
method="onSendMessage" arguments="{[currentEvent.data]}"/>
</rtmp:resultHandlers>

<rtmp:faultHandlers>
<mate:MethodInvoker generator="{MainManager}"
method="onError" arguments="{[currentEvent]}"/>
</rtmp:faultHandlers>
</rtmp:RtmpServiceInvoker>

Вызывать метод на FMS, получить ответ или error — это есть.

Далее нужно придумать, как будут работать методы, активно вызываемые со стороны сервера. Сделаю какой-нибудь registerCallback()

Потом нужен sample project, показывающий, как все это юзается на практике. (В идеале нужно показать его в работе не только с FMS, но и с Red5 и Wowza).

Выложить на гугл-код. Отписать в блоге.

А, еще сделать правильный логинг, а не тупые трейсы.
yzh44yzh
mate Мысли.
Тривиальная задача — получить с FMS данные, запихать их в модель. Нужно:
1. FmsClient — содержит методы, которые будут вызываться со стороны FMS.
2. Кастомное событие, которое будет передавать эти данные
3. Карта, которая знает, что делать с событием
4. Сама модель.

Что здесь лишнее? Ну без FmsClient и модели никак не обойтись. Хотя если подумать, то в самой модели можно сделать методы для приема данных сразу с FMS, но тут возникает целый ряд нюансов, которые нужно будет хорошо продумать (займусь на досуге).

Кастомное событие. В принципе можно обойтись без него, тупо использовать универсальное событие с неким data:Object внутри. Не смертельно. Но кастомное событие улучшит самодокументирование проекта.

Карта. Без нее нам нужно либо FmsClient должен знать о модели, чтобы пихать туда данные, либо модель должна знать о FmsClient, чтобы подписаться на событие. Карта рвет связи в обоих направлениях и делает обоих участников более простыми и более универсальными.

Вывод: пусть будут все 4 элемента, оно того стоит. Наверное.

Но вот очень интересно будет сделать так, чтобы сама модель принимала данные с FMS. Это пришло в голову, пока писал этот пост :)
yzh44yzh
mate Невозможность ходить по Ctrl+B со временем начинает раздражать. Приходится юзать Ctrl+Shift+F взамест, это намного медленнее. При рефакторингах случаются неприятные сюрпризы. Начинаю задумываться, что может это и не лучший выбор. Есть более старый проект без Мате. Не скажу, что он офигенно хуже супортится. Не хуже.

Все таки Яков Файн был прав в отношении архитектурных фреймворков. Они приносят столько же неудобств, сколько и выгод. Разве что добавляют ЧВС разработчику. Но это до поры до времени :)