Связывание форм (GUI) с данными: императивно vs декларативно
От: Shmj Ниоткуда  
Дата: 29.07.19 19:01
Оценка: -1
Почему все верят, что декларативный подход рулит и на порядок упрощает работу?

Вот, давайте на примере. Есть поле на форме, вам нужно установить дату и подсветить, если дата нечетная.

Императивный подход (примерно):

DateTextBox.Text = UIConverter.ConvertToText(businessObject.Date);

if (businessObject.Date.IsOdd)
   DateTextBox.Background = Color.Red;


Декларативный подход типа:

<Window.Resources>
        <local:DateBacklightConverter x:Key="dateBacklightConverter" />
</Window.Resources>

<TextBox Text="{Binding Date}" Background="{Binding Source=Date,Converter={StaticResource dateBacklightConverter}}" />


Теперь давайте какие реальные плюсы у т.н. декларативного? Букв меньше не стало. Совокупная сложность кода не понизилась — все равно в конвертере есть проверка if и выбор цвета. В XML-е писать не удобнее, но даже не в этом суть.

Только вера в то, что декларативно типа круче?

Ну ОК, вы скажите что ковертор можно будет задействовать в другом месте. Но! Что мешает мне вынести:

if (businessObject.Date.IsOdd)
   DateTextBox.Background = Color.Red;


— в отдельный метод и просто его вызывать? Вам для конвертора придется целый класс содавать а мне — только метод.

Подозреваю что начнут приводить преимущества т.н. двустороннего связывания и обработки событий изменения данных. У меня есть что ответить на это, но подожду пока скажут.

Получается, что никакого реального преимущества, кроме хайпа, нет
Отредактировано 29.07.2019 19:13 Shmj . Предыдущая версия . Еще …
Отредактировано 29.07.2019 19:04 Shmj . Предыдущая версия .
Отредактировано 29.07.2019 19:03 Shmj . Предыдущая версия .
Re: Data binding
От: Qbit86 Кипр
Дата: 29.07.19 19:50
Оценка: 1 (1) +2 -1
Здравствуйте, Shmj, Вы писали:

S>Получается, что никакого реального преимущества, кроме хайпа, нет :xz:


Ни так, ни эдак делать не нужно. И декларативное vs. императивное тут ни при чём.

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

Вместо этого:
<Window.Resources>
        <local:DateBacklightConverter x:Key="dateBacklightConverter" />
</Window.Resources>

<TextBox Text="{Binding Date}" Background="{Binding Source=Date,Converter={StaticResource dateBacklightConverter}}" />

останется это:
<TextBox Text="{Binding DateString}" Background="{Binding DateColor}" />
Глаза у меня добрые, но рубашка — смирительная!
Re: Связывание форм (GUI) с данными: императивно vs декларативно
От: Skorodum Россия  
Дата: 30.07.19 11:48
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Почему все верят, что декларативный подход рулит и на порядок упрощает работу?

Часто упрощает. Классический пример: соотношение размеров графических элементов, простые анимации и т.п.
В С++ и Qt есть оба подхода: QML и QWidgets. Многое на QML проще.
Re[2]: Связывание форм (GUI) с данными: императивно vs декларативно
От: Владимир35  
Дата: 31.07.19 10:42
Оценка:
S>>Почему все верят, что декларативный подход рулит и на порядок упрощает работу?
S>В С++ и Qt есть оба подхода: QML и QWidgets. Многое на QML проще.

Действительно, некоторые простые примеры на QML выглядят проще. Но, не совсем понятно, как можно называть QML-подход декларативным. Как там насчет таблиц и деревьев? А деревьев в таблицах, сожержащих таблицы? Не нужно, да?
Re: Связывание форм (GUI) с данными: императивно vs декларативно
От: Владимир35  
Дата: 31.07.19 10:57
Оценка:
S>Почему все верят, что декларативный подход рулит и на порядок упрощает работу?
S>Вот, давайте на примере.

