Re[17]: Программы в сохраненной html-странице -- почему не р
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 01.04.17 15:34
Оценка:
Здравствуйте, vdimas, Вы писали:

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


S>>При этом эту ВК тоже качают и используют.

S>>На самом то дело не в продукте, а в том, что я Никто и звать меня никак.

V>Кто ты такой — решать лишь тебе.

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

Мне вот интересно, покажи где у меня проблемы с совестью.
Если я был не прав, то я извинюсь. Я признаю свои ошибки.

Ну а кратко наша беседа
1. Ты говоришь, что TS отстой ибо компилируется в JS, а DART супер ибо компилируется в VM.
При этом TS компилируется в DART, а VM существует только на сервере.
И все применение Dart то же, что и TS компиляция в JS.

2. Я говорю, что у меня есть технология использования классов .Net в браузере, в частности через TS.
При этом я могу использовать и JS классы и на стороне .Net. Там особо нет проблем.

Ты же даешь ссылки на контролы. Это далеко не одно и тоже.

Дальше ты говоришь, что NetStandard 2 отстой

Было уже когда-то, когда регили C# и основные классы дотнета в ECMA.
Не взлетело.


При чем тут ECMA, когда речь идет про стандартизацию библиотек внутри .Net
Ибо их сейчас 3 вида .Net Framework, Net Core и Xamarin

NET Standard solves the code sharing problem for .NET developers across all platforms by bringing all the APIs that you expect and love across the environments that you need: desktop applications, mobile apps & games, and cloud services:
.NET Standard is a set of APIs that all .NET platforms have to implement. This unifies the .NET platforms and prevents future fragmentation.
.NET Standard 2.0 will be implemented by .NET Framework, .NET Core, and Xamarin. For .NET Core, this will add many of the existing APIs that have been requested.
.NET Standard 2.0 includes a compatibility shim for .NET Framework binaries, significantly increasing the set of libraries that you can reference from your .NET Standard libraries.
.NET Standard will replace Portable Class Libraries (PCLs) as the tooling story for building multi-platform .NET libraries.
You can see the .NET Standard API definition in the dotnet/standard repo on GitHub.



Опять же когда идет разговор прот Angular 2, то по сути это Дксктопный GUI, который прекрасно живет на коиенте без сервера.
Для построения DOM не нужно гонять тонны данных на сервер и с сервера по каждому клику. Нужны только данные которые. Используя патерн MVVM все делать на клиенте, по сути превращая браузер в GUI.

Ты же говоришь про PHP. Опять возвращаемся к началу 2000.Еще вспомни WebForms.

Ты когда GUI на декстопе делаешь, тоже используешь PHP?

Вот и вся тема нашего разговора. Кто пра, а кто нет пусть решают другие. Я прислушаюсь к их мнению.
и солнце б утром не вставало, когда бы не было меня
Отредактировано 01.04.2017 16:37 Serginio1 . Предыдущая версия . Еще …
Отредактировано 01.04.2017 15:41 Serginio1 . Предыдущая версия .
Re[24]: Программы в сохраненной html-странице -- почему не р
От: vdimas Россия  
Дата: 01.04.17 18:12
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>>>Во во оно и видно. Ты все еще мыслишь категориями 2000 и контролами.

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

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

Выглядит как-то так:
struct Item {
    int id;
    string name;

    RENDER(node) {
      node
        (panel, cls="item")
          VAR(id)
          VAR(name)
        (!panel)
     (end);
    }   
};

struct Form1 {
    vector<Item> items_;

    RENDER(node) {
      node
      (panel, style="style1", "Some visible header")
        (list, items_)
        (button, "OK", onClickOK)
        (button, "Cancel", onClickCancel)
        (label, "Some information")
      (end); // вот тут закроет все вложенные открытые элементы
    }
};


Немного инфраструктуры для VAR:
template<typename T>
struct Var {
    const char * name;
    const T & value;

    RENDER(node) {
      node
      (panel, cls="field")
        (span, cls="name")[name][": "](!span)
        (span, cls="value")[value](!span)
      (end);
    }
};

template<typename T>
Var<T> makeVar(const char *n, const T & v) {
    return Var{n, v};
}

#define VAR(v) (makeVar(##v, v))


И для вектора:
template<typename T> 
struct ListNode<vector<T>> { 
    RENDER(node) {
      Node lst = node(list);
      foreach(const T & item, *this) 
        lst(item);    
      node(!list);
    }
}


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

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

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

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

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

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

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

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

В общем, возвращаясь в реальность — за пару часов на коленке можно собрать достаточно развитый DSL для типобезопасной генерации HTML на плюсах. Просто сам язык располагает к таким вещам.
Поищи в гугле "С++ XML DSL", их хватает.
element page = xml 
    (html)
        (head)
            (title)
                ["Vasya Pupkin's home page"]
            (!title)
        (!head)
        (body)
            (h1,align="center")
                ["Welcome to my home page!!!"]
            (!h1)
        (!body)
    (!html);


Или такое:
document doc =
        _
        <html>_
            <head>_
                <title>"XSMELL demo"<!title>_
            <!head>_
            <body>_
                <p>"Yesssssssssssssssss!"<!p>_
                <img .src("chucknorris.png") .alt("sneezing eyes open")>_ <!img>_
            <!body>_
        <!html>
        _;

    std::cout << doc << '\n';


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

Тут вся польза в Электроне в этом смысле лишь в наличии "вылизанных" под конкретную тематику оформления CSS, больше ни в чем.
Отредактировано 02.04.2017 7:09 vdimas . Предыдущая версия . Еще …
Отредактировано 02.04.2017 7:07 vdimas . Предыдущая версия .
Re: Программы в сохраненной html-странице -- почему не развиты?
От: bnk СССР http://unmanagedvisio.com/
Дата: 01.04.17 18:54
Оценка:
Здравствуйте, Shmj, Вы писали:

