Продолжу тему

Автор: Shmj
Дата: 30.09.17

, но конкретизирую.

При всем многообразии способов реализовать GUI, можно выделить несколько подходов:

1. Императивный подход. Каждый элемент создаете в коде (Button b = new Button()) и в том же коде устанавливаете свойства. Императивный подход не так так плох, когда есть хороший визуальный редактор и он выполняет за вас всю грязную работу (однако написание такого редактора -- задача не тривиальная).

2. Декларативный подход + лапша-код. Этот в старом стиле писали jsx, asp или php-страницы. Когда GUI задается декларативно, т.е. вы пишите все <div> <img>, но динамика осуществляется с помощью подмешивания в html спец. тегов (абстрагируемся от технологий, теги могут быть и клиентские <script>).

3. Разделение декларативного GUI и кода. В ASP.Net это не плохо сделали, старые aspx-страницы.

Элементы пишем декларативно с помощью HTML/XAML/etc. Чтобы манипулировать элементом, ты ему задаешь ID. И уже из кода по событию манипулируешь.

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

Я бы не сказал что подход такой уж плохой. Основной минус -- сложно тестировать код.

4. MVP. Чтобы подход 3 можно было тестировать, придумали MVP. Добавляем посредника, который управляет и формой (представлением) и View. Фишка в том, что мы сможем подменить форму на тестоый оъект, поскольку в форме ничего сложного не содерижится (форма не знает о методах презентера и данных View). Это все решает вопрос тестирования.

5. MVC. Типа альтернатива MVP для Web-а без JS, где нет событий (презентер то требует событий от View, а их нет в клиент-серверном старом взаимодействии (без WebSocket)).

В теории можно даже подменить одну View на другую, сделанную совсем по другой технологии (типа использовать вместо Web -- нейтивное приложение). Ведь код контроллера не знает кто и как его долбанную модельку будет отображать.

Популярна для Web-а, так как подходит под идеологию -- 1 запрос 1 ответ (1 объект модели отправили, новый объект модели приняли). Когда обмен данными двунаправленный, выходит на сцену MVVM.

6. MVVM. Фишка в двунаправленном байндинге. Т.е. есть некая модель и то что ты установишь в коде для этой модели -- отобразится в GUI. Но в отличии от MVC, можно еще и изменить свойство в модели и это отобразится в GUI.

Это удобнее и понятнее MVC, но не везде реализуемо (для браузера можно сделать только на стороне JS).

Ничего не забыл? Какой подход, по вашему, наиболее удобный?

Здравствуйте, Shmj, Вы писали:

S>Продолжу тему

Автор: Shmj
Дата: 30.09.17

, но конкретизирую.

S>Ничего не забыл? Какой подход, по вашему, наиболее удобный?

По мне MVVM — самый удобный.

Здравствуйте, Shmj, Вы писали:

S>Ничего не забыл? Какой подход, по вашему, наиболее удобный?

Когда каждый элемент гуя описывается двумя атрибутами:
1. тип поля;
2. дополнительные условия к типу (например, количество символов в string).

Форм нет, а есть классы, состоящие из набора элементов, описанных выше.
Класс отображается пользователю автоматически.
Управление объектами, созданными из таких классов, выполняется командами.
Программист — создаёт такие команды и/или связывает несколько команд в одну новую.
Соответственно, чтобы работать с таким гуем, нужно менять своё мышление.
Аналогов нет.
Создать реально.

Здравствуйте, Real 3L0, Вы писали:

R3>Аналогов нет.
R3>Создать реально.

Давайте все-таки обсуждать реальность, а не свои фантазии. Вот как сделаете -- так и говорите.

Здравствуйте, Shmj, Вы писали:

S>Давайте все-таки обсуждать реальность, а не свои фантазии. Вот как сделаете -- так и говорите.

Ты спрашивал про самый удобный подход — я ответил. Всё описанное тобой — не удобно.
У меня не фантазии — прототип я реализовал. И он работал. Но потом стал переписывать и распилил его.

Здравствуйте, Real 3L0, Вы писали:

R3>Когда каждый элемент гуя описывается двумя атрибутами:
R3>1. тип поля;
R3>2. дополнительные условия к типу (например, количество символов в string).

R3> ...
R3>Управление объектами, созданными из таких классов, выполняется командами.
R3>Программист — создаёт такие команды и/или связывает несколько команд в одну новую.
R3> ...