Возьмите пример посложнее. ГУИ для списка, содержащего деревья разных типов, содержащие списки разных типов. Используйте темплейты для данных. Готово.

Что нужно сделать для создания ГУИ императивно? Даже подумать страшно. Определенные императивные технологии, и некоторые причисляющие себя к "декларативным", такого в принципе не поддерживают.

Вот это и есть порядок реального преимущества.
Re[3]: Связывание форм (GUI) с данными: императивно vs декларативно
От: Skorodum Россия  
Дата: 31.07.19 10:58
Оценка:
Здравствуйте, Владимир35, Вы писали:

В>Действительно, некоторые простые примеры на QML выглядят проще. Но, не совсем понятно, как можно называть QML-подход декларативным. Как там насчет таблиц и деревьев? А деревьев в таблицах, сожержащих таблицы? Не нужно, да?

А никто и не говорил, что все задачи можно решить чисто декларативным подходом, в отличии от императивного. Очевидно, что кто-то должен реализовать эту подкапотную магию, для всех случаев это невозможно
Re: Связывание форм (GUI) с данными: императивно vs декларативно
От: Mamut Швеция http://dmitriid.com
Дата: 31.07.19 11:30
Оценка:
S>Теперь давайте какие реальные плюсы у т.н. декларативного? Букв меньше не стало. Совокупная сложность кода не понизилась — все равно в конвертере есть проверка if и выбор цвета. В XML-е писать не удобнее, но даже не в этом суть.

Потому что ты не зе знаешь никаких других подходов, кроме XAML'а, и делаешь далеко идущие выводы. Например, SwiftUI тоже декларативный, сильно короче XAML'а и короче аналогичного декларативного бкода, и наглядно показывает удобство деклартивного кода и прозрачного связывания данных даже на простых примерах, например тут: https://developer.apple.com/tutorials/swiftui/creating-and-combining-views UI просто становится комбинацией вложенных структур, которые можно как угодно менять и вкладывать друг в друга.


dmitriid.comGitHubLinkedIn
Re: Связывание форм (GUI) с данными: императивно vs декларативно
От: MadHuman Россия  
Дата: 31.07.19 14:59
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Теперь давайте какие реальные плюсы у т.н. декларативного? Букв меньше не стало. Совокупная сложность кода не понизилась — все равно в конвертере есть проверка if и выбор цвета. В XML-е писать не удобнее, но даже не в этом суть.


ну например при декларативном биндинге, автоматом работает обновление отображаемого значения при изменении значения проперти в модели.
также например в декларативном биндинге потенциально можно использовать формулу, и подсистема биндинга может её проанализировать, выявить зависимости
от других полей модели и пересчитывать и обновлять отображаемое значение при их изменении.
Re[2]: Связывание форм (GUI) с данными: императивно vs декларативно
От: Shmj Ниоткуда  
Дата: 31.07.19 22:48
Оценка:
Здравствуйте, Владимир35, Вы писали:

В>Что нужно сделать для создания ГУИ императивно? Даже подумать страшно. Определенные императивные технологии, и некоторые причисляющие себя к "декларативным", такого в принципе не поддерживают.


В императивном стиле это будет выглядеть как вложенные друг в друга циклы или рекурсивные функции. Там все интуитивно понятно.

А вот в декларативном — действительно деревья с ветками разных типов со списками представить сложно.
Re[2]: Связывание форм (GUI) с данными: императивно vs декларативно
От: Shmj Ниоткуда  
Дата: 31.07.19 22:52
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Потому что ты не зе знаешь никаких других подходов, кроме XAML'а, и делаешь далеко идущие выводы. Например, SwiftUI тоже декларативный, сильно короче XAML'а и короче аналогичного декларативного бкода, и наглядно показывает удобство деклартивного кода и прозрачного связывания данных даже на простых примерах, например тут: https://developer.apple.com/tutorials/swiftui/creating-and-combining-views UI просто становится комбинацией вложенных структур, которые можно как угодно менять и вкладывать друг в друга.