S>А ведь такая простая возможность создавать утилитные кроссплатформенные приложения упущена...


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

Если подумать, чего не хватает сайту? Доступа к файлам пользователя?
Дак он есть, с разрешения (html5 file api). К тому же и файлы сейчас на компе все меньше хранятся (dropbox/onedrive/etc)
Доступ к устройствам (типа принтеров-сканеров-моей-любимой-адруины)? Пилят потихоньку (стандарт usbweb например — свежак). Распространенные (микрофон-звук-камера-gps) уже поддерживаются (html5, webrtc)
Или мало производительности? WebAssembly скоро будет.

Зачем еще десктоп-приложения?
Re[25]: Программы в сохраненной html-странице -- почему не р
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 01.04.17 18:59
Оценка:
Здравствуйте, 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
и солнце б утром не вставало, когда бы не было меня
Отредактировано 01.04.2017 19:06 Serginio1 . Предыдущая версия .
Re[2]: Программы в сохраненной html-странице -- почему не развиты?
От: Shmj Ниоткуда  
Дата: 01.04.17 19:33
Оценка:
Здравствуйте, bnk, Вы писали:

bnk>Зачем еще десктоп-приложения?


Для оффлайн работы.
Re[3]: Программы в сохраненной html-странице -- почему не развиты?
От: bnk СССР http://unmanagedvisio.com/
Дата: 01.04.17 20:14
Оценка:
Здравствуйте, Shmj, Вы писали:

bnk>>Зачем еще десктоп-приложения?


S>Для оффлайн работы.


Это да. AFAIK последняя попытка "настоящих оффлайн приложений из коробки" — service workers. Если взлетит, хорошо.

Таскать свою собственную версию браузера на N MB для приложения из 1 KB — ака cef, electron — как-то не айс.
Re[20]: Программы в сохраненной html-странице -- почему не р
От: DenisCh Россия  
Дата: 02.04.17 02:33
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> DC>Я сколько раз говорил, что твои извращения в 1с не нужны?

S> Их использует куча народа. И я в том числе.

Извини, я я лично не знаком с тобой. И не знаю, насколько ты большая куча.

А вот твои извращения не нужны. Я тебе об этом не первый год говорю.
avalon/2.0.3
Re[21]: Программы в сохраненной html-странице -- почему не р
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 02.04.17 06:10
Оценка:
Здравствуйте, DenisCh, Вы писали:

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


S>> DC>Я сколько раз говорил, что твои извращения в 1с не нужны?

S>> Их использует куча народа. И я в том числе.

DC>Извини, я я лично не знаком с тобой. И не знаю, насколько ты большая куча.


DC>А вот твои извращения не нужны. Я тебе об этом не первый год говорю.


Еще раз. Если тебе не нужно, это не значит, что это не нужно всем.
и солнце б утром не вставало, когда бы не было меня
Re[26]: Программы в сохраненной html-странице -- почему не р
От: vdimas Россия  
Дата: 02.04.17 07:07
Оценка:
Здравствуйте, Serginio1, Вы писали:

V>>>>Ну ты же не знаешь, как я HTML-текст генерил, верно?

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

И? Проблемы?


V>>Т.е., на этапе проектирования потусовать туда-сюда шаблоны — это ОК, это понятно.

V>>Но в момент билда из шаблона представления должен собираться максимально приближённый к конечному вариант.
S>Еще раз. Angular 2 генерит Dom, а не HTML, который еще нужно распарсить и построить DOM

Это еще неизвестно, что быстрее: сделать несколько сотен вызовов DOM из JS (причем, самым-пресамым тормозным образом — через селекторы), или один раз подать HTML-текст в нейтивный парсер браузерного движка.


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

S>Так WPH XAML компилируется в код.

Не компилируется. В ресурсах так и хранится XML. Разве что в токенизированном виде.

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

S>

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


BAML — это и есть XML. Там всей разницы, что его парсинг чуть быстрее.
Но все остальное происходит динамически — поиск зависимых св-в контролов по имени, определение типа зависимого св-ва, биндинг к ним и т.д.
Это не что иное как интерпретация данных, и вот она — одна из самых тормозных частей WPF.
При том что если сгенерировать код построения "сцены", то обращение к зависимым св-вам будет статически-типизированным.

S>Внутри используется DirectX.


DirectX тоже используется криво и косо, я тут лет 7 назад разбирал и подробно описывал происходящее.
На стороне дотнета сериализуется набор байт, в которых закодированы команды-вызовы в DirectX, а нейтивная DLL эти команды "проигрывает", т.е. осуществляет реальные вызовы в DirectX. В общем, тут дело в том, что вызов методов COM-объектов из C# медленный. Ну вот вызов импортированной бинарной ф-ии быстрый, а методов имено COM-объектов — медленный. Почему? Для каждого вызова запрашивает GetInterface(). Причем, сначала запрашивается интерфейс маршаллинга. Я делал свои нейтивные COM-объекты, подавал их в дотнет и смотрел, что и как именно дергает дотнет в моих компонентах. Фигня там, кароч. Мне пришлось нарисовать набор обычных экспортируемых сишных однострочных ф-ий, которые внутри делают всего одну вещь — вызывают нужный метод интерфейса поданного как параметр указателя на COM-объект. ))
А потом и от этого ушел, переписав на нейтиве приличный кусок.


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


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


S> Есть вариант с динамической загрузкой XAML

S>https://professorweb.ru/my/WPF/base_WPF/level2/2_10.php

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

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


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

