Целомудрие - самое неестественное из сексуальных извращений.
Автомашина — комфорт самоистребления.
Эта заметка - перевод статьи 10 tips for working with cairngorm. Фельетон показалась мне шибко интересной и полезной в плане общих советов по применению фреймворка, особенно в первостепенной важности раз. За перевод благодарствую Виноделу.
Это Применимо к Flex 2.0.1 с любой версией Cairngorm. Поскольку опыт программирования во Flex у всех различен, это не факты, а как мое мнение, основанное на моем более чем двухлетнем опыте использования ARP & Cairngorm. Побольше того, существуют альтернативы Cairngorm, при всем при том я не могу испытывать их столько, сколько хочу.
Поскольку я работаю именно над продуктом, я не могу по своему усмотрению «забрать и попробовать эту среду на этом новом проекте». Я работаю с одним и тем же базовым кодом, поддерживая существующих клиентов, и не могу совершать резких изменений в кодировании, не рискуя быть уволенным.
1. Если Cairngorm кажется вам сложным, не волнуйтесь, это так и убирать за обе щеки, вы не одиноки.
"Куча кода на _root вместо всех сих классов и соглашений? Это займет целую вечность!". На самом деле к этому надо просто вжиться. Я почувствовал себя уверенно с Cairngorm только на четвертом проекте. Все-таки до сих пор я совершенствую манера работы, пробую неодинаковые дурь. Чем больше людей приходят во Flex, тем все больше кульных идей и технарь появляется около.
2. Вам кажется, что у вас поначалу уйдет гораздо времени только на то, чтобы общий что-то выделать в Cairngorm. И это так оно и есть..
OMFG… три класса для того, что во флеше заняло бы одну строку?
Стимулятор кода поможет, особенно на начальной стадии работы над проектом.
3. Только Commands устанавливают талант в Model; вы можете это побороть, но не есть расчет, буде можете исправить код.
В Model View Controller, только Controller устанавливает данные в Model. В этом случае Commands выступают в качестве Controller (обычно) и в качестве таковых течение данных ModelLocator – их единственная работа. Если данные на@бываются, вам сию минуту удобопонятно, что накосячил Command. Вам никогда не нуждаться задавать вопрос «кто устанавливает мои документация, где и когда?».
4. Delegates заставляют сервер вызывать и парсить данные (иногда в Factory).
Это произошло в моей карьере лишь раз как-то: я работал с PHP для серверной части, которая парсит XML, в зенит проекта мы переключились на OpenAMF и Java, где пришлось парсить объекты. При использовании Delegates вам придется только поменять код Delegates, не трогая остальную часть вашего приложения. Талантливость Commands сохранятся.
Я пользуюсь Factories только ибо, что
A) для парсинга может понадобиться пропасть кода, а вы не хотите, в надежде Delegates выглядели паче сложно, чем они есть
B) вы еле ощутимо можете выделить процесс парсинга в том же классе Factory.
5. Если вы видите, что Command парсит данные, он написан неправильно.
Парсинг отличается от фильтрации, изменения и ассемблирования. Это из этого явствует, что изготавливать Value Objects из XML скорее в Delegate, а не в Command. Нормально и перевязывание с ArrayCollections, содержащими предустановленные значения. Помните, что разве Command получает необработанные серверные эмпирика, - вы или некорректно используете Delegates, или у вас правильно работает AMFPHP/FDS/WebOrb, хехе.
6. Существует три способа использования Commands и Delegates. Я предпочитаю А, так как он дает небольшие файлы классов и очень членораздельный.
A) Для каждого случая использования создается Вотан Command и Водан Event. А иногда нужно сделать и Водан Delegate. (например LoginEvent, LoginCommand, LoginDelegate)
B) Для каждого случая использования вы можете упаковать их в Водан пакет.
Скажем, Login, ChangePassword, ForgotPassword составили бы один отлично. В этом случае для определения запускаемой части используются константы. (то набивать себе брюхо, у LoginEvent пилить LOGIN, CHANGE_PASSWORD, и FORGOT_PASSWORD, являющиеся String константами. У LoginCommand есть switch, который определяет команду, которая должна быть запущена. У LoginDelegate есть три метода: login, changePassword, и forgotPassword которые может использовать Command.
C) Вариации на тему Б. Надо думать существование одного Event и одной Command, но нескольких Delegates.
Этот пункт – типа обобщающий, на какой есть шанс. Я повидал мульти вариантов, которые дозволяется назвать “В с вариациями”.
7. ViewLocators считаются «плохой эмпирически».
Значит, хряпать разработчики, которые до сих пор их любят и используют.
Хотя использование чисто в таком варианте: кабы зудить View, что знает, нет-нет да и в Command что-то произошло. Я использую callbacks: изменения данных в Model вызывают callbacks во Views (возможно, через setter), а некоторые люди используют addEventListener совместно с CairngormEventDispatcher.
8. ViewHelpers считаются плохой опытным путем.
То есть существуют разработчики, которым нравится идея выделения программного кода от заключение разметки. Я видал соответствующие темы в блогах и в списках рассылки. Загрызть две общие идеи:
A) Им не нравится мешать в одну кучу ActionScript & MXML.
B) Они хотят отделить View's от "View controller code"
Часть используют скриптовые теги для указания на бьющий файл (по моему мнению – дребедень; вам придется определить контроллеры как руки и ноги-переменные а закончите вы тем, что будет в два раза все больше классов View).
Некоторые используют наследование там, где вы расширяете GUI MXML.
Кое-кто используют обратное и расширяют GUI MXML с ActionScript ViewHelper.
Некоторые в основных чертах придерживаются подхода при котором Composition наследуеся от MovieClip , что я многократно видел у кодеров на Flash. Чем ViewHelper , расширяющего класс видов, он принимает UIComponent в качестве параметра конструктора, и использует UIComponent через композицию.
Мне думается, вы с сим разберетесь как токмо разберетесь во Flex. Пишите домашние компоненты в MXML с кодом в скриптовых тегах. Иначе будет то на деле нужна действенность или хотите начать писать на низком уровне, на классах абстрактного типа, можете писать свои компоненты на ActionScript. Разве же хотите закончить «до заката» - используйте MXML.
9. Вместо flash.net.Responder используйте mx.rpc.Responder.
Да, это неудобно, так как Flex 2.0.1 не предоставляет исходников (эта новость уже устарела - прим. перев.), но, по-моему, Flex Builder не жуть до чего хорошо справляется с классами с одинаковыми названиями. Просто пользуйтесь тем, что использует Flex и бросайте работу. Разве что кто-то требует flash.net.Responder - напишите враппер, с тем чтобы перевести его во Flex.
«Сэр…Вам нужен галстук чтобы войти в ресторан. У нас хрумать один, минутку»
10.Делайте так, ради View не использовали CairngormEventDispatcher (или действие, которые работают с CairngormEvent, используя event.disaptch()).
За сего делайте “живо” транслируемые события View.
Или соедините их так, чтобы контроллер View мог создавать перипетии Cairngorm, или постройте их «типа домино».
Обычный сценарий, в отдельных случаях itemRenderer - это классы в DataGrid.
Вы:
- делаете класс itemRenderer. Коли есть что-нибудь «кликабельное», посылается обычное событие по «клику».
- расширьте DataGrid тот или другой использует звезд с неба не рвет itemRenderer, и поместите обычное сенсация в <mx:Metadata> над головой. В противном случае классом, кто содержит DataGrid и хорошего понемножку допущен к подключению к событиям через MXML, брось чуть только ActionScript.
Если вы используете MXML, то сочинение не удастся, поскольку у DataGrid нету такого события в его исходном коде.
Поначалу может почудиться круто иметь LoginForm чтобы передавать LoginEvent, но хорошенького понемножку неудобно ставить на службу его для других целей; это «тяжеленько написано» для того, чтобы использовать особого CairngormEvent. Применяется это ко всем компонентам. Инкапсулируйте ваши компоненты, и лучшее, что вы можете - сделать события всплывающими.
Поездка на Черное море на машине. Часть 2: дорога Вологда Анапа
О сайте
Новогодние Пазлы
Комментариев нет:
Отправить комментарий