А как там будет выглядеть установка цвета даты в зависимости от четности, к примеру?
Re[2]: Связывание форм (GUI) с данными: императивно vs декларативно
От: Shmj Ниоткуда  
Дата: 31.07.19 22:59
Оценка:
Здравствуйте, MadHuman, Вы писали:

MH>ну например при декларативном биндинге, автоматом работает обновление отображаемого значения при изменении значения проперти в модели.


А оно не всегда нужно!!! Более того — иногда обновление нужно моментальное (т.е. пользователь еще не успел убрать фокус из элемента ввода) а иногда отложенное. Иногда обновление нужно связанное не с данными а с командой — как то нажатие на кнопку.

MH>также например в декларативном биндинге потенциально можно использовать формулу, и подсистема биндинга может её проанализировать, выявить зависимости

MH>от других полей модели и пересчитывать и обновлять отображаемое значение при их изменении.

А ссылку на пример дадите?
Re[3]: Связывание форм (GUI) с данными: императивно vs декларативно
От: Mamut Швеция http://dmitriid.com
Дата: 01.08.19 08:36
Оценка: +1
M>>Потому что ты не зе знаешь никаких других подходов, кроме XAML'а, и делаешь далеко идущие выводы. Например, SwiftUI тоже декларативный, сильно короче XAML'а и короче аналогичного декларативного бкода, и наглядно показывает удобство деклартивного кода и прозрачного связывания данных даже на простых примерах, например тут: https://developer.apple.com/tutorials/swiftui/creating-and-combining-views UI просто становится комбинацией вложенных структур, которые можно как угодно менять и вкладывать друг в друга.

S>А как там будет выглядеть установка цвета даты в зависимости от четности, к примеру?


Ты бы мог пройти по приведенной мной ссылке и увидеть сам. Но ты этого делать не собираешься, потмоу что твоя единственная задача — создать информационный шум и побольше тем с целью бессмысленных споров.


dmitriid.comGitHubLinkedIn
Re[3]: Связывание форм (GUI) с данными: императивно vs декларативно
От: MadHuman Россия  
Дата: 01.08.19 09:43
Оценка:
Здравствуйте, Shmj, Вы писали:

MH>>ну например при декларативном биндинге, автоматом работает обновление отображаемого значения при изменении значения проперти в модели.


S>А оно не всегда нужно!!! Более того — иногда обновление нужно моментальное (т.е. пользователь еще не успел убрать фокус из элемента ввода) а иногда отложенное. Иногда обновление нужно связанное не с данными а с командой — как то нажатие на кнопку.

если нужно в большинстве случаев, то исключения уже не играют рояль.
к тому же описанные вами варианты, могут быть потенциально реализованы как доп. настройка (проперть) режима декларативного биндинга.

MH>>также например в декларативном биндинге потенциально можно использовать формулу, и подсистема биндинга может её проанализировать, выявить зависимости

MH>>от других полей модели и пересчитывать и обновлять отображаемое значение при их изменении.

S>А ссылку на пример дадите?

такое есть внутри нашего проекта, но используется внутренняя реализация.
в общедоступных сходу не припомню, но смутно припоминаю что в каких-то веб-фрэймворках такое видел.
Re[4]: Связывание форм (GUI) с данными: императивно vs декларативно
От: Shmj Ниоткуда  
Дата: 01.08.19 15:45
Оценка:
Здравствуйте, MadHuman, Вы писали:

MH>если нужно в большинстве случаев, то исключения уже не играют рояль.


А вот в этом и ошибка — кто сказал, что нужно в большинстве случаев?

В большинстве случаев ничего не нужно обновлять на форме для каждого элемента. Есть редкие элементы, для которых нужно обновлять форму — либо после того как убрал фокус либо до.