S>А можно ссылочку на невозможность скомпилировать.

Э-э-э... Я не могу привести ссылку на "нечто", что я так и не нашел.

Если ты нашел возможность сгенерить из XAML код построения сцены, то поделись такой ссылкой.


S>Тот же UWP вообще компилируется в натив.


Нейтив не означает отсутствие динамики.
Все твои динамические языки писаны на нейтиве, если что. ))


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


Вот это и ужасно.
Или ты так и не понял сути моих претензий?


S>Еще раз посмотри Net Native и UWP


На что именно посмотреть?
UWP — это лишь ограниченный набор WinAPI + ср-ва по динамическому определению наличия некоего АПИ.


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

S>Еще раз нужно не только построить DOM, но и отрабатывать кучу событий без участия сервера.

При чём тут вообще сервер, если речь о клиентской приложухе?


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

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

Сосредоточься, плиз. Для небольших приложений JS вообще никакой выгоды не даёт.
А для больших — тем более. ))
Я уже говорил, где, на мой взгляд, скрипты рулят.
Только не для "приложений".
Они рулят для автоматизации какой-нить рутины, т.е. как инструмент для построения небольших утилит для разработчика.


S>То есть по сути иметь GUI в виде браузера


— ты куда, в баню?
— да нет, в баню!
))


S>То о чем вы радостно кричите про WebAssembly.

S>А я показал как можно в Net Core использовать браузер как GUI

1. Это старо как мир.
2. Ты показал самый неэффективный на сегодня сценарий:

О-о-о, да при такой схеме твоя приложуха на три вшивые GUI-кнопки съест всю батарейку за 15 мин.

Re[27]: Программы в сохраненной html-странице -- почему не р
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 02.04.17 07:35
Оценка:
Здравствуйте, vdimas, Вы писали:

Смотри


Есть XAML


<Entry Text="{Binding Path=price, Mode=TwoWay, StringFormat='{}{0:c}'}" Keyboard="Numeric" Completed="updateItem" />


Есть

async void updateItem(object sender, EventArgs e)
{
    var item = (MyItemType) ((Entry)sender).BindingContext;

    //Code to update the item with the SQLite database with the new price
}



Как бы не хранился XAML он компилируется в код.
Иначе бы к Entry нельзя обратиться и не изменял свойства через код, не добавлял новые элементы.

Что касается DOM из JS. Как правило нужно при клике, что то добавить или удалить.
Нужна одна команда.

При серверном варианте это получение HTML.
Он либо полностью заменяет страницу, либо через AJAX встраивается в контейнер.

Э
и солнце б утром не вставало, когда бы не было меня
Отредактировано 02.04.2017 7:50 Serginio1 . Предыдущая версия . Еще …
Отредактировано 02.04.2017 7:49 Serginio1 . Предыдущая версия .
Re[22]: Программы в сохраненной html-странице -- почему не р
От: DenisCh Россия  
Дата: 02.04.17 07:50
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> S>> DC>Я сколько раз говорил, что твои извращения в 1с не нужны?

S> S>> Их использует куча народа. И я в том числе.
S> DC>Извини, я я лично не знаком с тобой. И не знаю, насколько ты большая куча.
S> DC>А вот твои извращения не нужны. Я тебе об этом не первый год говорю.
S> Еще раз. Если тебе не нужно, это не значит, что это не нужно всем.

Ну, например линух тоже не нужен. Но находятся извращенцы...

Может, просто лучше подбирать инструмент под задачу, а не заниматься любимим рсдн-овским делом с совой и глобусом?
avalon/2.0.3
Re[23]: Программы в сохраненной html-странице -- почему не р
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 02.04.17 07:58
Оценка:
Здравствуйте, DenisCh, Вы писали:



DC>Ну, например линух тоже не нужен. Но находятся извращенцы...


DC>Может, просто лучше подбирать инструмент под задачу, а не заниматься любимим рсдн-овским делом с совой и глобусом?


А ты не читатель. Еще раз

Использование сборок .NET в 1С 7.x b 8.x. Создание внешних Компонент

Посмотри сколько просмотров. И скачивания за денежку.
Есть ссылки в открытом доступе Как вызвать метод из C# в 1С?

Что касаетя Ъ, то это вопрос к 1С почему они не хотят возвращать объекты и передавать их в параметрах.
И опять же ты же не пишешт создателям JQuery про $
и солнце б утром не вставало, когда бы не было меня
Re[28]: Программы в сохраненной html-странице -- почему не р
От: vdimas Россия  
Дата: 02.04.17 13:11
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Смотри

S>Есть XAML
S>Как бы не хранился XAML он компилируется в код.

Не компилируется XAML ни в какой код.


S>Иначе бы к Entry нельзя обратиться и не изменял свойства через код, не добавлял новые элементы.


Происходит интерпретация XML в рантайм, т.е. биндинг создаётся при загрузке формы.
А почему именно интерпретация — вопрос вопросов, однако.

Почему на стороне ASP.Net из шаблона страницы генерят код, и почему тут ниасилили?

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


S>Что касается DOM из JS. Как правило нужно при клике, что то добавить или удалить.

S>Нужна одна команда.

И какие проблемы добавить или удалить элементы непосредственно через DOM без всякого промежуточного JS?
Как IE, так и CEF и XUL дают возможность оперировать элементами DOM непосредственно, из нейтива.
Для IE есть дотнетная обертка от MS, для XUL есть кроссплатформенная дотнетная обертка GeckoFX.
Для WebKit вот тоже вижу обертку:
https://github.com/webkitdotnet/webkitdotnet
Вот еще для CEF:
https://www.essentialobjects.com/Products/WebBrowser/Default.aspx


S>При серверном варианте это получение HTML.

