![]() |
Отдельный класс под каждый Custom event?
Доброго времени суток,
необходимо обрабатывать два события для класса: onData и onError. Нашел пример класса для отдельного экземпляра, и немного дописал под себя: Код AS3:
Код AS3:
также, возможно ли какая-то обработка в конструкторе до вызова конструктора родителя? (аля установить переменную this.data если событие onData и переменную this.error если событие onError) видел топик на тему что тогда класс родителя может начать вести себя не так как предполагается.. но не смог вникнуть в суть. Чревато ли это чем-либо? Добавлено через 1 минуту P.S. также, если совместить два класса, придется вызывать метод super с одним из двух параметров (this.DATA или this.ERROR) |
1. можно.
2. можно, но у вас нет в этом необходимости. 3. в super передается тип события, параметр вашего конструктора который вы назвали error (для конспирации?). |
Спасибо за ответ,
Цитата:
P.S. По идее, можно сделать один параметр в конструкторе "data:String" и свойство data:String, в котором хранить данные, которые объект получает в конструкторе и я был бы беспредельно счастлив если бы смог бы чисто избавится от лишних классов, которые в любом случае приходится дефайнить в addEventListener с константой, но пугает метод super() Учитывая гибкость as, чувствую что что-то упустил. |
Вы можете несколько параметров в конструктор передать...
Код AS3:
|
Значение константы должно быть «controlType», а не «errorControl».
|
Спасибо. Буду приводить скрипты в порядок =)
|
Cудя по всему, Вы взяли мой пример из темы http://flasher.ru/forum/showthread.php?t=148963
Там совсем другой контекст, речь шла ИМЕННО о событиях с единственным типом. Будьте внимательней. В вашем случае я бы сделал так – Код AS3:
|
Wolsh, между именем константы типа события и его значением вполне есть устоявшаяся однозначная связь.
|
Возможно, это одна из концепций, которую я еще не готов разделить)) Кроме того, разные источники так же расходятся во мнениях по этому поводу - например ФД создает значения в camelstyle, а в книгах я видел варианты где все слова из имени сливались в одну прописную строчку. Когда нет однозначности, я делаю так, как кажется логичным мне. Со временем это может измениться))
В данном случае называть тип события "data" или "error" мне кажется опасным из-за "популярности" этих выражений. Лучшим решением, чем я тут предложил, было бы назвать константы позамороченней, чтобы избежать коллизий, тогда ДА, конечно, значение должно совпадать с именем константы. А ты мог бы обосновать, почему однозначно нужно пользоваться именем для значения? Ну так, чтоб не осталось никаких сомнений? |
Редакторы, в частности, FB, юзают метатег [Event], в котором тип события как раз указывается в camelStyle. При подписке на события, этот camelStyle превращается в UPPER_CASE прямиком конвертацией из name. Поэтому иное фактическое значение константы может сбить с толку как разработчика, так и некоторые фреймворки, использующие в рантайме эти метатеги и подписывающиеся на такие события.
Т. е. если у тебя SUPER_EVENT = "myCustomEventSuperEvent", а в метатеге для корректного автокомплита указано [Event(name="superEvent", type="my.custom.SuperEvent")] или не дай боже [Event(name="SUPER_EVENT", ...)], то фреймворк, юзающий этот самый метатег, подпишется не на то событие (если он не гениален и не сконвертирует в имя константы). Ещё хуже ситуация, когда в параметре name написано фактическое значение константы — фреймворк отработает на ура (если он при этом был гениален, то уже не отработает), а редактор же будет автокомплитить несуществующий SuperEvent.MY_CUSTOM_EVENT_SUPER_EVENT. Посему, дабы избежать подобных проблем, я использую чёткую связь между именами констант и их значениями, которая, кстати, прослеживается как в нативном фреймворке, так и во Flex, и во многих других. В данной ситуации надо просто назвать событие позамороченней. |
| Часовой пояс GMT +4, время: 13:16. |
Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.