Чем этот подход отличается от MV* вариантов?

Здравствуйте, amironov79, Вы писали:

A>Чем этот подход отличается от MV* вариантов?

Да, наверное, ты прав: связка "визуального контрола" и свойства объекта — наверное ничем.
Фишка в том, что кроме связки — больше ничего нет. Не в смысле, не реализовано, а в смысле, что не нужно. Ну, это долго рассказывать.

Здравствуйте, Real 3L0, Вы писали:

R3>Здравствуйте, amironov79, Вы писали:

A>>Чем этот подход отличается от MV* вариантов?

R3>Да, наверное, ты прав: связка "визуального контрола" и свойства объекта — наверное ничем.
R3>Фишка в том, что кроме связки — больше ничего нет. Не в смысле, не реализовано, а в смысле, что не нужно. Ну, это долго рассказывать.

Я бы послушал. А пока я понимаю, что данный способ предлагает встроенный валидатор и генератор форм. И удобно это будет (если еще будет) только в самых простых случаях. Для примера посмотри DevExpress XAF: простое приложение на основе модели данных можно сделать за пару кликов, но настроить его под свои требования -- задача сопоставимая с написанием нового приложения.

Здравствуйте, amironov79, Вы писали:

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

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

A> Для примера посмотри DevExpress XAF: простое приложение на основе модели данных можно сделать за пару кликов, но настроить его под свои требования -- задача сопоставимая с написанием нового приложения.

Это всё — всем известные "формочки". У меня же полностью изменение подхода к графическому интерфейсу. До сих пор ещё осталось много вопросов к реализации. Хотя с другой стороны — много вопросов и решено.
О! У меня, оказывается, сохранилось некоторое описание: http://obcom.ws/info.aspx

Здравствуйте, Real 3L0, Вы писали:

R3>Это всё — всем известные "формочки". У меня же полностью изменение подхода к графическому интерфейсу. До сих пор ещё осталось много вопросов к реализации. Хотя с другой стороны — много вопросов и решено.
R3>О! У меня, оказывается, сохранилось некоторое описание: http://obcom.ws/info.aspx

Так и не понял, в чем оригинальность идеи. По описанию — будет очередной application framework.

Здравствуйте, amironov79, Вы писали:

A>Так и не понял, в чем оригинальность идеи. По описанию — будет очередной application framework.

Так дай мне ссылку на реализацию?

Здравствуйте, Real 3L0, Вы писали:

R3>Здравствуйте, amironov79, Вы писали:

A>>Так и не понял, в чем оригинальность идеи. По описанию — будет очередной application framework.

R3>Так дай мне ссылку на реализацию?

Пожалуйста: для .net — https://www.devexpress.com/products/net/application_framework/, для java — https://www.cuba-platform.ru/.

Так в чем оригинальность твоей идеи относительно этих продуктов?

Здравствуйте, amironov79, Вы писали:

A>Пожалуйста: для .net — https://www.devexpress.com/products/net/application_framework/, для java — https://www.cuba-platform.ru/.
A>Так в чем оригинальность твоей идеи относительно этих продуктов?

Повторяю — это всё "формочки".
Например, вот закодил ты на этом фреймворке такую формочку:

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

В случае приведённого фреймворка, надо добавлять или кнопочки, или новую формочку + копипастить код или делать связь с библиотекой графического редактора (в последнем случае, это потребует разбираться в коде, если библиотеку делал не ты).

В моём случае надо... ни делать ничего.

Здравствуйте, Real 3L0, Вы писали:

A>>Так в чем оригинальность твоей идеи относительно этих продуктов?
R3>Повторяю — это всё "формочки".

Что значит "формочки"? Пользовательский интерфейс все-равно в конечном итоге представлен в виде форм, и в XAF они большей частью создаются автоматически:

XAF way: an elegant user interface is generated automatically . XAF UI is inspired by Microsoft Office and offers CRUD detail and list forms with built-in navigation – all based on data models.

Написав класс Employee, мы автоматически получим форму сотрудника.

public class Employee { [Size(255)] public string FullName { get; set; } public DateTime? BirthDate { get; set; } public Image Photo { get; set; } ... public IList<Task> Tasks { get; } public IList<ChangeHistoryItem> ChangeHistory { get; } public IList<Phone> Phones { get; } }