S>Он либо полностью заменяет страницу, либо через AJAX встраивается в контейнер.

Я ХЗ при чем тут серверный вариант. Речь шла о клиентской приложухе, использующей графический движок браузера для своего GUI.
Тут есть два конкурирующих способа по динамическому управлению содержимым текущего отображения:
1. Тупая вставка текста в узел:
someNode.InnerHtml = myGeneratedHTML;


2. Ручное добавление элементов в узел:
auto child = someNode.addChild(SomeNodeType);
child.setCssClass("class1");
// и т.д.
...


Для обоих способов никакой JS не нужен и даром.

Вот я рядом показал оперирование DOM без всякого JS:
http://www.rsdn.org/forum/flame.comp/6728513.1
Оттуда:
— добавление элементов:
dynamic row = table.insertRow(-1);
...
row.insertCell(-1).innerHtml = ...

Заметь, что оба указанных подхода сочетаются — но это не мой мопед, я просто переводил некий имеющийся JS-код сугубо в демонстрационных целях. ))

— подписка на события:
elm.LostFocus += (obj, args) => { ...


Итого, даже находясь в координатах C#, бери себе любую из указанных выше оберток над какой-нить браузерной либой — Gecko, Webkit или CEF (который с 13-го года сидит на Blink) — и вперёд.

И никакой JS тебе и даром не нужен, особенно если у тебя наработки из дотнета.
Отредактировано 02.04.2017 13:12 vdimas . Предыдущая версия .
Re[29]: Программы в сохраненной html-странице -- почему не р
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 02.04.17 13:54
Оценка:
Здравствуйте, vdimas, Вы писали:

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


S>> Смотри

S>>Есть XAML
S>>Как бы не хранился XAML он компилируется в код.

V>Не компилируется XAML ни в какой код.



S>>Иначе бы к Entry нельзя обратиться и не изменял свойства через код, не добавлял новые элементы.


V>Происходит интерпретация XML в рантайм, т.е. биндинг создаётся при загрузке формы.

V>А почему именно интерпретация — вопрос вопросов, однако.

Ну в итоге интерпретируется или все же компилируется при загрузке формы?

Да? То есть если мы программно создаем то интерпиртации нет, а вот из XAML то есть?
Есть две компиляции в il и в машинный код

V>Почему на стороне ASP.Net из шаблона страницы генерят код, и почему тут ниасилили?

Вот и я думаю, при чем туи интерпритация.
Давай зададим вопрос на форуме.
V>Проблема еще в том, что при интерпретации XML в рантайм многие ошибки тоже будут сыпаться именно в рантайм (при неверном биндинге или неверной росписи триггеров), хотя львиную долю таких ошибок в рантайме можно было бы избежать, сообщив о них в момент сборки приложения.

Непомню, помоему на этапе компиляции такие ошибки вылетают. Нужно проверить

S>>Что касается DOM из JS. Как правило нужно при клике, что то добавить или удалить.

S>>Нужна одна команда.

V>И какие проблемы добавить или удалить элементы непосредственно через DOM без всякого промежуточного JS?


И каким это образом?
V>Как IE, так и CEF и XUL дают возможность оперировать элементами DOM непосредственно, из нейтива.
V>Для IE есть дотнетная обертка от MS, для XUL есть кроссплатформенная дотнетная обертка GeckoFX.
V>Для WebKit вот тоже вижу обертку:
V>https://github.com/webkitdotnet/webkitdotnet
V>Вот еще для CEF:
V>https://www.essentialobjects.com/Products/WebBrowser/Default.aspx

Угу ты уверен, что они дергают не через JS. И в CEF дергантся через JS методы
https://bitbucket.org/chromiumembedded/cef/wiki/JavaScriptIntegration.md

S>>При серверном варианте это получение HTML.

S>>Он либо полностью заменяет страницу, либо через AJAX встраивается в контейнер.

V>Я ХЗ при чем тут серверный вариант. Речь шла о клиентской приложухе, использующей графический движок браузера для своего GUI.

V>Тут есть два конкурирующих способа по динамическому управлению содержимым текущего отображения:
V>1. Тупая вставка текста в узел:
V>
V>someNode.InnerHtml = myGeneratedHTML;
V>

А ну ты опять о своем. Нахрена использовать для GUI браузер, если есть WPF или UWP?
То что я предлагал, это использование натива из JS и JS из натива?

V>2. Ручное добавление элементов в узел:

V>
V>auto child = someNode.addChild(SomeNodeType);
V>child.setCssClass("class1");
V>// и т.д.
V>...
V>


А ты уверен, что ты не дергаешь JS?
V>Для обоих способов никакой JS не нужен и даром.

Угу. Только вот объект SomeNodeType какие контракты имеет?

V>Вот я рядом показал оперирование DOM без всякого JS:

V>http://www.rsdn.org/forum/flame.comp/6728513.1
V>Оттуда:
V>- добавление элементов:
V>
V>dynamic row = table.insertRow(-1);
V>...
V>row.insertCell(-1).innerHtml = ...
V>

V>Заметь, что оба указанных подхода сочетаются — но это не мой мопед, я просто переводил некий имеющийся JS-код сугубо в демонстрационных целях. ))

V>- подписка на события:

