WPF Handler (Open source): Введение / forpes.ru

Главная
WPF Handler (Open source): Введение

WPF Handler (Open source): Введение

27.01.2020 06:41

Cripos 21 1500 Источник

Введение

В данной части я постараюсь структурировать имеющуюся информацию о WPFH фреймворке в небольшую статью, так-как оригинальная Wiki достаточно объемна и может запутать.

Так же в этой статье мы подключим фреймворк к нашему проекту и запустим один из стандартных примеров.

В дальнейших частях серии мы рассмотрим создание простого приложения построенного на WPFH.

Что такое WPFH и кому нужен?

WPF Handler (WPFH) это фреймворк с открытым кодом, который существенно упрощает разработку приложений с использованием WPF покрывая большое количество базовых задач и автоматизируя часть процесса разработки.

Ключевые особенности

Авто-сборка UI — фреймворк позволяет автоматизировать сборку панелей интерфейса, что существенно ускоряет разработку, а также стандартизирует интерфейс.
Встроенная система локализации — фреймворк предоставляет решение по локализации позволяя заменять контент приложения на лету. В качестве плюса можно выделить то, что содержимое хранится в простом словаре, что позволит пользоваться услугами по переводу от людей не имеющего образования и опыта в компьютерных науках.
Простая работа с пользовательскими плагинами — фреймворк предлагает простой способ масштабировать приложение пользовательскими плагинами, а так же имеет базовые элементы интерфейса для управления ими через приложение.
Коллекция элементов интерфейса — фреймворк содержит в себе набор новых элементов интерфейса соответствующий современным стандартам UI.

Как начать?

Первым делом необходимо загрузить фреймворк. Для этого заходим на GitHub в раздел Releases и скачиваем последнюю доступную версию.

Распакуйте архив любую удобную для вас директорию. Фреймворк не требует установки.

Теперь остается только подключить WPFHandler.csproj в качестве ссылки для проекта. Файл находиться в директории WPFH_FOLDER/WpfHandler/.

Где найти примеры?

Набор примеров доступен сразу же после распаковки архива.
Запустите WpfHandler.sln и откройте папку Examples в вашей IDE.

Здесь вы увидите несколько вложенных папок с проектами. Рассмотрим содержимое каждой из них.

Auto layout — в этой папке находятся пример в котором элементы интерфейса собираются в панель с использованием дескриптора и его атрибутов разметки.
Controls using — тут находится ряд примеров демонстрирующих варианты работы с новыми элементами интерфейса.
Localization — как понятно из названия в этой папке лежит пример использования системы локализации.
Plugins — данный каталог хранит в себе 3 проекта. Один из них, «MainPluginBasedApp» является основным приложением, два оставшихся это плагины которые будут им запускаться.

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

Полезные ссылки

Оригинальные обучающие материалы

Обзор новых элементов управления (англ.)
Преимущества автоматической сборки интерфейса (англ.)
Работа с UIDescriptor (англ.)
Локализация интерфейса (англ.)

Документация

Wiki — здесь вы можете найти туториалы и подробное объяснение работы каждого модуля и фичи фреймворка.
Online documentation — сгенерированная документация позволяющая найти описание того или иного элемента фреймворка.

Заключение

На этом обзорная статья заканчивается. Спасибо, что нашли время ее прочесть!

В дальнейшем это статья будет обновляться актуальной информацией, а так же ссылками на продолжении серии статей посвященных разработке приложений с использованием WPFH.

Комментарии (21)

