Форум Flasher.ru

Форум Flasher.ru (http://www.flasher.ru/forum/index.php)
-   ActionScript 3.0 (http://www.flasher.ru/forum/forumdisplay.php?f=83)
-   -   Свое всплывание событий. (http://www.flasher.ru/forum/showthread.php?t=145627)

Zebestov 14.10.2010 16:12

Свое всплывание событий.
 
Всем привет. Тут мелькала эта идея, но я шота не могу понять как сделать.
Входящие данные:

1. события разные. 99% — уже имеющийся в AS3 набор.
2. всплывать событиям придется в иерархии объектов типа EventDispatcher (?)
3. надо сохранить target

нид хелп короч.

passertm 14.10.2010 16:15

не совсем понятна задача.
чем EventDispatcher плохо?
да target не получается заменять. мне тоже это показалось странным.
нужно будет свои евенты наследовать и реализовывать.

dimarik 14.10.2010 16:18

Всплытие нативно поддерживается только DisplayObject'ом (участвует его #parent). Можете построить аналогичную систему или стройте иерархию, используя базовыми классами Shape, Sprite, etc.

Zebestov 14.10.2010 17:40

Так вот и спрашиваю, как построить аналогичную систему =)
DisplayObject — крайний случай.

etc 14.10.2010 18:10

Собственно, target можно хранить статически во время всплытия.

zuxul 14.10.2010 18:30

Чтобы сохранить таргет (только для своих классов Event-ов)
1) override get target
2) override clone

BlooDHounD 14.10.2010 18:31

etc нельзя. тогда произойдёт колапс, когда одно событие рождает другое.

etc 14.10.2010 18:41

Цитата:

Сообщение от BlooDHounD (Сообщение 942728)
etc нельзя. тогда произойдёт колапс, когда одно событие рождает другое.

А, ну да, простите.

Zebestov 14.10.2010 20:31

Теперь target всегда сохраняется при клонировании и его не нужно явно передавать в конструктор MyEvent()

Код AS3:

package {
 
        import flash.events.Event;
 
        /**
        * ...
        * @author Vadim BELLinSKY
        */

 
        public class MyEvent extends Event {
 
                private var _target:Object;
 
                public function MyEvent(type:String, bubbles:Boolean = false, cancelable:Boolean = false, target:Object = null):void        {
                        super(type, bubbles, cancelable);
                        this._target = target;
                }
 
                override public function clone():Event {
                        return new MyEvent(super.type, super.bubbles, super.cancelable, this.target);
                }
 
                override public function get target():Object {
                        return this._target ? this._target : super.target;
                }
        }
}

UPD
Вообще все затевается ради всплывания событий в дереве моделей... я начинаю думать, что это лишнее.
Зачем какой-то модели следить не за непосредственно подопечными, а и за их подопечными.
Ну т.е. если меняется дочерняя модель — событие CHANGE, на которое реагирет изменениями текущая модель, что вызывает тот же CHANGE уже для его родителя.
Поправьте, есличё.

BlooDHounD 14.10.2010 21:45

из последний 3х предложений не понял ничего.

Zebestov 14.10.2010 21:49

одним предложением: а точно ли нужно всплывание событий в дереве моделей (MVC)?

Psycho Tiger 14.10.2010 22:01

Очень редко, но бывает нужно. В таких случаях я просто редиспатчу событие наверх.

Добавлено через 2 минуты
Цитата:

Сообщение от BlooDHounD (Сообщение 942728)
etc нельзя. тогда произойдёт колапс, когда одно событие рождает другое.

Не совсем понимаю почему.

Zebestov 14.10.2010 22:07

Цитата:

Сообщение от Psycho Tiger (Сообщение 942769)
Очень редко, но бывает нужно. В таких случаях я просто редиспатчу событие наверх.

ну как бы и я планировал редиспатчить. для того и затеял этот класс, для сохранения target-а.

Psycho Tiger 14.10.2010 22:11

Цитата:

Сообщение от Zebestov (Сообщение 942773)
ну как бы и я планировал редиспатчить. для того и затеял этот класс, для сохранения target-а.

В моей практике не встречалось такого, что target нужно было перекинуть через модель/контроллер. Обычно всё фаршируется уровнем выше, фарш в котлеты ещё уровнем выше и так далее. Событие-уведомление, что что-то произошло - да, достаточно часто.

