![]() |
Как передать параметр в общую функцию события
Есть код:
Код:
function loadLibrary(name,path) { |
Вы знаете, что такое поля класса? Если в один момент времени может грузится только одна либа, то используйте поле класса для хранения данных. Если нет, то напишите наследника Loader с необходимыми полями и грузите через него. Соответственно, при получении события, можно сослаться на target и получить необходимые данные. Либо написать делегата:
Код:
function resizeHandler(event:Event, ...rest):void { |
Delegate работает как надо.
2 _etc огромное спасибо. |
Мне тоже Delegate очень помог.
>Хотя этот вариант не очень хорош. А в чем его недостатки? |
В том, что отписаться от такого обработчика сложно. Это как минимум.
|
ну например можно написать класс типа
Код:
//ChangeDateEvent.as |
расширять класс Event своим классом и передавать всё что нужно
|
Я тоже раньше думал что кастомные события покрывают весь спектор возможных случаев, пока не столкнулся с необходимостью передавать параметр.
|
Цитата:
У меня никогда не возникало ситуации, когда нужен подобный делегат. Snut, геттер и сеттер в событии не нужен, нужна обычная публичная переменная (кроме случаев, когда нужно сделать возможность указания значения только в конструкторе, тогда пишется только геттер). А ещё надо описывать метод clone(), иначе при всплытии события придёт не то событие, которое ожидаешь. |
Код:
package {Код:
l.contentLoaderInfo.addEventListener(Event.COMPLETE, function(e:Event){ |
CrazyFlasher, а clone() кто будет описывать?
Во втором коде откуда name у тебя возьмется? |
1. ага...я тут немного не тот пример указал...для dispatchEvent
2. что касается второго кода, то я просто не стал всё писать: Код:
function loadLibrary(name,path) { |
CrazyFlasher, вариант с анонимной функцией по-любому плохой.
|
Цитата:
Код:
addEventListener(CusomEvent.CUSTOM, param, true); |
болие надёжным каким боком? в данном примере ваш вариант просто ущербен.
|
Ну а как не ущербен?
|
Цитата:
|
ну как? тупо паблик вар. без гетеров и сеторов.
|
Цитата:
|
Цитата:
|
ну просто у меня черт знает откуда привычка создавать приватные переменные с гетерами сетттерами а не просто публичную
|
дурацкая привычка
|
вполне возможно
|
Можно сделать еще кастомные диспатчеры =) Тогда вообще всех покроют =)
BlooDHounD, почему дурацкая? Не менее дурацкая чем оставлять место для комментов в виде /**\n * \n */ или притормаживать перед пешеходным переходом :) Одна из основных идей создания g/s - это минимизация изменений для клиентов, ведь реализация всегда может измениться. Конечно, если это объект данных или Value Object то никто g/s делать не будет, но если логика в этом месте может появиться - то почему нет. |
Цитата:
|
etc, ну, и я о том же.
Кстати, я тебя уважаю, но делегат с предыдущей страницы это [censored] всему живому :) Но круто, конечно :) |
Slon_vsapogax, а у нас на форуме не матерятся.
Делегат был написан в качестве примера, что передать параметры вообще можно, но применять его на практике не стоит, уже который раз пишу. По-хорошему, надо писать наследника Loader (или что там) и сохранять параметры в нём. |
Цитата:
|
Rzer:
для твоего случая я знаю два более-менее подходящих подхода: - создать наследника Loader и нужные данные хранить в нем - создать Dictionary и хранить там нужный параметр или объект данных. |
Цитата:
Просто по одной простой причине, что если используются и геттер и сеттер, то никакой выгоды в этом нет. К тому же, жрет лишнюю память. |
__etc:
такие темы обычно скорее холивар, чем обсуждение. Поэтому каждый разработчик должен решать сам для себя что ему ложится на сердце. Но, в таком случае, не стоит упрекать за выбор, какой бы он ни был. К слову сказать, в среде джава разработчиков холивар на эту тему давно ушел в спор допустимости использования приватных переменных без использования методов доступа. О допустимости применения публичных переменных никто и не заикается. |
Ну холивар я разводить тут не собираюсь, привычка делать приватные переменные с публичными геттерами и сеттерами безусловно хорошая.
|
| Часовой пояс GMT +4, время: 20:43. |
Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.