AgentFire
27.01.2020 10:41
#21192304
В чем прекол-то? Что он делает то, конерктно?
1. Cripos Автор
  27.01.2020 11:09
  #21192442
  1. Закрывает часть задач которые так и так придется делать для нормального приложения. Вроде локализации, разработки анимаций, красивых эффектов. Все это сведено обычно к вызову 1 строки кода.
  2. Может самостоятельно верстать панели управления из исходного кода. (Хорошей аналогией будет Unity, когда вы не прописываете кастомный редактор для компонента). Это существенно ускоряет разработку типовых форм.
  3. Реализует новые элементы интерфейса.
  
  Честно не знаю как ответить еще конкретнее. Он про позволяет сэкономить очень много времени на рутинных задачах + предоставляет весь свой функционал через максимально простой API.
  
  Думаю для того, чтобы разрабатывать приложения с ним, можно обладать минимальным опытом.
  1. byme
    27.01.2020 11:58
    #21192740
    
    Локализация в WPF есть из коробки, как и анимации… не понятно чем это решение лучше.
    
    Оно автоматом генерит формы из классов?
    
    Например какие?
    
    Cripos Автор
    27.01.2020 14:17
    #21193562
    Я понял проблему статьи. Думаю будет лучше если я доработаю непосредственно ее, чем вкину все ответы в комментарии. Я в течении пары дней ее доработаю со сравнениями и более подробными объяснениями.
    
    Спасибо, за фидбэк.

byme
27.01.2020 11:48
#21192670
А зачем качать все это из github-a, если есть nuget?
1. Cripos Автор
  27.01.2020 15:20
  #21193902
  Хороший вопрос! Но ответа у меня на его нет… будем исправлять)

ArtZilla
27.01.2020 11:48
#21192674
А есть причины, почему это не выполнено в виде NuGet пакета? Это очень удобно, попробуйте, может понравится =)
1. Cripos Автор
  27.01.2020 15:25
  #21193938
  Спасибо за совет) Уже работаю в этом направлении. Только с необходимостью сделать мелкие фиксы, доработать статью и ответить на вопросы не могу сказать, что оно вот вот окажется на гитхабе.

byme
27.01.2020 11:51
#21192690
Можно было бы больше рассказать о его фичах. Например, что такое auto-layout и какие проблемы он решает лучше в сравнении с стоковым wpf.
1. Cripos Автор
  27.01.2020 11:56
  #21192728
  В целом это есть на Wiki: Статья
  
  Но я согласен, что это ключевая информация и было бы не плохо ее перевести и опубликовать тут для наглядности (возможно дополнить эту статью). Думаю я сделаю это в ближайшее время.
  1. Deosis
    27.01.2020 13:02
    #21193094
    Я посмотрел примеры, и хотел бы задать несколько вопросов:
    
    Локализация. В примере вручную (code-behind) задается локализация для текстового поля. Это надо делать вручную для каждого текстового поля?
    
    auto-layout. Как задать атрибутами 2 разных представления? с сортировкой полей по алфавиту, либо расположить связанные свойства рядом?
    
    Как это взаимодействует? Как написать простейший редактор для высоты и ширины прямоугольника так, чтобы можно было локализовать метки свойств и отобразить их в алфавитном порядке?
    
    Cripos Автор
    27.01.2020 15:18
    #21193886
    1. Если Вы создаете поля НЕ используя UIDecriptor, то на текущий момент, Вам необходимо проделывать эту операции вручную так, как показано в примере, поскольку именно так происходит связь а on-fly системой локализации на текущий момент.
    
    Тем не менее главная идея фреймворка это работа через дескрипторы, чтобы минимизировать работу с версткой. Они же позволяют сделать это гораздо проще, просто через добавление к члену класса атрибута Content.
    
    Если у Вас есть предложения как это должно быть сделано, чтобы это было еще проще, то было бы не плохо услышать предложения.
    
    2. При работе с auto-layout Вы указываете через XAML к какой панеле будет принадлежать интерфейс созданный дескриптором. Это происходит путем добавление AutoLayoutVeiw элемента в качестве содержимого панели (аналогично любому другому контролу в WPF). После этого из code behind Вы определяете какой дескриптор будет подключен к этому AutoLayoutVeiw. Ничего не мешает вам добавить несколько таких объектов.
    
    На текущий момент сортировка полей через дескриптор не представляется возможным. Порядок задается либо автоматически основываясь на метадате сборки, либо же с использованием атрибута Order.
    
    Идея дескриптора в том, чтобы собирать законченные панели. Задача с сортировкой больше свойственна коллекциям, а дескриптор это не коллекция по своей сути. Возможно позже, при наличии интереса к фреймворку, это будет как то изменено, но пока что это так.
    
    На текущий момент я могу предложить использовать — AutoCollection. Она может достаточно много и это ее прямое назначение.
    
    3. Это превосходный вопрос. Думаю немного позже я добавлю ответ на него в качестве примера в статью.
    
    Deosis
    28.01.2020 07:54
    #21196470
    Для сравнения компонент от telerik. Он позволяет автоматически сгенерировать форму для редактирования объекта и при этом позволяет сортировать, группировать, фильтровать поля. Также можно редактировать коллекции и вложенные объекты.