V>
V>elm.LostFocus += (obj, args) => { ...
V>


Ага. Я так же могу и через CEF дергать JS объекты. Ты уверен, что это не COM обертка?
Еще раз
CEF, ES6, Angular 2, TypeScript использование классов .Net Core. Создание кроссплатформенного GUI для .Net с помощью CEF

CEF, Angular 2 использование событий классов .Net Core


Для асинхронных методов и событий, я дергаю JS методы.
Подробнее можно посмотреть здесь, или скачать мой код.
https://bitbucket.org/chromiumembedded/cef/wiki/JavaScriptIntegration.md


V>Итого, даже находясь в координатах C#, бери себе любую из указанных выше оберток над какой-нить браузерной либой — Gecko, Webkit или CEF (который с 13-го года сидит на Blink) — и вперёд.


V>И никакой JS тебе и даром не нужен, особенно если у тебя наработки из дотнета.


Еще раз ты говоришь про контейнеры. Для Net Core нет GUI. Есть Mono. Но он WebForms и умирающая технология с поддержкой 4.5.
и солнце б утром не вставало, когда бы не было меня
Отредактировано 02.04.2017 14:26 Serginio1 . Предыдущая версия . Еще …
Отредактировано 02.04.2017 13:59 Serginio1 . Предыдущая версия .
Re[29]: Программы в сохраненной html-странице -- почему не р
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 02.04.17 14:49
Оценка:
Здравствуйте, vdimas, Вы писали:

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


S>> Смотри

S>>Есть XAML
S>>Как бы не хранился XAML он компилируется в код.

V>Не компилируется XAML ни в какой код.



S>>Иначе бы к Entry нельзя обратиться и не изменял свойства через код, не добавлял новые элементы.


V>Происходит интерпретация XML в рантайм, т.е. биндинг создаётся при загрузке формы.

V>А почему именно интерпретация — вопрос вопросов, однако.

Вот и верь тебе.
Специально сделал приложение, правда UWP

Добавил кнопку в XAML

<Button x:Name="button1" Width="100" Height="40" Content="Кнопка" FontFamily="Verdana" Click="button1_Click" />


Заменяю object на string

private void button1_Click(string sender, RoutedEventArgs e)
        {
            //
        }

Жмякаю на собрать решение. И получаю ошибки

Серьезность Код Описание Проект Файл Строка Состояние подавления
Ошибка Error HRESULT E_FAIL has been returned from a call to a COM component.

Серьезность Код Описание Проект Файл Строка Состояние подавления
Ошибка CS0123 Нет перегруженного метода для "button1_Click", который соответствует делегату "RoutedEventHandler".


То есть ошибки олавливаются на этапе компиляции в CIL
и солнце б утром не вставало, когда бы не было меня
Re[30]: Программы в сохраненной html-странице -- почему не р
От: vdimas Россия  
Дата: 03.04.17 01:48
Оценка:
Здравствуйте, Serginio1, Вы писали:

V>>Происходит интерпретация XML в рантайм, т.е. биндинг создаётся при загрузке формы.

V>>А почему именно интерпретация — вопрос вопросов, однако.
S>Ну в итоге интерпретируется или все же компилируется при загрузке формы?

Т.е. ты до сих пор не понял?
А если есть сомнения, то что помешало самому проверить?
В таком подходе к делу я вижу лишь ту самую среду патологических лентяев, среди которых живут и размножаются слухи/мифы.


S>Да? То есть если мы программно создаем то интерпиртации нет, а вот из XAML то есть?


Именно так.


S>Есть две компиляции в il и в машинный код


Нет в WPF никакой компиляции в IL.


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

S>Непомню, помоему на этапе компиляции такие ошибки вылетают. Нужно проверить

Лучше бы было проверить, чем писать сюда очередное бессмысленное сообщение.


V>>И какие проблемы добавить или удалить элементы непосредственно через DOM без всякого промежуточного JS?

S>И каким это образом?

Я ссылку давал.


V>>Вот еще для CEF:

V>>https://www.essentialobjects.com/Products/WebBrowser/Default.aspx
S>Угу ты уверен, что они дергают не через JS.

Если это был вопрос, то вот встречный — ты в своём уме вообще? ))
В первую очередь DOM доступен прямо из языка, на котором написан — на С++.
А вот уже через одно место к нему прикручен биндинг на JS.
И да, существующие дотнетные обертки — они оборачивают нейтивный код, ес-но, а никакой не JS.


S>И в CEF дергантся через JS методы


Исходники открыты, что тебе помешало посмотреть на реализацию WebKit и на то, как идёт работа с ним из CEF?
Лень-матушка? ))
Ты же опять подставляешься по самые помидоры.
Выходит, ты работал с некоей технологией, но всё-равно обломался на неё толком посмотреть.


S>https://bitbucket.org/chromiumembedded/cef/wiki/JavaScriptIntegration.md


Очередное проявление бессовестности.
Давать ссылку и не удосуживаться прочесть инфу по ней хотя по диагонали.


V>>Я ХЗ при чем тут серверный вариант. Речь шла о клиентской приложухе, использующей графический движок браузера для своего GUI.

V>>Тут есть два конкурирующих способа по динамическому управлению содержимым текущего отображения:
V>>1. Тупая вставка текста в узел:
V>>
V>>someNode.InnerHtml = myGeneratedHTML;
V>>

S>А ну ты опять о своем. Нахрена использовать для GUI браузер

А я здесь причем? Это ж ты такое условие поставил несколькими сообщениями выше и в этом топике тоже.
Тебе оно нужно якобы для кроссплатформенности.


S>если есть WPF или UWP?


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

Слово UWP тоже забудь, потому что ты не понимаешь, что есть UWP.
И никогда его не упоминай до тех пор пока не поймешь, насколько нелепо ты его вставляешь не в тот контекст.
Для твоей тематики пользуй только лишь аббревиатуру WinRT и ни в коем случае не UWP.
Потому что тебя никто понимать не будет и будут смотреть как на чудака.
Потому что ты вовсе не UWP имеешь ввиду во всей этой беседе, а банальный нейтивный WinRT.
И мне уже порядком надоело продираться сквозь чащу твоей неточности и поверхностности, положа руку на.


