Противоположный код позади во Flex

Question

Почему в Flex шаблон кода кода использует класс Actionscript в качестве базового класса вместо использования компонента MXML для этого?
Я имею в виду, вместо того, чтобы расширять наш код AS3 за классом, почему мы не расширяем нашMXML в новом классе AS3?

Использование этого подхода кажется более естественным, поскольку оно является реальным расширением, мы добавляем код и функциональные возможности в нашу базу MXML.
Использование шаблона с кодом является взломом для ООП, каждый раз, когда мы добавляем компонентк нашему MXML нам нужно изменить наш класс AS3, то есть, если мы модифицируем дочерний (MXML), нам нужно изменить и родительский (AS3).

Что не так с противоположным кодом (код впереди?)?

Answer 1

Основная причина, по которой код приобрел популярность, была связана с набором инструментов.Вы просто не можете перетащить компонент на основе AS3 в среду проектирования Flex Builder 3.Я пробовал различные обходные пути, но все они были проблематичными.Фактически, это было первое, о чем я писал в блоге: http://www.rogue -development.com / blog2 / 2007/03 / code-in-front /

Я непопробовал это в Flash Builder 4. Главным образом потому, что с тех пор я пришел к выводу, что гибкий инструмент макета - это дерьмо, и я его редко использую.Из-за этого все мои последние разработки были написаны на переднем плане.

Если вам нужно связать переменную в вашем MXML, вы определяете эту переменную в MXML, тогда она становится доступной через наследование в вашем подклассе..

Я не большой фанат искривления для компонентов с одной оболочкой.Если у вас есть компонент, который имеет только один визуальный вид, то код впереди гораздо проще разрабатывать.(Скиннинг идеально подходит для компонентов, которым требуется несколько скинов)

Answer 2

Именно поэтому Adobe решила перепроектировать свою архитектуру компонентов и создала набор компонентов Spark и соответствующий механизм оформления.

В этой новой (-ish) философии вы создаете класс ActionScript, расширяющий SkinnableComponent или SkinnableContainer., в котором вы описываете поведение вашего компонента.Затем вы можете создать класс обложки в MXML, который определяет, как будет выглядеть ваш компонент (и, возможно, какое-то визуальное поведение, но без существенного поведения компонента).

Это позволяет четко разделить проблемы.Это не противоположность кода, но это другой подход, который действительно хорошо работает, когда вы освоите его.

Answer 3

«Код впереди» является более естественным расширением и разработкой ООП, потому что мы расширяем наш MXML функциональными возможностями в AS3, и нам не нужно менять своего родителя каждый раз, когда мы меняем своего ребенка.

Но есть проблема, мы не можем использовать привязку в MXML, потому что теперь наш MXML является нашим базовым классом, и у нас есть наши переменные / функции в дочернем классе AS3.


РЕДАКТИРОВАТЬ: еще одна проблема с кодом впереди заключается в том, что вы не можете видеть "AS3 Componentte" в режиме разработки (не тестировался в FB4 +, возможно, он работает сейчас).Подробнее об этом читайте в ответе Марка Хьюза.

Answer 4

Я думаю, что причиной этого является унаследованная архитектура компонентов, унаследованная от Flash, когда вы перетаскиваете компонент черного ящика и, по крайней мере, немного возитесь со скином на уровне цветов / форм / шрифтов, а не(не могу) коснуться, как это работает.