UnclShura
27.01.2020 11:56
#21192732
И ни одной картинки или примера кода… Что смотреть-то?
1. Cripos Автор
  27.01.2020 14:24
  #21193590
  Спасибо, за фидбэк. Статья будет доработана. В обновленной версии будут добавлены скриншоты и анимации демонстрирующие результат работы.
  
  Примеры с кодом есть как на GitHub, так и с подробными объяснениями на Wiki. Одно дело добавлять сюда какой то полноценный крупный пошаговый туториал, другое дело просто мелкие фрагменты использования той или иной фичи. Последнего в достатке в источниках и честно говоря я не уверен, что это хорошая идея просто заниматься их копипастой.

Sing
27.01.2020 12:03
#21192764
Какая-то неделя отречения от MVVM в WPF.

Сначала я подумал, что это ещё один UI Scaffold. Нет, UI генерируется постоянно из стороннего класса. При этом, например, не поддерживаются коллекции (хорошо бы, автор, в таком случае, иметь список того, что всё-таки поддерживается) — а это и есть самое муторное в вёрстке. Текстбоксы я и сам могу накопипастить. Обработка изменений — вручную, через подписывание на событие в событии OnLoaded… И как мне связаться с текущим состоянием своей модели? Как сделать кнопки в этом классе? И как их связать с данными?