S>То что я предлагал, это использование натива из JS и JS из натива?


Ты предлагал некие результаты своих экспериментов.
А я тебе объяснял, почему не надо их предлагать.
Потому что если бы ты поставил себе себе задачу нормально, то ты бы её решил малость по-другому.

Но ты не ставил никакой задачи, ес-но, ты просто экспериментировал... и в какой-то момент решил, что наэкспериментировал что-то интересное.


V>>2. Ручное добавление элементов в узел:

V>>
V>>auto child = someNode.addChild(SomeNodeType);
V>>child.setCssClass("class1");
V>>// и т.д.
V>>...
V>>

S>А ты уверен, что ты не дергаешь JS?

Как бы так подобрать сюда эпитеты, чтобы меня не забанили? ))
Ну ты хоть порассуждал бы...
Из JS недоступно никакой другой функциональности кроме той, которую экспортируют в его контекст исполнения, так?
Т.е., прежде чем что-то станет доступно из JS, оно должно быть доступно и без JS, напрямую, верно?

Так с каких хреней, простите, ты, глядя на совершенно абстрактную демонстрацию непосредственного обращения к DOM, и даже при наличии пояснения в том же сообщении об именно "непосредственном оперировании DOM", пишешь вот эту несусветную свою ерунду? Кто тебе вообще дал право ВОТ ТАК формулировать свои вопросы? Когда люди формулируют именно таким образом свои вопросы, то это всегда означает, что у них ЕСТЬ основания думать иначе и они эти основания готовы предъявить, ес-но. Потому что в противном случае получается то самое "быкование", т.е. тупое хамство, придирки и прочие бессовестные вещи из разряда "семки есть? а если найду?"


V>>Для обоих способов никакой JS не нужен и даром.

S>Угу. Только вот объект SomeNodeType какие контракты имеет?

Сугубо нейтивные.


S>Ага. Я так же могу и через CEF дергать JS объекты.


Именно поэтому твоя "матрешка" никуда не годится.
Именно поэтому уже 50 сообщений до тебя никак не дойдёт простейшая причина, по которой я предлагал тебе ну хотя бы GeckoFX.


S>Ты уверен, что это не COM обертка?


В нейтиве COM — это никакая не обертка. Это непосредственные виртуальные ф-ии объектов С++, это и есть нейтивная реализация.
Это в дотнете обертки над COM.
Но COM-оберток для дотнетных объектов не бывает (если сам ручками реализацию COM-интерфейсов не распишешь по всем правилам маршаллинга).
Автоматом бывает только нетипизированный IDispatch.
Разумеется, показанный мною код никакой IDispatch не трогает.
Ты можешь уточнить в MSDN методы интерфейса IDispatch и убедиться, что сие так и есть. )))


S>Еще раз

S>CEF, ES6, Angular 2, TypeScript использование классов .Net Core. Создание кроссплатформенного GUI для .Net с помощью CEF

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


S>Для асинхронных методов и событий, я дергаю JS методы.


Потому что ты ни исследования имеющихся решений под CEF не провел, ни архитектуру самого CEF смотреть не стал.
Потому что ты неисправимый лентяй.

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


S>Еще раз ты говоришь про контейнеры.


Еще раз ты потерял остатки совести расписываться за оппонента.
Какие еще в опу "контейнеры"?


S>Для Net Core нет GUI.


С чего ты взял-то?


S>Есть Mono. Но он WebForms и умирающая технология с поддержкой 4.5.


GUI и Mono как связаны?

Сколько дотнетных оберток над нейтивными GUI-либами ты вообще смотрел?
Их же много десятков.

Если в Net Core есть стандартный интероп, то все эти десятки либ автоматом доступны из Net Core.

===========
Кароч, сорри, но ты сложен в общении сразу по многим показателям.
Откланиваюсь.
Re[30]: Программы в сохраненной html-странице -- почему не р
От: vdimas Россия  
Дата: 03.04.17 01:58
Оценка:
Здравствуйте, Serginio1, Вы писали:

V>>Происходит интерпретация XML в рантайм, т.е. биндинг создаётся при загрузке формы.

V>>А почему именно интерпретация — вопрос вопросов, однако.
S>Вот и верь тебе.

А своему любимому SO веришь?


S>Специально сделал приложение, правда UWP


Это один из любимых вопросов по WPF:
http://stackoverflow.com/questions/4225867/how-can-i-turn-binding-errors-into-runtime-exceptions
http://stackoverflow.com/questions/19274594/turn-wpf-binding-error-into-runtime-exception-not-working-on-published-released


S>Добавил кнопку в XAML


Слишком просто, низачот.
Попробуешь еще раз?
Re[31]: Программы в сохраненной html-странице -- почему не р
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 03.04.17 07:21
Оценка: :)
Здравствуйте, vdimas, Вы писали:

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


V>>>Происходит интерпретация XML в рантайм, т.е. биндинг создаётся при загрузке формы.

V>>>А почему именно интерпретация — вопрос вопросов, однако.
S>>Вот и верь тебе.

V>А своему любимому SO веришь?



S>>Специально сделал приложение, правда UWP


V>Это один из любимых вопросов по WPF:

V>http://stackoverflow.com/questions/4225867/how-can-i-turn-binding-errors-into-runtime-exceptions
V>http://stackoverflow.com/questions/19274594/turn-wpf-binding-error-into-runtime-exception-not-working-on-published-released


S>>Добавил кнопку в XAML


V>Слишком просто, низачот.