MH>к тому же описанные вами варианты, могут быть потенциально реализованы как доп. настройка (проперть) режима декларативного биндинга.


Проблема в том, что на практике кода меньше не становится

Вроде бы да, двойное связывание (но и оно не всегда нужно!) позволяет писать в 2 раза меньше кода. Однако из-за индивидуальных особенностей каждой конкретной формы, как правило, проигрываешь в другом.
Re: Связывание форм (GUI) с данными: императивно vs декларативно
От: IT Россия linq2db.com
Дата: 01.08.19 21:32
Оценка: 140 (5) +3
Здравствуйте, Shmj, Вы писали:

S>Теперь давайте какие реальные плюсы у т.н. декларативного? Букв меньше не стало. Совокупная сложность кода не понизилась — все равно в конвертере есть проверка if и выбор цвета. В XML-е писать не удобнее, но даже не в этом суть.


S>Только вера в то, что декларативно типа круче?


Не вера, а знание. Это ты не веришь, а мы точно знаем

У тебя ошибка в том, что ты сравниваешь количество строк, простоту восприятия этого примитивного примера и относительную лёгкость создания такого кода. Так и есть. Всё верно. На простом примере такой код выглядит проще и писать его легче. Да и на более сложном примере будет примерно тоже самое. Вообще, я считаю, что любой нормальный программист должен без проблем сгенерировать строчек сто кода, которые должны даже работать. Почему все так любят всё переписывать? Потому что на чистом листе ещё нет никаких проблем, пиши себе, излагай мысль, одно удовольствие.

Все проблемы начинаются потом. Когда эти удовольствия и мысли нужно изогнуть в другую сторону, выправить под изменившиеся требования, расширить или наоборот урезать, но не всё, а только часть и сбоку ещё чего-нибудь пришпандорить.

Вот в этом случае императивный подход сосёт у декларативного как трофейный пылесос.

Ценность технологий, паттернов и подходов не в том, чтобы можно было быстро наклепать простой пример или демку (как в Code First). Не в том, что этот примитивный пример получился не в 10 строк, а в 9. Это всё не более чем приятный бонус. Ценность всего этого в том, насколько сопровождаемым и управляемым будет твой код на протяжении всего его жизненного цикла. Сможешь ли ты через год в своём или вообще в чужом коде быстро разобраться в хитросплетениях ифов и циклов? Не на твоём примере, а там где количество строк уже давно за тысячи и руку приложило несколько девелоперов. Я сомневаюсь. А в декларативном коде всё это сделать будет на порядок проще. Потому что его было тяжелее создавать, тяжелее проектировать, поначалу даже больше писать. Зато менять его как два пальца об асфальт.
Если нам не помогут, то мы тоже никого не пощадим.
Re[2]: Связывание форм (GUI) с данными: императивно vs декларативно
От: Ночной Смотрящий Россия  
Дата: 07.08.19 18:48
Оценка: 6 (1)
Здравствуйте, Mamut, Вы писали:

M>Потому что ты не зе знаешь никаких других подходов, кроме XAML'а


Да и зэмл, а точнее WPF он знает весьма поверхностно.

M>, и делаешь далеко идущие выводы. Например, SwiftUI тоже декларативный, сильно короче XAML'а и короче аналогичного декларативного бкода, и наглядно показывает удобство деклартивного кода и прозрачного связывания данных даже на простых примерах


Даже тут не к месту. Как раз на простыхьпримерах декларативность рулит. Проблемы наступают со сложными, так как императивный код гибче даже хорошего декларативного, и просто на две головы выше плохого декларативного, коего, увы, намного больше.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[3]: Связывание форм (GUI) с данными: императивно vs декларативно
От: Mamut Швеция http://dmitriid.com
Дата: 08.08.19 07:58
Оценка:
НС>Даже тут не к месту. Как раз на простыхьпримерах декларативность рулит. Проблемы наступают со сложными, так как императивный код гибче даже хорошего декларативного, и просто на две головы выше плохого декларативного, коего, увы, намного больше.