В примере локализации не работает локализация.
Плагины — это не когда мы делаем прямые ссылки на проекты.
Про систему распространения через скачивание исходников уже сказали, это не годится.
1. Cripos Автор
  27.01.2020 14:52
  #21193744
  Безусловно это мой промах, я не достаточно подробно все описал. И я постараюсь это исправить в обновленной версии статьи. Но возможно вы упустили пару моментов.
  
  1. Если вы работаете с интерфейсом, который создан из дескриптора, то вам не нужно самостоятельно заморачиваться за подписки и связи интерфейса с кодом. Вам достаточно 1 раз создать AutoLayoutVeiw в XAML и передать ему сущность дескриптора через code behind. Дескриптор сам создаст интерфейс, сам будет обрабатывать при пользовательском вводе, сам вернет новые данные из интерфейса в объект дискриптора.
  
  Если вам нужно вы можете получить конкретный элемент интерфейса и подписаться на его обновление. Не нужна такая точность, подпишитесь на обновление всего дескриптора. И об обновлении дескриптора знать не нужно? Не подписывайтесь, обработаете объект со всеми значениями из интерфейса тогда, когда сами решите.
  
  2. Дескриптор далеко не просто создает текстбоксы, он умеет работать с коллекциями (AutoCollection), toggles группами (может автоматически создать из enum или же использовать массив значений заданный вручную), самостоятельно обрабатывает значение для разных типов значений, с которыми можно работать через тексбоксы (это ведь не только стринг).
  
  Так же дескриптор умеет создавать группы элементов, которые могут быть свернуты, что позволяет делать лаконичные панели с множеством групп и подгрупп.
  
  3.
  Плаги?н — независимо компилируемый программный модуль, динамически подключаемый к основной программе и предназначенный для расширения и/или использования её возможностей. Плагины обычно выполняются в виде библиотек общего пользования.
  Wikipedia
  
  Именно в таком виде это и реализовано в WPFH. Вы делаете библиотеку, а фреймворк упрощает вашу жизнь в подключении ее содержимого к приложению и стандартизирует этот процесс.
  
  P.S.
  На текущий момент кнопки нельзя создать через дескриптор, но это никак не ограничивается возможностями фреймворка. Просто фреймворк молодой и разрабатывается в одиночку. В случае если фреймворк будет нужен сообществу, то он будет развиваться и такие мелочи, как нехватка пары элементов интерфейса или методов в API закроются быстро.
  В этом деле главный вопрос не «а возможно ли это сделать?», а «есть ли смысл тратить на это время?».
  
  P.P.S.
  Спасибо за репорт о локализации. В примере потерянны сами словари, по этому она и не работает. Это не что то связанное с самим фреймворком, просто не вошли в релиз.
  1. Sing
    27.01.2020 16:34
    #21194328
    1. Если вы работаете с интерфейсом, который создан из дескриптора, то вам не нужно самостоятельно заморачиваться за подписки и связи интерфейса с кодом.
    Для этого есть биндинги. Мне и не было нужно заморачиваться. Но теперь, если свойство меняется, для реакции на это я не могу просто использовать его set — я должен в дескрипторе подписаться на событие.
    сам вернет новые данные из интерфейса в объект дискриптора.
    Только мне не нужны данные из интерфейса в дескрипторе. Дескриптор — он, вроде как, позволяет интерфейс отрисовать. Но он же и занимается обработкой данных. Он нарушает SRP — мне нужно в него лезть и для изменения интерфейса, и для изменения обработки данных.
    
    Не подписывайтесь, обработаете объект со всеми значениями из интерфейса тогда, когда сами решите.
    Я пока вижу только подписки на изменения данных. Как подписываться на события интерфейса? Клик или скролл, например. Как подписываться на кнопки?
    2. Дескриптор далеко не просто создает текстбоксы, он умеет работать с коллекциями (AutoCollection),
    То, что для каждой коллекции нужен свой дескриптор рушит всю концепцию бибилиотеки.
    
    Вы делаете библиотеку, а фреймворк упрощает вашу жизнь в подключении ее содержимого к приложению и стандартизирует этот процесс.
    У вас в примере плагинов — прямые ссылки на проекты с «плагинами». А плагин — это, как и написано в википедии, динамически подключаемый модуль.
    В этом деле главный вопрос не «а возможно ли это сделать?», а «есть ли смысл тратить на это время?».
    Я и клонил к тому, что всё это не нужно. Библиотека не даст такой же гибкости как изначальный язык разметки — более того, она не упрощает вещи, а сильно усложняет. Вместо банальной работы с MVVM, где, при должной сноровке, всё ясно и понятно — здесь подписки на события для каждого поля. Я смотрю на то, как это сделано, и попытки ответить на вопросы о валидации, локализации, оповещении интерфейса об изменениях в модели, а также тестировании — и никаких позитивных эмоций ваше решение не вызывает.
    
    Cripos Автор
    27.01.2020 17:34
    #21194702
    1. Вот только с UIDecriptor вам нее нужно делать биндинги. Вы не тратите на это вообще времени. В просто создали класс с полями и свойствами и на этом все и подключили его к 1 (!) элементу. Остальной за вас сделал фреймворк. Он создает интерфейс, он делает связь. А то что описываете вы это просто ручной труд.
    
    Я не понимаю, что вы имеете в виду под тем, что дескриптор «обрабатывает данные». То как в итоге поступать с данными решаете вы. Дескриптор просто является связью между объектом, который представляет из себя контейнер для информации и интерфейсом. На этом все.
    Часть реализаций IGuiField действительно приводит данные к правильному формату, но это то что и должно быть. Вам ведь надо, чтобы текстовые значения оставались текстом, числовые — числами.
    
    На счет гибкости. Почитайте какие атрибуты могут быть задействованы в дескрипторе. WPFH вообще никак не принуждает вас ни к чему. Захотели — поменяли стиль, захотели — поменяли направление лэйаута, захотели — вообще принудили использовать другой элемент. Вы все можете поменять.
    
    2. Это абсолютно неверное заключение. Это естественно, что многие типы требуют своих собственных элементов интерфейса. Как по вашему какой-нибудь массив или список должен отрисовываться и обрабатываться через текстовое поле? Что вас смущает в наличии элемента интерфейса AutoCollection, который используется для таких мэмберов?
    
    3. В примере прямые ссылки использованы исключительно потому что в ином случае придется включать в билд директорию с библиотека и распространять скомпилированные плагины.
    Если вы уберете ссылки на них и принудительные вызовы, то вы смело можете кинуть дллки плагинов в папку plugins\ главного приложения и получить тот же результат.
    
    4.
    Я и клонил к тому, что всё это не нужно.
    
    С учетом того, как вы поняли логику работы WPFH (дескриптор, плагины, коллекции тому пример), я могу заключить, что вы видите на месте того, что есть, совершенно другой по концепции продукт. И то, что вы видите действительно не нужно.
    Но дело в том, что WPFH работает совсем иначе о того, как вы его себе представили.
    
    Sing
    27.01.2020 18:58
    #21195090
    1. Вот только с UIDecriptor вам не нужно делать биндинги. Вы не тратите на это вообще времени.
    Я их и не делаю. Я указываю поле, которое нужно привязать. То, что вы пишете в
    Остается подключить его к 1 (!) элементу.
    Только потом у вас ещё надо привязываться к его изменениям. Ещё как-то надо будет оповещать интерфейс об изменениях.
    
    Я не понимаю, что вы имеете в виду под тем, что дескриптор «обрабатывает данные».
    Вот вам пример из вашего кода:
    github.com/ElbyFross/wpf-handler/blob/8e4733cfe5a4a6c5d6a01dc18d1efc7ef37138af/Examples/Auto%20layout/ExamplePanelDescriptor/MainWindow.xaml.cs#L109 Изменения в интерфейсе обрабатывает сам дескриптор.
    Дескриптор просто является связью между объектом, который представляет из себя контейнер для информации и интерфейсом. На этом все.
    У вас в примере «контейнер для информации» определяет фон окна. Если связь только между контейнером информации и интерфейсом, то где тут место для манипуляций информацией? Этим должен заниматься — опять же — сам «контейнер информации».
    Вам ведь надо, чтобы текстовые значения оставались текстом
    Не всегда. Я могу хранить в тексте цвет фона элемента.
    Это естественно, что многие типы требуют своих собственных элементов интерфейса.
    Так я и сделаю для каждого свой элемент управления: TextBox, ComboBox и т.д. Какая такая Авто-сборка UI тогда?
    
    Как по вашему какой-нибудь массив или список должен отрисовываться и обрабатываться через текстовое поле? Что вас смущает в наличии элемента интерфейса AutoCollection, который используется для таких мэмберов?
    Мне пожалуйста, автосборку UI. Без дополнительных манипуляций элементами интерфейса, иначе я теряю, где тут авто.
    
    Но дело в том, что WPFH работает совсем иначе о того, как вы его себе представили.
    Соглашусь, сложно что-то представлять, когда описание такое куцее, а примеры не работают.
    
    Сделайте, пожалуйста, рабочий пример приложения: с базой данных, CRUD, простой моделью, содержащей коллекцию и разные типы полей. Пару кнопок для добавления и удаление из коллекции. Хочется посмотреть на слой бизнес-логики, как он с этим должен работать. Локализация, опять-таки и конечно же там будут новые контролы, которые предлагает ваша библиотека. Плюс, конечно, плагины.
    Minimum viable product, в общем. В WPF это займёт полчаса, ну час. В вашем ускорителе работы, наверняка, ещё быстрее. Вот тогда можно будет сделать пост об этом и сразить всех наповал. Особенно мощно будет смотреться, если вы сделаете аналогичный проект, скажем, на Prism, и будет очевидно ваше превосходство.

a-tk
27.01.2020 17:38
#21194716
Да, статью однозначно надо развить или переписать с нуля, а эту спрятать.
Примеры кода, какие проблемы решает (если это проблемы), и т.п.