V>Попробуешь еще раз?
Попробуй сам. Я тебе не из головы выдумал. И ошибки показал.
Кроме того UWP не совсем WPF, но XAML почти тот же. Нет времени проверять WPF. Там кстати и версия .Net 4,5,1
и солнце б утром не вставало, когда бы не было меня
Отредактировано 03.04.2017 7:25 Serginio1 . Предыдущая версия .
Re[31]: Программы в сохраненной html-странице -- почему не р
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 03.04.17 08:39
Оценка: -1
Здравствуйте, vdimas, Вы писали:


V>Нет в WPF никакой компиляции в IL.



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

S>>Непомню, помоему на этапе компиляции такие ошибки вылетают. Нужно проверить

V>Лучше бы было проверить, чем писать сюда очередное бессмысленное сообщение.


Проверил http://rsdn.org/forum/flame.comp/6744672.1
Автор: Serginio1
Дата: 02.04.17

Будешь извиняться за " очередное бессмысленное сообщение"

V>>>И какие проблемы добавить или удалить элементы непосредственно через DOM без всякого промежуточного JS?

S>>И каким это образом?

V>Я ссылку давал.



V>>>Вот еще для CEF:

V>>>https://www.essentialobjects.com/Products/WebBrowser/Default.aspx
S>>Угу ты уверен, что они дергают не через JS.

V>Если это был вопрос, то вот встречный — ты в своём уме вообще? ))

V>В первую очередь DOM доступен прямо из языка, на котором написан — на С++.
V>А вот уже через одно место к нему прикручен биндинг на JS.
V>И да, существующие дотнетные обертки — они оборачивают нейтивный код, ес-но, а никакой не JS.

Угу при этом создаются и добавляются именно объекты JS
S>>И в CEF дергантся через JS методы

V>Исходники открыты, что тебе помешало посмотреть на реализацию WebKit и на то, как идёт работа с ним из CEF?

V>Лень-матушка? ))
V>Ты же опять подставляешься по самые помидоры.
V>Выходит, ты работал с некоей технологией, но всё-равно обломался на неё толком посмотреть.
Да да. Ты только болтун

S>>https://bitbucket.org/chromiumembedded/cef/wiki/JavaScriptIntegration.md


V>Очередное проявление бессовестности.

V>Давать ссылку и не удосуживаться прочесть инфу по ней хотя по диагонали.
И что тапм не так?
прежде чем заявлять о бессовестности покажи, что там не так. Я же даю СВОЙ код и знаю как устроено.


V>>>Я ХЗ при чем тут серверный вариант. Речь шла о клиентской приложухе, использующей графический движок браузера для своего GUI.

V>>>Тут есть два конкурирующих способа по динамическому управлению содержимым текущего отображения:
V>>>1. Тупая вставка текста в узел:
V>>>
V>>>someNode.InnerHtml = myGeneratedHTML;
V>>>

S>>А ну ты опять о своем. Нахрена использовать для GUI браузер

V>А я здесь причем? Это ж ты такое условие поставил несколькими сообщениями выше и в этом топике тоже.

V>Тебе оно нужно якобы для кроссплатформенности.

Да при том, что я говорю о браузере, а не контороллере.

S>>если есть WPF или UWP?


V>WPF, считай, что нет и никогда не существовало в природе.

V>Всё, забудь, это была случайная ошибка природы.
V>Временное помутнение одного из стад индусов.


V>Слово UWP тоже забудь, потому что ты не понимаешь, что есть UWP.

V>И никогда его не упоминай до тех пор пока не поймешь, насколько нелепо ты его вставляешь не в тот контекст.
V>Для твоей тематики пользуй только лишь аббревиатуру WinRT и ни в коем случае не UWP.
V>Потому что тебя никто понимать не будет и будут смотреть как на чудака.
V>Потому что ты вовсе не UWP имеешь ввиду во всей этой беседе, а банальный нейтивный WinRT.
V>И мне уже порядком надоело продираться сквозь чащу твоей неточности и поверхностности, положа руку на.


S>>То что я предлагал, это использование натива из JS и JS из натива?


V>Ты предлагал некие результаты своих экспериментов.

V>А я тебе объяснял, почему не надо их предлагать.
V>Потому что если бы ты поставил себе себе задачу нормально, то ты бы её решил малость по-другому.
Я тебе показывал решение, которое ты даже не удосужился просмотреть, но сразу начал хаять
V>Но ты не ставил никакой задачи, ес-но, ты просто экспериментировал... и в какой-то момент решил, что наэкспериментировал что-то интересное.


V>>>2. Ручное добавление элементов в узел:
V>>>
V>>>auto child = someNode.addChild(SomeNodeType);
V>>>child.setCssClass("class1");
V>>>// и т.д.
V>>>...
V>>>

S>>А ты уверен, что ты не дергаешь JS?

V>Как бы так подобрать сюда эпитеты, чтобы меня не забанили? ))

V>Ну ты хоть порассуждал бы...
V>Из JS недоступно никакой другой функциональности кроме той, которую экспортируют в его контекст исполнения, так?
V>Т.е., прежде чем что-то станет доступно из JS, оно должно быть доступно и без JS, напрямую, верно?

А что по твоему напрямую? По твоему нужно держать две модели одну на JS другую на нативе?
Это как в .Net держать и манагед и натив одновременно. Так было в начале, но потом натив используется очень мало.



V>>>Для обоих способов никакой JS не нужен и даром.

S>>Угу. Только вот объект SomeNodeType какие контракты имеет?

Во во поподробнее. Значит SomeNodeType, а JS объект будет оберткой над нативом? Зачем двойная диспетчеризация.
А
V>Сугубо нейтивные.


S>>Ага. Я так же могу и через CEF дергать JS объекты.


V>Именно поэтому твоя "матрешка" никуда не годится.