R3>Например, вот закодил ты на этом фреймворке такую формочку:
R3>Image: Automatic_Data_Representation.png
R3>В другом месте ты закодил простенький графический редактор с функцией поворота картинки.
R3>Что надо сделать, чтобы на формочке выше появилась возможность поворота картинки? (Кстати, это реальное требование.)

Реализовать адаптер для контрола редактора и привязать его к полю.

R3>В случае приведённого фреймворка, надо добавлять или кнопочки, или новую формочку + копипастить код или делать связь с библиотекой графического редактора (в последнем случае, это потребует разбираться в коде, если библиотеку делал не ты).
R3>В моём случае надо... ни делать ничего.

Это фантастика! (c)

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

Здравствуйте, amironov79, Вы писали:

A>Что значит "формочки"? Пользовательский интерфейс все-равно в конечном итоге представлен в виде форм,

Пользовательский интерфейс Siri не представлен в виде формочек.
Графический пользовательский интерфейс может отличаться между собой, сохраняя все нужные функции. "Формочками" я называю текущий интерфейс, реализованный во всех известных десктопных OS. Но заметь, как интерфейс десктопных OS отличается от мобильных OS. Потому что требования другие.
Вот и я поставил другие требования и получил другой подход к интерфейсу. (Не говорю, что он лучше.)

A> и в XAF они большей частью создаются автоматически:

Ну круто, если так.

A>Так расскажи, что надо сделать, чтобы потом не делать ничего.

Это долго. И мне лень. И есть ещё вопросы, которые решаемые. Но мне лень. И даже если это будет очень круто — все занятые люди и им некогда.
Я как-то тут уже предлагал поучаствовать в этом проекте. Трое изъявили желание. Один из них, вроде, даже был админом рсдн. Все тихо слились.

A> Как твоя система узнает, что есть новый контрол редактора, как его использовать и что с его помощью надо отображать вот это конкретное поле?

Попробую объяснить, натянув на реальнее вещи.
Допустим, есть WinForms в .NET Framework.
Допустим, в WinForms появился контрол ListBox.

Ты закодил приложение с этим контролом, в котором как-то появляются элементы.
В следующей версии .NET Framework/WinForms контролу ListBox добавили возможность удалять элементы через контекстное меню.

(первая картинка, что нашёл )

Опустим установку этой следующей версии .NET Framework/WinForms и повторную перекомпиляцию приложения.
Теперь, если пользователь не хочет использовать это контекстное меню — не использует. Хочет — есть возможность.

Отвечая на твой вопрос: что-то типа единой базы контролов, где любой разработчик может добавить как свой контрол, так и новую функцию к существующему. Короче, тут ещё копать надо. Поэтому не на все твои возможные вопросы я буду отвечать.

Здравствуйте, Real 3L0, Вы писали:

R3>Это долго. И мне лень. И есть ещё вопросы, которые решаемые. Но мне лень. И даже если это будет очень круто — все занятые люди и им некогда.
R3>Я как-то тут уже предлагал поучаствовать в этом проекте. Трое изъявили желание. Один из них, вроде, даже был админом рсдн. Все тихо слились.

Почему-то не удивлен. Пожалуй, тоже сольюсь.

Здравствуйте, Shmj, Вы писали:

S>Ничего не забыл?
Еще бывает immediate mode gui. Код примерно такой:

function update() {
    var username = textbox("user");
    var password = textbox("password");
    if(button("login")) {
        login(username, password);
    }
}

S>Какой подход, по вашему, наиболее удобный?
Очевидно от задач зависит.

Здравствуйте, Real 3L0, Вы писали:

R3>Когда каждый элемент гуя описывается двумя атрибутами:
R3>1. тип поля;

<input type="text">

R3>2. дополнительные условия к типу (например, количество символов в string).

<input type="text" maxlength=100>

Это?

Здравствуйте, c-smile, Вы писали:

CS>Это?

Наверно, можно и так. Но я реализовал создание UI мышкой.
А что на счёт остального?

Здравствуйте, Real 3L0, Вы писали:

R3>Наверно, можно и так. Но я реализовал создание UI мышкой.

Извини, не удержался, но "создание UI мышкой" — это не "не делать ничего".

R3>А что на счёт остального?

Чего остального?