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

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

S>>>>Во во оно и видно. Ты все еще мыслишь категориями 2000 и контролами.
V>>>Ну ты же не знаешь, как я HTML-текст генерил, верно?
S>> то что генерится на сервере это уже 2000

V>Зачем на сервере? Нейтивная приложуха генерит генерит HTML-текст по данным.

Мы говорим про браузер.

V>Да, с отделением шаблонов представлений от данных не возился, да это было и не нужно для почти одноразовых задач.
V>Во-первых, приличная часть такого разделения выполняется на стороне CSS, т.е. темы уже переключать можно.
V>Во-вторых, в рантайм такое отделение не требуется вообще никогда.
V>Т.е., на этапе проектирования потусовать туда-сюда шаблоны — это ОК, это понятно.
V>Но в момент билда из шаблона представления должен собираться максимально приближённый к конечному вариант.

Еще раз. Angular 2 генерит Dom, а не HTML, который еще нужно распарсить и построить DOM
V>Это я критикую философию WPF, где в динамике выполняется много таких действий, которые одни и те же при каждом запуске, т.е. могли быть выполнены в момент билда приложения. Т.е. это жуткий бред вообще в WPF происходит, когда тащат шаблоны в ресурсы. При правильном подходе положено из шаблонов представлений генерить код построения GUI в момент билда.

Так WPH XAML компилируется в код. Внутри используется DirectX.

https://metanit.com/sharp/wpf/2.php

При компиляции приложения в Visual Studio код в xaml-файлах также компилируется в бинарное представление кода xaml, которое называется BAML (Binary Application Markup Language). И затем код baml встраивается в финальную сборку приложения — exe или dll-файл.

По сути то можно обходиться и без XAML программно используя компоненты.

Есть вариант с динамической загрузкой XAML
https://professorweb.ru/my/WPF/base_WPF/level2/2_10.php

DependencyObject rootElement;
            using (FileStream fs = new FileStream(xamlFile, FileMode.Open))
            {
                rootElement = (DependencyObject)XamlReader.Load(fs);
            }

Очевидно, что динамическая загрузка XAML не будет столь же эффективной, как компиляция XAML в BAML с последующей загрузкой BAML во время выполнения, особенно в случае сложного пользовательского интерфейса. Тем не менее, она открывает ряд возможностей для построения динамических пользовательских интерфейсов

V>Кстате, первым делом, когда я увидел WPF, я посмотрел именно на это — есть ли там возможность не только интерпретировать в рантайм эти шаблоны, но и "скомпиллировать" их в код? Такой возможности не увидел и забил на это г-но.

А можно ссылочку на невозможность скомпилировать. Тот же UWP вообще компилируется в натив.

V>У них там есть преобразование XML-текста в "бинарный вид" XBP, мол это "немного ускоряет интерпретацию XML". А-а-а-а-а, бестолочи...
V>

V>The compiled XAML file is pre-tokenized so that, at run time, loading it should be much faster than loading a XAML file

Комптлируется в BAML , И затем код baml встраивается в финальную сборку приложения — exe или dll-файл.
Еще раз посмотри Net Native и UWP

V>Неисправимые нубы, хосподя... За такое должно быть жутко, болезненно стыдно...
V>Тут я, в общем, окончательно махнул рукой на весь этот десад. Разочаровался. Когда-то ожидал от дотнета большего, но он явно делается какими-то левыми индусами-полупрограммистами с двумя извилинами в голове.

V>Причем, это такое, знаешь ли, фундаментальнейшее нубство. Т.е. из разряда, когда люди в упор не видят тривиальнейших вещей. )) Т.е., даже не состоянии оторвать нос от своего поделия, оглянуться по сторонам и посмотреть — а как такие задачи решаются в других технологиях?

V>В принципе, подобный генератор-компилятор в код можно было бы накатать и самому, ес-но (я как раз первым делом экспериментировал с "ручным" созданием WPF GUI, без XML), но зачем, если в конкурирующих технологиях эти генераторы всегда идут изкаробки?


Еще раз нужно не только построить DOM, но и отрабатывать кучу событий без участия сервера.
V>И что-то мне подсказывается, что если речь о ДЕЙСТВИТЕЛЬНО небольших мобильных приложениях на основе некоего HTML-фреймворка, типа XUL или CEF, то показанное мною явно предпочтительнее всех Электронов вместе взятых. ))

V>Тут вся польза в Электроне в этом смысле лишь в наличии "вылизанных" под конкретную тематику оформления CSS, больше ни в чем.

CEF позволяет использовать натив в JS, и JS из натива. То есть по сути иметь GUI в виде браузера, а натив ( а через него и манагед) выступает как приложение.
То о чем вы радостно кричите про WebAssembly.
А я показал как можно в Net Core использовать браузер как GUI

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

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

S>>>>Во во оно и видно. Ты все еще мыслишь категориями 2000 и контролами.
V>>>Ну ты же не знаешь, как я HTML-текст генерил, верно?
S>> то что генерится на сервере это уже 2000

V>Зачем на сервере? Нейтивная приложуха генерит генерит HTML-текст по данным.