Но ничего не имею против перекидывания target более старшим. Если не секрет, поделись почему возникла такая необходимость.

Zebestov 14.10.2010 22:16

секрет... для меня в первую очередь :D
поставил задачу, решил. а пригодится или нет — там посмотрим. только приступаю.

dimarik 14.10.2010 22:42

Очень удобно знать таргет "наверху". "Там" можно проверить источник, который сгенирил ADDED или REMOVED, например. А таргетом может оказаться как ветка модели, так и её листок. Ответственное представление добавит/удалит подчиненные представления, ассоциированные с таргетом. Реализовать таргет нетронутым, если он был впервые установлен, в кастомном классе не должно составить труда. Но я упертый ) И пропагандирую использовать в деревьях то, что уже написано до нас - DisplayObject.

Zebestov 14.10.2010 22:51

Цитата:

Сообщение от dimarik (Сообщение 942782)
пропагандирую использовать в деревьях то, что уже написано до нас - DisplayObject.

та оно да.
но когда только ради всплывания надо наследоваться от объекта с тучей ненужного борохла — меня как-то коробит... "неаккуратненько как-то" ©
и навязчиво.

dimarik 14.10.2010 22:55

Зато нативно и шустро.

Zebestov 14.10.2010 22:57

блин... смириться что ли с тем, что разрабы провоцируют носить кирпичи в сумочке от GUCCI :quiet:

dimarik 14.10.2010 23:05

Взвесьте "за" и "против" и решайте ).

Psycho Tiger 14.10.2010 23:40

Zebestov, ну раз у тебя не практическая задача требующая решения - я думаю пока и взвешивать рано. Попробуй это дело на практике, там будет куда виднее. На данный момент я однозначно против моделей из DO. Пожалуй, самый везкий аргумент - это очень много всякой ерунды по автокомплиту валится, а эксклудить лень ) Ну, а если серьезно - просто нужды не было острой нужды в шустром и простом с точки зрения программиста бабблинге.

BlooDHounD 15.10.2010 03:38

@dimarik, странная пропаганда. памяти больше многократно и время создания больше многократно. но, до .. я же забыл! на бублинг всего в 2 раза быстрее! в общем пропагандируй =)

etc 15.10.2010 16:04

Цитата:

Сообщение от Zebestov (Сообщение 942788)
та оно да.
но когда только ради всплывания надо наследоваться от объекта с тучей ненужного борохла — меня как-то коробит... "неаккуратненько как-то" ©
и навязчиво.

Ну, [Exclude] не отменяли.

Добавлено через 1 минуту
Цитата:

Сообщение от Psycho Tiger (Сообщение 942769)
Не совсем понимаю почему.

Ну первое событие пойдет дальше. Какой у него target будет?

arkadattx 15.10.2010 16:28

Цитата:

Ну, [Exclude] не отменяли.
А можно поподробней? Это команда какая-то хитрая? Или я не так понял.

etc 15.10.2010 16:34

Цитата:

Сообщение от arkadattx (Сообщение 942921)
А можно поподробней? Это команда какая-то хитрая? Или я не так понял.

Это метатег, можно поставить его над теми методами/свойствами, которые необходимо скрыть из автокомплита. Актуально для Flash Builder.

Zebestov 15.10.2010 17:04

Цитата:

Сообщение от etc (Сообщение 942906)
Ну, [Exclude] не отменяли.

Я так понимаю, это "косметическая операция". В памяти все равно создается весь DO со своим прицепом — я на это сетовал.

Psycho Tiger 15.10.2010 18:13

Цитата:

Ну первое событие пойдет дальше. Какой у него target будет?
Изначальный и будет. Можно на пальцах что происходит, я похоже просто туплю.

zuxul 15.10.2010 18:35

На пальцах:
Как сделать рэ-диспатч при баблинге?
Делается примерно так - parent.dispatshEvent(event), так вот, при этом таргет-ом будет уже parent, а не его ребенок который испустил всплывающее событие.

Zebestov 15.10.2010 18:36

Цитата:

Сообщение от Psycho Tiger (Сообщение 942967)
Изначальный и будет. Можно на пальцах что происходит, я похоже просто туплю.

target всегда указывает на диспатчера — из-за этого и весь сыр-бор. при искусственном баблинге предполагается редиспатч события с потерей начального target-а. приведенный класс решает эту проблему.


Часовой пояс GMT +4, время: 02:35.

Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.