Нужна прагматичность: декларативность, где надо, и императивность, где надо Но где ж найти идеал-то...


dmitriid.comGitHubLinkedIn
Re[4]: Связывание форм (GUI) с данными: императивно vs декларативно
От: Ночной Смотрящий Россия  
Дата: 08.08.19 08:46
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Нужна прагматичность: декларативность, где надо, и императивность, где надо Но где ж найти идеал-то...


Даже небольшая примесь императивности все сильно усложняет. Хороший пример — Blend и редактор WinForms. Последний намного более убог, но при этом очень глючен и мутен. Причина как раз наличие неизбежной императивности.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[5]: Связывание форм (GUI) с данными: императивно vs декларативно
От: Mamut Швеция http://dmitriid.com
Дата: 10.08.19 14:17
Оценка:
M>>Нужна прагматичность: декларативность, где надо, и императивность, где надо Но где ж найти идеал-то...

НС>Даже небольшая примесь императивности все сильно усложняет. Хороший пример — Blend и редактор WinForms. Последний намного более убог, но при этом очень глючен и мутен. Причина как раз наличие неизбежной императивности.


Императивщина все равно бывает нужна. Потому что декларативность бывает многословна и/или неэффективна. Или надо работать с императивным кодом. И т.п. Но ее надо ограничивать. Типа «в условиях X мы можем использовать императивный код».

Например, в туториале, что я привел по ссылке, есть раздел «Use UIKit and SwiftUI Views Together»:


struct MapView: UIViewRepresentable {
    func makeUIView(context: Context) -> MKMapView {
        MKMapView(frame: .zero)
    }

    func updateUIView(_ view: MKMapView, context: Context) {
        let coordinate = CLLocationCoordinate2D(
            latitude: 34.011286, longitude: -116.166868)
        let span = MKCoordinateSpan(latitudeDelta: 2.0, longitudeDelta: 2.0)
        let region = MKCoordinateRegion(center: coordinate, span: span)
        view.setRegion(region, animated: true)
    }
}

struct MapView_Preview: PreviewProvider {
    static var previews: some View {
        MapView()
    }
}


в update/make позволяется императивный код. Но для кода вокруг получившуюся струтуру все равно можно использовать дебкларативно

struct ContentView: View {
    var body: some View {
        VStack {
            MapView()

            VStack(alignment: .leading) {
                Text("Turtle Rock")
                HStack(alignment: .top) {
                    Text("Joshua Tree National Park")
                    Spacer()
                    Text("California")
                }
            }
        }
    }
}

struct ContentView_Preview: PreviewProvider {
    static var previews: some View {
        ContentView()
    }
}


Вот что-то в таком стиле, имхо, — правильный подход.


dmitriid.comGitHubLinkedIn
Re: MS делают видео вместо статей - где разум?
От: Kolesiki  
Дата: 25.09.20 15:36
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Почему все верят, что декларативный подход рулит и на порядок упрощает работу?


Потому что суть не в противопоставлении себя "императивщине", а в том, что декларативный подход суть DSL. А это значит, что в твоём "языке ГУЁв" только самые нужные элементы и они заточены на свою задачу, позволяя наиболее мощно описывать решение.

S>Декларативный подход типа:


S>
S><Window.Resources>
S>        <local:DateBacklightConverter x:Key="dateBacklightConverter" />
S></Window.Resources>

S><TextBox Text="{Binding Date}" Background="{Binding Source=Date,Converter={StaticResource dateBacklightConverter}}" />
S>


К сожалению, именно этот пример на ублюдочно спроектированном WPF — плохой. Вот такой лучше:

<TextBox Text={Date} BG=[Date2Color(OddDays)] FG="red" />


Здесь {} — сокращение для Binding, [] — вызвать функцию из кода, "" — задать значение напрямую.
Ну чем тебе не идеал?
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.