#apache-flex #code-behind
#apache-flex #код позади
Вопрос:
Почему в шаблоне Flex код, лежащий в основе шаблона, использует класс Actionscript в качестве базового класса вместо использования компонента MXML для этого?
Я имею в виду, вместо того, чтобы расширять наш код AS3 за классом, почему мы не расширяем наш MXML в новом классе AS3?
Использование этого подхода кажется более естественным, потому что это реальное расширение, мы добавляем код и функциональные возможности в нашу базу MXML.
Использование шаблона code behind — это взлом ООП, каждый раз, когда мы добавляем компонент в наш MXML, нам нужно модифицировать наш класс AS3, то есть, если мы модифицируем дочерний (MXML), нам также нужно модифицировать родительский (AS3).
Что не так с обратным кодом позади («код впереди»?)?
Ответ №1:
Отчасти поэтому Adobe решила переработать свою компонентную архитектуру и создала набор компонентов Spark и соответствующий механизм скининга.
В соответствии с этой новой философией вы создаете класс ActionScript, который расширяет SkinnableComponent или SkinnableContainer, в котором вы описываете поведение вашего компонента. Затем вы можете создать класс обложки в MXML, который определяет, как будет выглядеть ваш компонент (и, возможно, некоторое визуальное поведение, но не существенное поведение компонента).
Это позволяет четко разделить проблемы. Это не противоположность code-behind, но это другой подход, который работает действительно хорошо, как только вы освоитесь с ним.
Комментарии:
1. Да, но почему Adobe предложила код позади вместо «кода впереди»? и почему ни один орган не использует этот подход (по крайней мере, я не вижу его ни в одном учебнике / руководстве). Я имею в виду, почему шаблон «код впереди» не существует? что с ним не так? Я не использую код позади, и я думаю, что я также не буду использовать «код впереди», но мне любопытно, почему никто не предложил это как решение (даже лучше, чем code behind).
2. Мне кажется, что независимо от того, кодируете ли вы позади или впереди, оба класса в любом случае тесно связаны. Единственная причина использовать любой из этих подходов — отделить ваш код MXML от вашего кода AS. Это не имеет ничего общего с разделением задач, это просто делает ваши классы более удобочитаемыми.
3. да, но код впереди — это реальное расширение, код позади — нет. У нас есть чистый класс просмотра MXML и чистый класс AS3, который расширяет этот MXML, и, следовательно, оба класса можно использовать, причем код, лежащий в основе вашего класса AS3 (base), бесполезен без вашего MXML, и если вы что-то измените в своем дочернем (MXML), вам также нужно изменить родительский (AS3)! возможно, я не очень хорошо это объясняю, но я думаю, что должна быть причина для выбора кода позади вместо кода впереди, это не произвольно, это шаблон проектирования. У кода впереди должна быть проблема / недостаток, но я этого не вижу.
4. Я думаю, что нашел недостаток для «кода впереди», с кодом позади вы можете использовать привязку в своем MXML, с кодом впереди вы не можете, потому что ваши переменные / функции находятся в AS3, и ваш MXML этого не знает. Возможно, именно по этой причине «код впереди» никогда не предлагался как решение в Flex.
5. Хороший улов. Вот почему — прежде чем я пошел по пути Spark — я создавал отдельные классы ‘presentation model’ и ‘controller’ для каждого компонента mxml вместо того, чтобы использовать код позади или спереди.
Ответ №2:
Основная причина популярности кода, лежащего в основе, заключалась в инструментах. Вы просто не можете перетаскивать компонент на основе AS3 в среде разработки Flex Builder 3. Я пробовал различные обходные пути, но все они были проблематичными. На самом деле, это было первое, о чем я когда-либо писал в блоге: http://www.rogue-development.com/blog2/2007/03/code-in-front /
Я не пробовал повторно использовать это во Flash Builder 4. В основном потому, что с тех пор я пришел к пониманию, что инструмент flex layout — дерьмо, и я редко им пользуюсь. Из-за этого вся моя недавняя разработка была code-in-front.
Если вам нужно выполнить привязку к переменной в вашем MXML, вы определяете эту переменную в MXML, затем она доступна через наследование в вашем подклассе.
Я не большой поклонник скининга spark для компонентов с одной оболочкой. Если у вас есть компонент, который имеет ровно один визуальный вид, с помощью кода впереди намного проще разрабатывать. (Скининг идеально подходит для компонентов, которым требуется несколько скинов)
Комментарии:
1. вау! спасибо, Марк, теперь я не так одинок :). Представление дизайна также является дополнительной проблемой, я этого не знал (в любом случае, я также не тестировал в FB4). Но я думаю, что наиболее важным является привязка, если вам нужно определить переменные в MXML для их привязки, тогда вам нужно добавить AS к вашему MXML (и это то, чего мы пытаемся избежать) больше, если вам нужно привязать какой-либо геттер. Я думаю, что обеих причин достаточно для существования кода и для того, чтобы не использовать код впереди. Если вы хотите, чтобы код был впереди, используйте meadiators, это лучший шаблон (я использую его, но мне было любопытно, почему adobe предложила код позади).
Ответ №3:
«Код впереди» — это более естественное расширение и дизайн ООП, потому что мы расширяем наш MXML функциональными возможностями в AS3, и нам не нужно менять нашего родителя каждый раз, когда мы меняем нашего потомка.
Но у этого есть проблема, мы не можем использовать привязку в MXML, потому что теперь наш MXML является нашим базовым классом, и у нас есть наши переменные / функции в дочернем классе AS3.
РЕДАКТИРОВАТЬ: еще одна проблема с кодом впереди заключается в том, что вы не можете видеть свой «AS3 componente» в режиме разработки (не тестировался в FB4 , возможно, он работает сейчас). Подробнее об этом читайте в ответе Марка Хьюза.
Ответ №4:
Я думаю, причиной этого является устаревшая архитектура компонентов, унаследованная со времен Flash, когда вы перетаскивали компонент черного ящика и, самое большее, немного возились с обложкой на уровне цветов / форм / шрифтов и не (не могли) коснуться того, как это работает.