Мы говорим про браузер.

V>Да, с отделением шаблонов представлений от данных не возился, да это было и не нужно для почти одноразовых задач.
V>Во-первых, приличная часть такого разделения выполняется на стороне CSS, т.е. темы уже переключать можно.
V>Во-вторых, в рантайм такое отделение не требуется вообще никогда.
V>Т.е., на этапе проектирования потусовать туда-сюда шаблоны — это ОК, это понятно.
V>Но в момент билда из шаблона представления должен собираться максимально приближённый к конечному вариант.

Еще раз. Angular 2 генерит Dom, а не HTML, который еще нужно распарсить и построить DOM
V>Это я критикую философию WPF, где в динамике выполняется много таких действий, которые одни и те же при каждом запуске, т.е. могли быть выполнены в момент билда приложения. Т.е. это жуткий бред вообще в WPF происходит, когда тащат шаблоны в ресурсы. При правильном подходе положено из шаблонов представлений генерить код построения GUI в момент билда.

Так WPH XAML компилируется в код. Внутри используется DirectX.

https://metanit.com/sharp/wpf/2.php

При компиляции приложения в Visual Studio код в xaml-файлах также компилируется в бинарное представление кода xaml, которое называется BAML (Binary Application Markup Language). И затем код baml встраивается в финальную сборку приложения — exe или dll-файл.

По сути то можно обходиться и без XAML программно используя компоненты.

Есть вариант с динамической загрузкой XAML
https://professorweb.ru/my/WPF/base_WPF/level2/2_10.php

DependencyObject rootElement;
            using (FileStream fs = new FileStream(xamlFile, FileMode.Open))
            {
                rootElement = (DependencyObject)XamlReader.Load(fs);
            }

Очевидно, что динамическая загрузка XAML не будет столь же эффективной, как компиляция XAML в BAML с последующей загрузкой BAML во время выполнения, особенно в случае сложного пользовательского интерфейса. Тем не менее, она открывает ряд возможностей для построения динамических пользовательских интерфейсов

https://msdn.microsoft.com/ru-ru/library/aa970678(v=vs.110).aspx

На этапе основной компиляции осуществляется компиляция файлов кода. Это происходит по логике, содержащейся в специфичных для языка файлах целей Microsoft.CSharp.targets и Microsoft.VisualBasic.targets.. Если эвристика определила, что первого этапа компилятора разметки достаточно, то создается основная сборка. Тем не менее, если один или несколько файлов XAML в проекте имеют ссылки на локально определенные типы, то затем создается временный DLL-файл, чтобы по завершении второго этапа компиляции разметки могли быть созданы окончательные сборки приложения.

V>Кстате, первым делом, когда я увидел WPF, я посмотрел именно на это — есть ли там возможность не только интерпретировать в рантайм эти шаблоны, но и "скомпиллировать" их в код? Такой возможности не увидел и забил на это г-но.

А можно ссылочку на невозможность скомпилировать. Тот же UWP вообще компилируется в натив.

V>У них там есть преобразование XML-текста в "бинарный вид" XBP, мол это "немного ускоряет интерпретацию XML". А-а-а-а-а, бестолочи...
V>

V>The compiled XAML file is pre-tokenized so that, at run time, loading it should be much faster than loading a XAML file

Комптлируется в BAML , И затем код baml встраивается в финальную сборку приложения — exe или dll-файл.
Еще раз посмотри Net Native и UWP

V>Неисправимые нубы, хосподя... За такое должно быть жутко, болезненно стыдно...
V>Тут я, в общем, окончательно махнул рукой на весь этот десад. Разочаровался. Когда-то ожидал от дотнета большего, но он явно делается какими-то левыми индусами-полупрограммистами с двумя извилинами в голове.

V>Причем, это такое, знаешь ли, фундаментальнейшее нубство. Т.е. из разряда, когда люди в упор не видят тривиальнейших вещей. )) Т.е., даже не состоянии оторвать нос от своего поделия, оглянуться по сторонам и посмотреть — а как такие задачи решаются в других технологиях?

V>В принципе, подобный генератор-компилятор в код можно было бы накатать и самому, ес-но (я как раз первым делом экспериментировал с "ручным" созданием WPF GUI, без XML), но зачем, если в конкурирующих технологиях эти генераторы всегда идут изкаробки?


Еще раз нужно не только построить DOM, но и отрабатывать кучу событий без участия сервера.
V>И что-то мне подсказывается, что если речь о ДЕЙСТВИТЕЛЬНО небольших мобильных приложениях на основе некоего HTML-фреймворка, типа XUL или CEF, то показанное мною явно предпочтительнее всех Электронов вместе взятых. ))

V>Тут вся польза в Электроне в этом смысле лишь в наличии "вылизанных" под конкретную тематику оформления CSS, больше ни в чем.

CEF позволяет использовать натив в JS, и JS из натива. То есть по сути иметь GUI в виде браузера, а натив ( а через него и манагед) выступает как приложение.
То о чем вы радостно кричите про WebAssembly.
А я показал как можно в Net Core использовать браузер как GUI