Delphi, FireMonkey, All-Access и иные приятные сюрпризы. FireMonkey
Читайте также
TRippleEffect класс для создания эффекта, который накладывает рябь волн на текстуру визуальных объектов.
Центр ряби указывается в свойстве Center . Другие аспекты ряби можно настроить при помощи свойств Amplitude (Амплитуда), AspectRatio , и Phase (Фаза). Количество волн ряби определяется свойством Frequency (Частота).
В следующей таблице показаны результаты влияния TRippleEffect на PNG фотографию, размещенную на форме (с помощью объекта ). Центр ряби находится в середине изображения. Остальные свойства TRippleEffect используются с их значениями по умолчанию (Amplitude = 0,1, AspectRatio = 1,5, Frequancy = 70, Phase = 0).
В этом уроке вы будете использовать несколько базовых эффектов изображений в приложении FireMonkey.
Шаг 1: Применить эффект к изображению.
В FireMonkey, применение эффекта изображения к изображению является простым процессом. Просто создайте компонент, который может содержать изображение, а затем примените один из эффектов изображения.
Создайте новое приложение FireMonkey (File> New> FireMonkey Desktop Application> HD FireMonkey Application ).
Поместите компонент на форму.
Выделите компонент на панели инструментов.
Расположите TImage на форме в конструкторе.
Вы можете видеть, что компонент не помещается в центр конструктора форм. Как показано на рисунке, необходимо, чтобы размер области изображения был как можно больше. Чтобы сделать это, выберите компонент на форме конструктора, а затем изменить свойства Align в alClient в Object Inspector, чтобы размер компонента стал таким же, как клиентский размер области формы.
Выберите изображение, к которому вы хотите применить эффект. Компонент хранит картину в свйостве Bitmap . Выберите свойство Bitmap в объектном инспекторе, и используя Edit ... для выбора изображения.
- Теперь вы можете выбрать эффект для изображения. На палитре инструментов выберите TRippleEffect .
Теперь RippleEffect отображается в в окне Structure .
Чтобы применить эффект он должен быть определен как дочерний для другого компонента. В этом случае, RippleEffect1 должны быть определены в качестве дочернего Image1 . Чтобы это сделать, перетащите RippleEffect1 и поместите его на Image1 на панели структуры.
- Теперь вы можете видеть, что RippleEffect уже работает на Form Designer.
- Измените свойство Frequency на 20 .
Шаг 2: Применить эффект анимации к эффекту RippleEffect.
Выделите RippleEffect на панели Structure .
Выделите свойство Phase в Object Inspector и выполните команду Create New TFloatAnimation из выпадающего меню.
Убедитесь, что FloatAnimation1 определена как дочерний элемент RippleEffect1 .
Измените свойства FloatAnimation1 как показано ниже:
Ну и напоследок добавим событийную процедуру OnMouseMove к .
FireMonkey — это центральная технология «нового Delphi». Расскажите, пожалуйста, о целях, возможностях и технических аспектах устройства этой принципиально новой библиотеки. По истечении времени, оглядываясь назад, насколько тяжелым и оправданным оказался ваш отказ от дальнейшего развития сверхпопулярной VCL?
Была выбрана в качестве магистрального направления развития технологии Delphi для достижения конкретной цели — мульти-платформенной разработки из одной среды, на основе единой базы исходных кодов, причем без необходимости в кардинальной переподготовки разработчиков. В рамках ставшей классической и сверхпопулярной VCL это было невозможно, её связь с WinAPI была слишком тесной, можно сказать, «на генетическом уровне».
Компоненты VCL не имели «абстрактной» прослойки между функциональным уровнем с точки зрения интерфейса и механизмами их отображения. Функциональный уровень — то, как вёдет себя как элемент управления, на какие события реагирует, какое взаимодействие с пользователем обеспечивает. Отображение — вызов платформенно-ориентированных методов визуализации как некого изображения, сформированного растровыми объектами и векторными примитивами. FireMonkey изначально реализовывала принцип строгого разделения элемента управления на две составляющие: «поведенческую» и «визуальную».
Всеволод Леонов, Embarcadero Technologies
Первая в целом повторят даже не основы VCL, а суть объектно-ориентированного программирования. Компонент есть класс, классы компонентов образуют иерархию, где можно выделить семейства и модули. Класс компонента слабо связан с тем, как он изображается.
Визуальная «картинка» формируется динамически, она не прописана жёстко в классе компонента. Изображение или «стиль» в FireMonkey загружается в компонент при запуске приложения. Мы имеем некий функциональный каркас для компонента, а «обшивка» или «облицовка» может быть изменена, но зачем? Именно затем, чтобы приложения FireMonkey смотрелись аутентично на любой платформе — Windows 7, Windows 8, Mac OS, iOS и, в ближайшем будущем, в Android. Этого традиционная монолитная классовая структура VCL обеспечить не могла.
Здесь особую роль играет технологичность подхода. Принципиально можно взять библиотеку VCL и «нафаршировать» WinAPI и всеми другими возможными платформенными вызовами. На очень ограниченном подмножестве компонентов это ещё можно сделать, но VCL содержит несколько сотен компонентов, поэтому такой подход мог бы просто «убить» VCL. Было принято решение «не трогать» VCL, а новые возможности развивать на новой платформе — FireMonkey. Данная технология даже обладает определённым техническим изяществом — в момент сборки проекта под конкретную платформу среда Delphi IDE подключает нужный компилятор, а компоненты интерфейса получают платформенный стиль.
Для пользователя это — один щелчок мыши и то же исходный код, для Delphi, — многолетний упорный труд разработчиков по созданию подобной мульти-платформенной библиотеки.
Когда стало ясно, что FireMonkey будет введена отдельной новой платформой, нужно было выбрать правильную стратегию сосуществования: Embarcadero не хотела никоим образом оказать негативное влияние на пользователей VCL. Поэтому мы выбрали следующий план: VCL остаётся идеологически и архитектурно стабильной для обеспечения максимально возможной совместимости, облегчая миграцию проектов на современные версии. Развитие FireMonkey будет идти естественным и параллельным путём, без «оглядки» на VCL.
Слабым местом такого решения является достаточно проблематичная миграция с VCL на FireMonkey в рамках одного проекта. Но зато для нового проекта разработчик может выбрать FireMonkey для обеспечения мульти-платформенности своего результирующего приложения. После релиза XE4 с поддержкой iOS мы уже можем говорить о ярких конкурентоспособных преимуществах Delphi для начала мобильной разработки в корпоративной среде, которые буду увеличены после реализации планируемой поддержки Android.
Поэтому как такового явного «отказа» от развития VCL нет. В новых версиях VCL-часть Delphi также развивается. Это и поддержка 64-bit, и введение стилизации для визуальных компонентов, и реализация механизма гибких динамических связей или «байндинга», и включение библиотеки FireDAC для работы с базами данных в VCL-проектах. Просто на фоне гигантского качественного скачка за счёт FireMonkey прогресс в VCL выглядит несколько непроявленным. Но, как бы то ни было, VCL — неотъемлемая часть Delphi и останется таковой ещё на долгие годы. Хотя эволюция платформ и современное положение дел в области ОС для настольных систем и мобильных устройств таковы, что будущее однозначно за FireMonkey.
В интервью мы уже обсудили поддержку iOS, давайте расскажем нашим читателям о поддержке других новейших технологий со стороны последней RAD Studio XE4, например, таких как Windows 8 и WinRT, 64-битных систем, MacOS и так далее. Можно перечислить, что вы ещё можете предложить современному избалованному новшествами программисту?
Скорее всего, современный программист не «избалован» новшествами. Для крупных проектов любое «новшество» зачастую оборачивается гигантским объемом работ.
Например, все долго ждали , многие тут же бросились переводить свои коды на новую платформу. Но выясняется, что даже весьма профессиональные команды к этому не готовы. Компилируемый 64-битный код не означает работоспособный. Стали всплывать «грехи молодости», например, использование инструкций в предположении о 4-байтном размере адреса. Отсутствие культуры проведения тестов, вкупе с технологической неготовностью в сжатые сроки внедрить данный процесс.
И тут — чем больше проект, измеряемый, допустим, количеством строк исходного кода, тем аккуратней и взвешенней относятся программисты к различного рода нововведениям в диапазоне от внешнего вида «кнопки» в интерфейсе до «синтаксического сахара» в компиляторе.
Одним из таких «проблематичных» достижений явился выход Windows 8. Лично у меня, как пользователя ПК, и просто современного IT-специалиста — Windows 8 вызывает восторг. Но для разработчиков, которым прислали партию компьютеров под Windows 8 с ТЗ на разработку под новую ОС в нагрузку, это означает определенные сложности.
Мы постарались максимально комфортно и безболезненно обеспечить поддержку разработки под новый интерфейс этой ОС. Поэтому и для VCL, и для FireMonkey введены специальные стили, а программист может либо перестроить интерфейс приложения, либо создать заново приложение, которое будет неотличимо от «родного» для Windows 8 по внешнему виду. Конечно, есть потребность в «нативной» поддержке Windows 8 за счёт WinRT. Но здесь сказывается приоретизация целей в современных условиях. Mac OS, iOS, Android в ближайших планах не дают пока возможности говорить о полноценной поддержке WinRT в ближайшем будущем.
Стратегической целью Embarcadero, конечно, является мульти-платформенность. Релиз RAD Studio XE4 явился ключевым, прежде всего из-за поддержки iOS. Действующий программист, использующий VCL, может в считанные часы начать разработку под iOS. Даже простое мобильное приложение может быть мгновенно преобразовано в мощный проект, работающий в рамках сложившейся инфраструктуры. Не надо думать, что это просто новый компилятор к FireMonkey и новый стиль для обеспечения соответствия интерфейсу iOS.
Это и новый визуальный дизайнер, и встроенная поддержка различных форм-факторов, и библиотеки доступа к данным, включая новую FireDAC, и технология LiveBindings для гибкого и динамического связывания с корпоративными данными. Все эти нововведения поступают синхронно — и для Windows, и для Mac OS, и для iOS. Операционная система Mac OS развивается не так стремительно, поэтому таких проблем, как переход Windows 7 — Windows 8 там нет. Но появились дисплеи Retina, и это потребовало отдельного внимания. Сейчас любое MacOS-приложение, созданное в Delphi XE4, автоматически включает в себя два стиля — «обычный» и «высокочёткий».
Т.о. одно и то же приложение может иметь одинаково качественный «нативный» интерфейс на любом настольном компьютере от Apple.
Компания Embarcadero своими новыми инновационными релизами не хочет «удивить», «поразить» или даже «развлечь» разработчиков. Скорее, наоборот, IT-сфера и так уже полна различных сюрпризов: новые устройства, новые платформы, новые пользователи, новые их потребности, новые сценарии взаимодействия. Добавьте сюда ещё и новые технологии разработки ПО, и программистам просто не останется времени на создание новых систем и на существующих — они будут только и делать, что проводить миграцию из одной среды в другую, со старой библиотеки на новую, с одного языка на другой.
Но мы и не исповедуем отказ от всего нового. Мы лишь хотим обеспечить преемственность всего — кода, интерфейса, проекта, даже профессиональных навыков при появлении новых платформ и устройств. Можно сказать, что мы боремся с нездоровым консерватизмом в отношении новых платформ за счёт здорового консерватизма в средствах разработки. Не ждите от Embarcadero экзотических продуктов, нестандартных языков программирования и диковинных средств разработки.
У нас вы всегда найдёте — визуальную разработку, классические языки, «нативный» код, и пусть новыми будут целевые платформы для ваших приложений, созданных всё тем же проверенным классическим способом.
06.03.2013 12:46 пп
Очень я страдал из-за отсутствия компонента-браузера в FireMonkey. Известный проект Delphi Chromium Embedded все-таки включил поддержку FMX в последнем билде. Но не смотря на то, что прошло довольно много времени, поддержку FMX2 автор добавлять не торопится. В итоге пришлось брать ситуацию в свои руки.
Компонент TChromiumFMX из официальной сборки вполне себе работает в FireMonkey (в XE2), но в FMX2 даже не компилируется. Пришлось немного разобраться с тем, как он устроен и исправить. Благо, серьезных изменений не потребовалось.
В FMX2 изменились две нужные компоненту вещи.
Первое — TBitmap больше не имеет свойств ScanLine и StartLine . Прямой доступ к содержимому TBitmap переделали (интересно, зачем?) и теперь оно доступно через класс TBitmapData , который возвращает метод TBitmap.Map .
Ну и второе, более известное — Platform .* больше нет, теперь необходимо получать нужный интерфейс через TPlatformServices.GetPlatformService . Здесь все довольно прямолинейно и проблем нет.
Особо изобретательно я его не тестировал, но для моих целей компонент вполне подходит — сайты через него смотреть можно. Скачать его . Еще, пожалуй, отправлю мои правки автору, может быть сочтет нужным добавить их в официальную версию.
30.07.2012 2:43 дп
Jason Southwell предлагает разработать набор FireMonkey-оберток для нативных контролов Windows/OSX и собирает на это деньги . Планирует для начала собрать 20 тысяч долларов.
Идея ясна. Существующие компоненты FireMonkey отрисовываются средствами Delphi практически с нуля, что с одной стороны во многом и обеспечивает их кроссплатформенность, но с другой — в результате мы получаем компоненты не вполне естественно выглядящие в обеих поддерживаемых на сегодня ОС. И это полбеды — кроме внешнего вида, приходится самостоятельно разрабатывать и логику этих компонентов. Например, RichEdit довольно сложен, самостоятельно повторить его логику в рамках FireMonkey — задача не из тривиальных. И VCL, и CLX не изобретали велосипедов, а пользовались готовым.
А теперь плохая новость. В рантайме все работает, но я не нашел никакого способа добавить свой новый тип вкладки в Items Designer. И похоже, что та же самая проблема есть у всех списковых контролов: TListBox, TGrid и т.п. Сначала мне подход к их реализации очень понравился, а вот теперь даже как-то сомневаюсь. Поиск в интернете показал, что я с этой проблемой не одинок .
Справка молчит, в коде я тоже не нашел ничего. Неужели никак? Это было бы крайне неприятно.
Что же такое FireMonkey?
FireMonkey (FMX) — фреймворк для кроссплатформенной разработки как для настольных систем (Windows, Mac OS + в ближайшем будущем планируется поддержка серверной части на Linux), так и мобильных (iOS и Android) с использованием языка Delphi/C++.
Особенности:
единая кодовая база для всех платформ;
любой контролл (визуальный компонент) может быть контейнером (родителем) для других компонентов;
наличие очень продвинутого относительного расположения (20 типов) компонентов на форме;
LiveBinding позволяет подключать любые типы данных или информации к любому пользовательскому интерфейсу или графическим объектам;
наличие стилей формы/компонентов;
Multi-Device Preview позволяет настроить визуальное представление для каждой из платформ;
FireUI Live Preview -— отображение вида приложения на реальных устройствах в режиме реального времени.
Возможности:
использование нативного API каждой из платформ, также возможность вызов сторонних родных библиотек;
взаимодействие со всеми датчиками (GPS, Accelerometer, Compass, Bluetooth (включая LE) и другие);
поддержка push уведомлений, IoT;
поддержка асинхронных HTTP запросов;
поддержка большинства баз данных (MsSQL, MySql, Oracle, PostgreSQL, MongoDB и др.);
работа с Cloud Service (Amazon, Azure);
поддержка Android Service.
Минусы (на текущий момент):
отсутствие поддержки кастомизации нативных классов;
реализация специфических вещей либо невозможна (виджеты, расширения (iOS) и др) либо необходима пляска с бубном (background service, broadcast message и др);
кастомизация Splash screen (начальный экран) мягко говоря никакая;
FMX контролы используют собственный рендеринг (визуализация, отрисовка), который чисто визуально похож на нативный;
использование нативных контроллов связано с большими телодвижениями;
при большой вложенности компонентов происходят невероятные вещи: приложение крашится в самых различных местах, теряется фокус, зависает и др.;
информативность отладки приложения на мобильных платформах нулевая;
описание ошибок на мобильных платформах сводятся к бесполезным “Error 0х00000Х”;
время компиляции желает быть лучшим для средних и крупных проектов;
необходимость использование напильника для доведения до ума мобильных приложений для каждой платформы;
отсутствует поддержка Intel Atom архитектуры;
неадекватная цена по сравнению с конкурентами.
Плюсы:
очень активное развитие в последнее время как продукта, так и сообщества, поддержка все новых и новых технологий;
наличие громадного числа бесплатных и коммерческих компонентов;
скорость работы приложения очень близка к нативному;
очень продвинутый визуальный редактор и среда в целом, наличие стилей;
возможность тестировать приложение на Win, и лишь потом разворачивать на устройствах, что очень ускоряет разработку;
смена режима/платформы легким движением руки;
PAServer обеспечивает легкое взаимодействие с MacOs при разработке для ОС Apple;
поддержка 3D графики из коробки.
В заключение хочу сказать, что FireMonkey за последние пару лет вырос в профессиональный инструмент кроссплатформенной разработки бизнес приложений и не только. Многие недостатки постепенно решаются и с каждым релизом продукт становиться все более современным и самодостаточным, также исчезает существующий скептизм к самому языку Delphi, связанный с многолетним застоем. Написание новых проектов на FireMonkey является “безопасным” и перспективным.
Прошло уже достаточно времени с тех пор, как термин FireMonkey стал более менее знаком, если, и не для всех разработчиков, то хотя бы тех, кто использует Delphi. За это время появились книги по FireMonkey, статьи по FireMonkey, записи про FireMonkey в многочисленных блогах. Читать все это очень интересно. Но ведь никакая теория не заменит практику. И у меня, как и у многих ранее, появился зуд попробовать что-нибудь написать с использованием FireMonkey.
При этом, однако, возникла проблема. Я, почему-то, решил, что надо просто реализовать какой-нибудь не очень сложный рабочий проект.
Чтобы объяснить,почему это оказалось для меня проблемой, потребуется некоторое (так и хочется написать, лирическое) отступление. Экскурс в мое прошлое, как разработчика. Пояснить некоторые сформировавшиеся у меня взгляды на программирование с использованием Delphi.
Надо сказать, что использовать Delphi я начал еще на Windows 3.1, то есть, с первой версии. И с тех самых пор я изучал VCL. Изучал в оригинале, так сказать. Смотрел, обращался, трассировал исходники. Снова и снова.
Известно, что в разное время в набор компонентов, поставляемых с Delphi, входили компоненты сторонних разработчиков, которые должны были заполнить пробелы в VCL, и которые, наверное, проходили некий контроль качества перед включением. Некоторые из таких компонентов продолжают поставляться и сейчас. Взять тот же Indy. Никого не хочу обидеть, это сугубо мое личное мнение, которое относится и ко мне самому, как разработчику компонентов: ни один набор не был так глубоко продуман и так качественно реализован, как громадный и разнообразный VCL. Нет, я не претендую на истину в конечной инстанции, и, конечно же, в самом VCL множество ошибок, решений, которые вызывают непонимание, вызывают неприятие и с которыми хочется не соглашаться. Но у меня всегда складывалось впечатление некого единого стиля. Есть в VCL, на мой взгляд, красивый и прочный стержень, который поддерживает всю конструкцию Delphi, и вокруг которого строится и программная инфраструктура, и само сообщество разработчиков. Именно благодаря во многом VCL, опять же, на мой взгляд, слухи о смерти Delphi до сих пор остаются слухами. И когда а поставку VCL включались компоненты сторонних разработчиков, это стразу было заметно, они отличались.
Но вот приходит момент, и я слышу, что VCL - это технология, которая устарела. Технология, которую надо оставить в прошлом. Разработчикам следует все свои новые проекты реализовывать на FireMonkey, а про старые... неплохо бы и их перевести на новые рельсы. FireMonkey везде и всегда. И слышу я это из разных источников. Причем довольно настойчиво. Нет, никто VCL не убивает. он остается с нами. Но он теперь не номер один. Он должен стать дублером. По крайней мере так я понимаю то, что говорится о будущем продукта.
В принципе, я понимаю такой расклад. Взят курс на многоплатформенность, и, что важнее, на кроссплатформенность. Ведь что такое VCL? Visual Component Library. Библиотека визуальных компонентов. С этим можно не соглашаться. Я, например, всегда считал множество невизуальных компонентов, да и не компонентов, а просто классов, неотъемлемой частью VCL, а огромное количество сторонних классов и компонентов - продолжением, расширением VCL. Ну не получается у меня считать наследников TDataset-а не частью VCL. Хотя, например, термин DBExpress Library говорит о том, что это, как бы, не VCL. Видимо, Embarcadero действительно разделяет монолитную, с моей точки зрения, VCL, на некоторое количество отдельных библиотек. Нет, конечно, не совсем отдельных, но, тем не менее. И если принять такую точку зрения, FireMonkey призван заменить именно визуальную часть VCL (как же я все-таки должен называть полную библиотеку классов и компонентов, может, Borland Component Library?).
Вокруг чего построены визуальные компоненты, входящие в библиотеку? Вокруг низкоуровневых, базовых элементов, предоставляемых операционной системой. Дескрипторы окон, шрифты, сами окна, элементы ввода, сообщения, контексты устройств и многое многое другое - это есть не понятия библиотеки, поставляемой с Delphi, а понятия операционной системы. Да, именно, Windows. И если вы хотите построить кроссплатформенную библиотеку, то логично отказаться от той инфраструктуры, которую предлагает операционная система, исполняющая написанную с использованием библиотеки программу.
Именно это и пытаются сделать при помощи FireMonkey. Пытаются создать инфраструктуру, основанную на базовых механизмах, поддерживаемых в различных операционных системах, способную заменить тот сервис, который предлагают сами операционные системы.
Многие помнят попытку сделать кроссплатформенной не только библиотеку, но и сам Delphi . Параллельно Delphi 6 вышел продукт Kylix и библиотека CLX. Все это было сделано для того, чтобы можно было разрабатывать для Linux. Однако, нет у Linux многих базовых понятий в плане графического оконного интерфейса, какие есть у Windows. Оконный интерфейс для Linux вообще явление не родное. Это необязательное приложение. И пришлось писать какую-то синтетическую библиотеку. С ее помощью можно было писать программу и для Windows, и для Linux. Однако, я до сих пор помню то чувство не разочарования, нет, скорее, раздражающего неудобства, которое испытал, когда попробовал воспользоваться аналогами визуальных компонентов из CLX. Мне стало много чего не хватать. То, что я привык делать не задумываясь при разработке с использованием VCL, оказалось сделать трудно, совсем по другому, или просто невозможно, с использованием CLX.
Приблизительно также я чувствовал себя и при переходе с BDE на DBExpress. Старый, знакомый еще с Field Test-а BDE (Borland тогда уже использовал его в Quattro Pro for Windows и в Paradox for Windows, и носил он название ODAPI, а затем IDAPI, и был на голову выше, на мой взгляд, майкрософтовского ODBC) был объявлен устаревшей технологией, которая должна уступить место в новых проектах новой библиотеке. Мне все время чего-то не хватало в DBExpress в первое время, особенно знаний.
При этом я ни в коем случае не хочу ругать или критиковать ни сами перечисленные выше библиотеки, ни решения, которые привели к их появлению. Речь идет лишь о моих впечатлениях, иногда,первых впечатлениях.
Теперь, наверное, становится немного понятней, почему решение написать с использованием FireMonkey небольшой рабочий проект, принесло некоторое количество проблем. В течении многих лет при разработке проектиков, проектов и проектищ складывается определенный стереотип, некий шаблон того, что и как надо делать. И в моем случае пришлось столкнуться с тем, что шаблон надо менять. Потому, что нельзя перенести все то, к чему привык, используя VCL, в проект, строящийся на FireMonkey.
При старте проекта я испытал некоторое чувство дежавю. А именно, чувство неудобства. Например, нет многих свойств у привычных элементов ввода. Приемчики, которые прочно вошли в практику, основанные на трюках, связанных со знанием каких-то особенностей операционной системы, не проходят в новом контексте. Не говоря уже о том, что некоторые компоненты изменились радикально.
Ну и еще важный нюанс. Какие обычно проекты приходится делать на работе, если она (работа) не связана с написанием компиляторов, систем моделирования или еще чем-нибудь высоконаучным? Я думаю, что для большинства это разработка чего-либо, связанного с использованием баз данных. Причем что-то высоконаучное тоже может пользоваться сервисами, предоставляемыми СУБД.
Вот тут меня ожидала еще одна засада. Почему-то, когда сталкиваешься на практике с тем, что FireMonkey не содержит элементов, ориентированных на работу с данными, хранящимся в БД, оказываешься к этому не совсем готов (мягко говоря). Хотя и читал уже об этом много раз и знаешь (теоретически), чем следует воспользоваться. Речь про Live Bindings.
Я не хочу ввязываться в спор про то, должны ли настоящие крутые программисты использовать db-aware компоненты, или не должны.На практике, начиная новый проект, я оказался перед фактом: надо привыкать и к новым визуальным компонентам и к новому способу извлечения данных для отображения, редактирования и, в конечном счете, сохранения. Что, опять же, не плохо, и не хорошо. Просто для меня получилось именно так.
На этом хочу завершить пост про первые впечатления. На очереди рассказы о том, что и как преодолевалось при работе над проектом.