V>Именно поэтому уже 50 сообщений до тебя никак не дойдёт простейшая причина, по которой я предлагал тебе ну хотя бы GeckoFX.


S>>Ты уверен, что это не COM обертка?


V>В нейтиве COM — это никакая не обертка. Это непосредственные виртуальные ф-ии объектов С++, это и есть нейтивная реализация.

V>Это в дотнете обертки над COM.
V>Но COM-оберток для дотнетных объектов не бывает (если сам ручками реализацию COM-интерфейсов не распишешь по всем правилам маршаллинга).
V>Автоматом бывает только нетипизированный IDispatch.
V>Разумеется, показанный мною код никакой IDispatch не трогает.
V>Ты можешь уточнить в MSDN методы интерфейса IDispatch и убедиться, что сие так и есть. )))
Тогда зачем ты используешь dynamic а не интерфейсы?

S>>Еще раз

S>>CEF, ES6, Angular 2, TypeScript использование классов .Net Core. Создание кроссплатформенного GUI для .Net с помощью CEF

V>Не надо мне на хабр вообще ссылки приводить.

V>Тем более на некачественные статьи с ужасным исходным кодом.
V>Я тебе уже показывал примеры, как положено экспортировать в JS требуемую функциональность.
V>Продолжать после этого настаивать на своём ужасе — это разновидность хамства и упоротости одновременно.
V>Я не знаю в каком мире ты обитаешь, но один такой закидон в реальной работе — и мгновенно будет указано на дверь.
V>Потому что разработчик, который не способен воспринимать инфу, да еще имеет наглость настаивать на своём некоем "праве" не воспринимать никакую инфу — совершенно бесполезен. А чаще даже вреден.

То есть мои статьи ты не читаешь, но споришь?

S>>Для асинхронных методов и событий, я дергаю JS методы.


V>Потому что ты ни исследования имеющихся решений под CEF не провел, ни архитектуру самого CEF смотреть не стал.

V>Потому что ты неисправимый лентяй.

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


S>>Еще раз ты говоришь про контейнеры.


V>Еще раз ты потерял остатки совести расписываться за оппонента.

V>Какие еще в опу "контейнеры"?

А что это по твоему. Котрол

S>>Для Net Core нет GUI.


V>С чего ты взял-то?


Я тебе приводил авалонию, но она в альфе. Приводи свой пример.

S>>Есть Mono. Но он WebForms и умирающая технология с поддержкой 4.5.


V>GUI и Mono как связаны?


Как WebForm// Как ссылк которые ты давал на контрол браузера для МОНО
V>Сколько дотнетных оберток над нейтивными GUI-либами ты вообще смотрел?
V>Их же много десятков.

Покажи для .Net Core
V>Если в Net Core есть стандартный интероп, то все эти десятки либ автоматом доступны из Net Core.

Нужно сделать обертки. Пока Авалония только в альфе
V>===========
V>Кароч, сорри, но ты сложен в общении сразу по многим показателям.
V>Откланиваюсь.

И я. К сожалению, я был большего мнения о тебе. Не будем больше тратить драгоценное времы на бессмысленные разговоры.
и солнце б утром не вставало, когда бы не было меня
Re[31]: Программы в сохраненной html-странице -- почему не р
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 03.04.17 11:04
Оценка:
Здравствуйте, vdimas, Вы писали:




S>>если есть WPF или UWP?


V>WPF, считай, что нет и никогда не существовало в природе.

V>Всё, забудь, это была случайная ошибка природы.
V>Временное помутнение одного из стад индусов.

V>Слово UWP тоже забудь, потому что ты не понимаешь, что есть UWP.

V>И никогда его не упоминай до тех пор пока не поймешь, насколько нелепо ты его вставляешь не в тот контекст.
V>Для твоей тематики пользуй только лишь аббревиатуру WinRT и ни в коем случае не UWP.
V>Потому что тебя никто понимать не будет и будут смотреть как на чудака.
V>Потому что ты вовсе не UWP имеешь ввиду во всей этой беседе, а банальный нейтивный WinRT.
V>И мне уже порядком надоело продираться сквозь чащу твоей неточности и поверхностности, положа руку на.


Я говорил прежде всего о Xaml. То есть декларативном описании интерфейса.
А его используют WPF, UWP, Xamarin.Forms. Xamarin.Forms использует Tizen.
И главное можно разделить работу верстальщика и программиста.
В свое время на Xamarin можно было писать только код. Затем появился XAML. С XAML удобнее.

Что такое Universal Windows Platform

UWP стала результатом эволюции более ранних технологий. Так, с выходом Windows 8 была внедрена новая архитектурная платформа для приложений — Windows Runtime (WinRT), которая позволяла запускать приложения в так называемом режиме Modern (Metro) на десктопах, планшетах. Затем с выходом Windows 8.1 и Windows Phone 8.1 эта технология получила развитие — появились "универсальные приложения", которые можно было запускать сразу Windows 8.1 и WP8.1. И в июле 2015 года официально вышла новая ОС Windows 10. Она использует платформу UWP, которая представляет собой развитие Windows Runtime.


UWP не поддерживает Windows 8.1 и Windows Phone 8.1
Так, что посмотри наконец на себя. Оцени свои высказываия. У тебя много знаний, но они либо устаревшие, либо поверхностные.

Теперь сделаем простейшее приложение. Визуально приложение UWP представлено через страницы — отдельные объекты Page. По умолчанию в проекте есть только одна страница — MainPage. Код этой страницы и определяет то, что мы увидим на экране при запуске приложения. И теперь немного изменим ее.
Итак, откроем файл MainPage.xaml:

и солнце б утром не вставало, когда бы не было меня
Отредактировано 03.04.2017 11:14 Serginio1 . Предыдущая версия .
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.