Берем пишем прогу на JS внутри HTML-страницы. Сохраняем на диск на компьютере. Когда нужно -- запустили, все открылось. Все работает. Причем все работает и в Win и в Lin и в Mac OS. А еще ведь браузеры есть и во всех моб. телефонах (даже не самых современных), значит и там можно сделать чтобы работало.
Но почему такие приложения не распространены? Ну чтобы 100% все работало оффлайн.
Одна из причин почему не прижилось -- IE не запускает JS в сохраненнных страницах (а ранее он был браузером №1). Ну недотепы. Ну как можно было такую хрень сделать? Ведь если бы всего лишь позволили запускаться JS -- то совсем по другому мир бы развивался.
Ранее были hta-приложения. Сейчас уже лет 10 их не видел, молодежь скорее всего и не знает об их существовании (попробуйте изменить расширение html на hta). Но они то только на Windows работали, по этому смысла мало...
А ведь такая простая возможность создавать утилитные кроссплатформенные приложения упущена...
S>Одна из причин почему не прижилось -- IE не запускает JS в сохраненнных страницах (а ранее он был браузером №1). Ну недотепы. Ну как можно было такую хрень сделать? Ведь если бы всего лишь позволили запускаться JS -- то совсем по другому мир бы развивался.
AFAIR это было сделано по какимто там причинам безопасности и настраивалось, так что это можно было разрешить.
Как много веселых ребят, и все делают велосипед...
Re[2]: Программы в сохраненной html-странице -- почему не развиты?
Здравствуйте, Shmj, Вы писали:
S>Берем пишем прогу на JS внутри HTML-страницы. Сохраняем на диск на компьютере. Когда нужно -- запустили, все открылось. Все работает.
Ты можешь сделать это прямо сейчас.
Всё будет прекрасно работать.
S>Но почему такие приложения не распространены? Ну чтобы 100% все работало оффлайн.
Потому что твоему коду на странице доступны только те ср-ва, которые предоставляет браузер.
А этого мало.
S>Ранее были hta-приложения. Сейчас уже лет 10 их не видел, молодежь скорее всего и не знает об их существовании (попробуйте изменить расширение html на hta). Но они то только на Windows работали, по этому смысла мало...
S>А ведь такая простая возможность создавать утилитные кроссплатформенные приложения упущена...
Как раз в hta ничего кроссплатформенного не было. Там шло создание COM-объектов через CreateObject, т.е. скрипт мог работать с "какой-то еще" функциональностью помимо той, которая предоставляется браузером.
Re[2]: Программы в сохраненной html-странице -- почему не развиты?
Здравствуйте, vdimas, Вы писали:
V>Ты можешь сделать это прямо сейчас. V>Всё будет прекрасно работать.
В EDGE не работает. Где гарантия что вашу прогу пользователь откроет не в EDGE или IE?
V>Потому что твоему коду на странице доступны только те ср-ва, которые предоставляет браузер. V>А этого мало.
А чего именно вам не хватает?
S>>Ранее были hta-приложения. Сейчас уже лет 10 их не видел, молодежь скорее всего и не знает об их существовании (попробуйте изменить расширение html на hta). Но они то только на Windows работали, по этому смысла мало...
V>Как раз в hta ничего кроссплатформенного не было. Там шло создание COM-объектов через CreateObject, т.е. скрипт мог работать с "какой-то еще" функциональностью помимо той, которая предоставляется браузером.
Выделил для вас.
Я о том, что стандарт типа hta или подобного могли сделать для всех платформ, согласовать чтобы работало у всех одинаково.
Re: Программы в сохраненной html-странице -- почему не развиты?
Здравствуйте, Alexander G, Вы писали:
AG>Может потому что JS, с которого в онлайне, как с подводной лодки, никуда не деться, но в оффлайне можно заменить на что угодно более продуктивное?
Не особо заменишь в случае если нужно:
1. Реально кроссплатформенное.
2. Скриптовое, чтобы OpenSource, знать что запускаешь.
3. Не нужно устанавливать, распространяется простым копированием.
Re[3]: Программы в сохраненной html-странице -- почему не развиты?
Здравствуйте, Shmj, Вы писали:
S>1. Реально кроссплатформенное. S>2. Скриптовое, чтобы OpenSource, знать что запускаешь. S>3. Не нужно устанавливать, распространяется простым копированием.
Lua? Вроде как раз там где нужна производительность и скрипты, то выбирают Lua, а не JS.
Да пребудет с тобой Великий Джа
Re[4]: Программы в сохраненной html-странице -- почему не развиты?
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>>Сейчас распространет Electron https://electron.atom.io/
S>Его еще устанавливать нужно. А хочется чтобы без установки -- запустил страницу и все работает. Надо -- подправил скрипт.
S>А еще там нужно скачивать разный файл-бинарник для каждой платформы. А HTML-файл везде один и тот же.
Так в браузере песочница. Там особо то не развернешься.
Пожалуйста по последней статье можно с помощью WebPack сгенерить JS файлы в котором будут и HTML шаблоны, CSS и в купе с основным HTML использовать без сервера
и солнце б утром не вставало, когда бы не было меня
Re: Программы в сохраненной html-странице -- почему не развиты?
S>Берем пишем прогу на JS внутри HTML-страницы. Сохраняем на диск на компьютере. Когда нужно -- запустили, все открылось. Все работает. Причем все работает и в Win и в Lin и в Mac OS. А еще ведь браузеры есть и во всех моб. телефонах (даже не самых современных), значит и там можно сделать чтобы работало. S>Но почему такие приложения не распространены? Ну чтобы 100% все работало оффлайн.
Большинство приложений используют обращения к серверу через всякие Rest API и без сети не заработают. Так что смысла мало.
Make flame.politics Great Again!
Re[3]: Программы в сохраненной html-странице -- почему не развиты?
Здравствуйте, vdimas, Вы писали:
S>>В EDGE не работает. V>В нем недоступен CreateObject().
Причем тут CreateObject? НИ в EDGE ни в IE не работает JS, если открыть страницу с диска.
S>>А чего именно вам не хватает? V>HTA-файлы создавались как альтернатива command-line скриптам, а из тех можно обращаться к файловой системе, останавливать и запускать сервисы и т.д.
Сейчас JS позволяет работать с изолированной файловой системой. Позволяет сохранять файлы на диск в любое место а так же брать файлы с диска. Для многих приложений этого достаточно.
S>>Я о том, что стандарт типа hta или подобного могли сделать для всех платформ, согласовать чтобы работало у всех одинаково. V>Запускай обычную HTML страницу, в ней прекрасно работает JS, т.е. все, что может браузер, можно делать из этой страницы.
Та кне работает в IE и EDGE Не работает. Получается уже привязка к браузеру есть.
Re[2]: Программы в сохраненной html-странице -- почему не развиты?
Здравствуйте, TimurSPB, Вы писали:
TSP>Большинство приложений используют обращения к серверу через всякие Rest API и без сети не заработают. Так что смысла мало.
Можно добавить Offline-режим. Есть же база данных в изолированном хранилище.
Re[3]: Программы в сохраненной html-странице -- почему не развиты?
Здравствуйте, Shmj, Вы писали:
S>>>В EDGE не работает. V>>В нем недоступен CreateObject(). S>Причем тут CreateObject? НИ в EDGE ни в IE не работает JS, если открыть страницу с диска.
Они могут не выполнять скрипты на загруженных и сохранённых локально страницах. Перед этим страницы (и вообще любые файлы) надо разблокировать:
S>Сейчас JS позволяет работать с изолированной файловой системой. Позволяет сохранять файлы на диск в любое место а так же брать файлы с диска. Для многих приложений этого достаточно.
Нихрена JS не позволяет, не придумывай. У него таких встроенных ф-ий банально нет. Он работает с той функциональностью, которую ему экпортирует в виде видимого контекста некий JS-хост, например node.js.
Соответственно в браузере не может быть никакой функциональности у скрипта, кроме предоставляемой хостом-браузером.
S>Та кне работает в IE и EDGE Не работает. Получается уже привязка к браузеру есть.
Я уже боюсь спросить, а что ты на своей работе делаешь? ))
Re: Программы в сохраненной html-странице -- почему не развиты?
Здравствуйте, Shmj, Вы писали:
S>Берем пишем прогу на JS внутри HTML-страницы. Сохраняем на диск на компьютере. Когда нужно -- запустили, все открылось. Все работает. Причем все работает и в Win и в Lin и в Mac OS. А еще ведь браузеры есть и во всех моб. телефонах (даже не самых современных), значит и там можно сделать чтобы работало.
Ну вот, например, сто лет в обед: https://ru.wikipedia.org/wiki/TiddlyWiki
Персональная вики, все изменения прямо в странице через манипуляции с DOM, соответственно, просто страницу сохраняешь и в любой момент можешь снова поднять и все будет работать.
Проверял и не раз. Microsoft Edge 38.14393.0.0 с настройками по умолчанию -- показывает пустой экран.
IE показывает пустой экран, но внизу еле заметная кнопка "Allow blocked content", после нажатия на которую скрипт все таки запускается.
В EDGE даже этой кнопки нету.
S>>Сейчас JS позволяет работать с изолированной файловой системой. Позволяет сохранять файлы на диск в любое место а так же брать файлы с диска. Для многих приложений этого достаточно.
V>Нихрена JS не позволяет, не придумывай. У него таких встроенных ф-ий банально нет. Он работает с той функциональностью, которую ему экпортирует в виде видимого контекста некий JS-хост, например node.js.
V>Соответственно в браузере не может быть никакой функциональности у скрипта, кроме предоставляемой хостом-браузером.
А какой в этом смысл? Оффлайн можно писать много на чём. Твой вариант называется "хромиум", т.е. страничка оффлайн есть, но открывается не просто в браузере, а в встроенном хромиуме, помимо прочих ништяков ещё и про кросс-браузерность думать не надо. А так — лучше онлайн, и с обновлением проблем меньше и бабки с клиента снять куда проще.
Re[2]: Программы в сохраненной html-странице -- почему не развиты?
Сохраняете 1 файл, который оффлайн работает на всех известных платформах.
vsb>Твой вариант называется "хромиум", т.е. страничка оффлайн есть, но открывается не просто в браузере, а в встроенном хромиуме, помимо прочих ништяков ещё и про кросс-браузерность думать не надо. А так — лучше онлайн, и с обновлением проблем меньше и бабки с клиента снять куда проще.
Это не работает как 1 файл для всех платформ.
Притом хотелось бы знать что запускаешь и суметь модифицировать на ходу.
Re: Программы в сохраненной html-странице -- почему не развиты?
Особенно для этого подходят single page web applications.
Пару лет назад я архитектурил такое приложение. Оно работало в occasionally connected mode — данные были в localStorage + sync с сервером когда он был виден.
Т.е. просто статическая html страница в web + application manifest и не нужно никаких app stores и прочего — просто попросить юзера нажать на "Add to Home Screen"
Здравствуйте, Shmj, Вы писали:
V>>Путь надо указать как-то так: file:///D:/probe/1.html S>Проверял и не раз. Microsoft Edge 38.14393.0.0 с настройками по умолчанию -- показывает пустой экран.
Ну, может, в локальных политиках покрутить надо.
V>>Нихрена JS не позволяет, не придумывай. У него таких встроенных ф-ий банально нет. Он работает с той функциональностью, которую ему экпортирует в виде видимого контекста некий JS-хост, например node.js. V>>Соответственно в браузере не может быть никакой функциональности у скрипта, кроме предоставляемой хостом-браузером. S>Попробуйте этот сайт: https://app.keeweb.info/ S>Сохраните в виде 1 единственной HTML-странички и полноценно открывайте/сохраняйте файл keepass.
Оно сохраняет в облаке.
S>Во всех нормальных браузерах работает.
Ты не показал, как из скрипта на странице, открытой "нормальным браузером" что-то писать в произвольное место файловой системы.
Сохранил я твою страницу, открыл Лисой, при попытке создать файл твоя приложуха пишет:
"Этот файл хранится во внутренней памяти приложения, если хотите работать с локальными файлами, берите это:" https://github.com/keeweb/keeweb/releases/tag/v1.4.1
ЧТД.
Re[8]: Программы в сохраненной html-странице -- почему не развиты?
Здравствуйте, vdimas, Вы писали:
V>Ну, может, в локальных политиках покрутить надо.
До готовности довести напильником (с)
V>Оно сохраняет в облаке.
В хроме можно сохранять в файл и загружать из файла.
V>Сохранил я твою страницу, открыл Лисой, при попытке создать файл твоя приложуха пишет: V>"Этот файл хранится во внутренней памяти приложения, если хотите работать с локальными файлами, берите это:" V>https://github.com/keeweb/keeweb/releases/tag/v1.4.1 V>ЧТД.
Попробуйте в хроме.
Re[2]: Программы в сохраненной html-странице -- почему не развиты?
Здравствуйте, Shmj, Вы писали:
V>>Сохранил я твою страницу, открыл Лисой, при попытке создать файл твоя приложуха пишет: V>>"Этот файл хранится во внутренней памяти приложения, если хотите работать с локальными файлами, берите это:" V>>https://github.com/keeweb/keeweb/releases/tag/v1.4.1 V>>ЧТД. S>Попробуйте в хроме.
Хром открывает его исходник, как веб-страницу открыть отказался.
Re[9]: Программы в сохраненной html-странице -- почему не развиты?
Здравствуйте, Shmj, Вы писали:
S>Попробуйте в хроме.
Удалось открыть в Хроме.
При попытке открыть "сохранённый ранее" файл (через обычную загрузку с сайта), пишет:
Вы собираетесь открыть файл, который будет храниться внутри приложения. Изменения, внесенные не будут сохранены обратно в файловую систему. Чтобы получить файл с вашими данными, экспортируйте его из настроек.
Очередное ЧТД.
Re[3]: Программы в сохраненной html-странице -- почему не развиты?
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, c-smile, Вы писали:
CS>>Это ты просто не знаешь... CS>>На iOS например можно твой сайт сконфигурировать на работу в offline.
S>Я не знаю -- значит не распространено. Новости IT отслеживаю регулярно.
"Многие вещи нам непонятны не потому, что наши понятия слабы; но потому, что сии вещи не входят в круг наших понятий." (C) Козьма наш Прутков.
Re[10]: Программы в сохраненной html-странице -- почему не развиты?
V>Вы собираетесь открыть файл, который будет храниться внутри приложения. Изменения, внесенные не будут сохранены обратно в файловую систему. Чтобы получить файл с вашими данными, экспортируйте его из настроек.
V>Очередное ЧТД.
Так зайдите в настройки и там будет кнопка "Сохранить как". Все сохраняется.
Re: Программы в сохраненной html-странице -- почему не развиты?
Здравствуйте, Shmj, Вы писали:
S>Берем пишем прогу на JS внутри HTML-страницы. Сохраняем на диск на компьютере. Когда нужно -- запустили, все открылось. Все работает. Причем все работает и в Win и в Lin и в Mac OS. А еще ведь браузеры есть и во всех моб. телефонах (даже не самых современных), значит и там можно сделать чтобы работало.
S>Но почему такие приложения не распространены? Ну чтобы 100% все работало оффлайн.
Приделайте к такому приложению схему (1) деплоя, и автообновления до актуальной версии, (2) сбора статистики, (3) монетизации — получите типичный сайт.
Спрашивать, следовательно, надо: почему разработчикам нужны 1-2-3? Ответ, я думаю, вы и сами знаете...
P.S. Для себя такие программы пишу часто. Но для себя.
Re[7]: Программы в сохраненной html-странице -- почему не развиты?
Здравствуйте, Shmj, Вы писали:
V>>Проверь прямо сейчас: V>><html> V>><script> V>>alert('Hello!'); V>></script> V>></html> V>>Путь надо указать как-то так: file:///D:/probe/1.html
S>Проверял и не раз. Microsoft Edge 38.14393.0.0 с настройками по умолчанию -- показывает пустой экран.
IMHO, где-то в твои эксперименты закралась систематическая ошибка
Edge 38.14393.0.0 с настройками по умолчанию работает точно так же как и Chrome/Firefox в плане локального javascript (то есть, выполняет javascript из файла выше, и показывает alert). Даже "разблокировать" файл не обязательно.
Можешь попробовать например на чистой виртуалке, с только что установленной системой (Windows 10 или Server 2016, чтобы Edge из коробки)..
S>IE показывает пустой экран, но внизу еле заметная кнопка "Allow blocked content", после нажатия на которую скрипт все таки запускается.
Здравствуйте, 463C21E2, Вы писали:
CE>Приделайте к такому приложению схему (1) деплоя, и автообновления до актуальной версии, (2) сбора статистики, (3) монетизации — получите типичный сайт.
Для проги это не нужно.
CE>P.S. Для себя такие программы пишу часто. Но для себя.
Отож. Только для себя и то с ограничениями.
Re[8]: Программы в сохраненной html-странице -- почему не развиты?
Здравствуйте, bnk, Вы писали:
S>>Проверял и не раз. Microsoft Edge 38.14393.0.0 с настройками по умолчанию -- показывает пустой экран.
bnk>IMHO, где-то в твои эксперименты закралась систематическая ошибка bnk>Edge 38.14393.0.0 с настройками по умолчанию работает точно так же как и Chrome/Firefox в плане локального javascript (то есть, выполняет javascript из файла выше, и показывает alert). Даже "разблокировать" файл не обязательно. bnk>Можешь попробовать например на чистой виртуалке, с только что установленной системой (Windows 10 или Server 2016, чтобы Edge из коробки)..
Я как поставил Windows так им не разу и не пользовался, настройки не менял.
Кстати, а где там включить чтобы оно работало? Это же файл на диске, а не локальная зона...
Re[9]: Программы в сохраненной html-странице -- почему не ра
Здравствуйте, Shmj, Вы писали:
bnk>>Edge 38.14393.0.0 с настройками по умолчанию работает точно так же как и Chrome/Firefox в плане локального javascript (то есть, выполняет javascript из файла выше, и показывает alert). Даже "разблокировать" файл не обязательно. bnk>>Можешь попробовать например на чистой виртуалке, с только что установленной системой (Windows 10 или Server 2016, чтобы Edge из коробки)..
S>Я как поставил Windows так им не разу и не пользовался, настройки не менял. S>Кстати, а где там включить чтобы оно работало? Это же файл на диске, а не локальная зона...
Я, честно говоря, не знаю как сделать чтобы оно НЕ работало
Вроде у Edge вообще такого выключателя нету, то есть, AFAIK невозможно выключить javascript только для локальных файлов.
Здравствуйте, Shmj, Вы писали:
vsb>>А какой в этом смысл? Оффлайн можно писать много на чём.
S>Но как писать кроссплатформенно, один файл для всех платформ и не заставлять устанавливать лишние приблуды в систему?
Самый популярный вариант Qt, например. Про один файл и лишние приблуды это уже какие-то твои личные заморочки, юзерам на это пофиг, лишь бы инсталлер работал. Ну и кроме Qt есть куча других вариантов.
S>Вот пример полезной прожки: https://app.keeweb.info/
S>Сохраняете 1 файл, который оффлайн работает на всех известных платформах.
И как мне сохранить файл в iOS? У меня там даже понятия файла нет. Я вот 1Password пользуюсь. Нормальное native-приложение с плагинами для браузеров, и мыслей нет пользоваться сохранёнными страничками.
vsb>>Твой вариант называется "хромиум", т.е. страничка оффлайн есть, но открывается не просто в браузере, а в встроенном хромиуме, помимо прочих ништяков ещё и про кросс-браузерность думать не надо. А так — лучше онлайн, и с обновлением проблем меньше и бабки с клиента снять куда проще.
S>Это не работает как 1 файл для всех платформ.
Да зачем это надо-то?
S>Притом хотелось бы знать что запускаешь и суметь модифицировать на ходу.
Приложение с минимальной сложностью, ну пусть 100 000 строк кода будет иметь. И что ты про него будешь знать или уметь модифицировать? Да ничего. Такой же чёрный ящик.
Ещё раз. Приложения можно писать в HTML как один файл. Но это несёт с собой проблемы. Поддержка множества браузеров, в том числе старых (проблема типичная для любого сайта), в том числе у каждого браузера есть свои тараканы для запускаемых с жёсткого диска файлов. Убогие инструменты для разработки на JS. Невозможно избавиться от оформления браузера. Если все эти ограничения устраивают — пожалуйста. Я вижу единственный плюс — у браузера есть песочница, поэтому, вроде бы, такой файл ничего в системе натворить не сможет. Хотя надо ещё разбираться, какие у него там ограничения в каком браузере.
Re[4]: Программы в сохраненной html-странице -- почему не развиты?
Здравствуйте, vsb, Вы писали:
vsb>И как мне сохранить файл в iOS? У меня там даже понятия файла нет. Я вот 1Password пользуюсь. Нормальное native-приложение с плагинами для браузеров, и мыслей нет пользоваться сохранёнными страничками.
А вот в этом и проблема -- могли бы сделать, но не делают.
Вы можете открыть его в виде сайта, но в этом есть минусы. Вдруг сайт ломанут и начнут пароли воровать?
S>>Это не работает как 1 файл для всех платформ. vsb>Да зачем это надо-то?
Чтобы не плодить лишние сущности.
vsb>Приложение с минимальной сложностью, ну пусть 100 000 строк кода будет иметь. И что ты про него будешь знать или уметь модифицировать? Да ничего. Такой же чёрный ящик.
Бывают и маленькие приложения с понятным кодом. К примеру сделать менеджер паролей простейший, без усложнизама. Или вычислялку хешей.
Глянул код -- нету там воровства паролей, все чисто.
vsb>Поддержка множества браузеров, в том числе старых (проблема типичная для любого сайта),
Сейчас не стоит остро, так как даже IE начал соответствовать стандартам. На старые можно забить.
vsb>в том числе у каждого браузера есть свои тараканы для запускаемых с жёсткого диска файлов.
Есть LocalStorage у браузера.
vsb>Убогие инструменты для разработки на JS.
Не такие уж и убогие.
vsb>Невозможно избавиться от оформления браузера.
А вот это уже искусственно создали. Тот же hta открывался без строчки навигации.
vsb>Если все эти ограничения устраивают — пожалуйста. Я вижу единственный плюс — у браузера есть песочница, поэтому, вроде бы, такой файл ничего в системе натворить не сможет. Хотя надо ещё разбираться, какие у него там ограничения в каком браузере.
И песочница -- тоже большой плюс. Вам нужно переживать что прога сделает бяку. И эта песочница реально работает, в отличие от .Net с ограниченными правами запуска.
Но мне важно и то что открытый код можно сделать, править на ходу, один файл для всех платформ, не нужно устанавливать и т.д. и т.п. -- очень круто. Просто не развито.
Ведь не сложно было сделать типа hta для всех платформ.
Re[5]: Программы в сохраненной html-странице -- почему не развиты?
Здравствуйте, Shmj, Вы писали:
S>Ведь не сложно было сделать типа hta для всех платформ.
Обычно делают то, что решает проблемы пользователей. Например браузер для просмотра интернета. Если к этому можно удачно решить проблему программистов, хорошо. Например встроенные developer tools. Но специально для программистов систему делают разве что сами программисты (Linux), и то в свободное время с соответствующим качеством. Могли бы сделать hta для всех платформ, но пользователям эти плюсы (один файл, можно редактировать) не нужны, для них один файл это файл инсталлятора и ярлык после инсталляции, а редактировать они могут только свои вордовские документы. Ну возьмёт гугл, выделит из бюджета миллион долларов, на эти деньги выделят ресурсы в виде 2-3 человек на пару месяцев, реализуют концепт для твоего hta. Выделят ещё десять миллионов, огранизуют конференции, убедят другие браузеры реализовать это всё. Те лет через 5 может и зарелизят такую фичу. И всё ради чего — чтобы хеши считать? Несерьёзно это.
Я думаю, шансы на подобное есть, но это будет со стороны мобильников. Изначально на iOS приложения не очень хотели давать делать, и планировали заставить разработчиков как раз и писать эти приложения на .HTML, а пользователь будет сохранять закладку на рабочий стол. Потом оказалось, что первые айфоны были совсем уж слабенькие, браузер умел не так много, поэтому таким макаром полезные приложения сделать было практически нереально, в итоге пошла волна нативных приложений. В настоящий момент лучшие смартфоны по вычислительной мощи догнали средние ноутбуки. Веб технологии развились очень неплохо. Вполне может быть второй виток спирали, когда разработчики начнут массово делать приложения в виде закладки, а не в виде нативного кода. Будет спрос на такие технологии, будет развитие браузеров в эту сторону и в десктопные браузеры эти фичи тоже так или иначе проникнут. Может быть не в виде файлов (ну в самом деле, это несерьёзно, кто пользуется файлами в 2017 году), но в виде приложений, запускаемых по определённому URL — почему бы и нет.
Re[8]: Программы в сохраненной html-странице -- почему не развиты?
Здравствуйте, bnk, Вы писали:
S>>IE показывает пустой экран, но внизу еле заметная кнопка "Allow blocked content", после нажатия на которую скрипт все таки запускается. bnk>Чтобы в IE работало, используется Mark Of The Web
Прикольно!
Исправленная версия:
<!-- saved from url=(0016)http://localhost -->
<html>
<script>
alert('Hello!');
</script>
</html>
Re[2]: Программы в сохраненной html-странице -- почему не разви
Кому надо давно так делали.
Опять же, в отличие от, предоставить скрипту глобальные плюсовые ф-ии и объекты было проще простого, потому что через OLE Automation.
Это как два пальца об асфальт — описываешь публичный интерфейс такого класса в COM-IDL, дальше оно само всё делает, ты только наследуешь класс от интерфейса и реализуешь его методы.
...и посмотрел я как-то спецификации для связи нейтива и JS в v8...
Тонну г-на надо вымесить ручками для самых простейших случаев, вот что такое "интероперабельность" v8 с нейтивом.
Воистину, мыши плакали, кололись, но продолжали жрать кактус. ))
Re[3]: Программы в сохраненной html-странице -- почему не разви
Здесь небольшая разница это кроссплатформенный OLE Automation
А для TS несложно написать заголовочные файлы. И все тоже самое.
Там все равно затраты на протаскивание объектов из V8 в натив и обратно больше чем на рефлексию и обмен между нативом и манагед
и солнце б утром не вставало, когда бы не было меня
Re[4]: Программы в сохраненной html-странице -- почему не разви
Здравствуйте, Serginio1, Вы писали:
S>Здесь небольшая разница это кроссплатформенный OLE Automation
Это две VM, исполняющиеся в одном вшивом процессе мобильного телефона.
S>А для TS несложно написать заголовочные файлы. И все тоже самое. S>Там все равно затраты на протаскивание объектов из V8 в натив и обратно больше чем на рефлексию и обмен между нативом и манагед
Затраты на протаскивание объектов туда-сюда обычно происходят не чаще, чем кликанье по юзверьскому интерфейсу. Зато весь остальной код тогось... на JS...
А это мобильник, мать его. Я свою "новую" (на тот момент) мобилу отдал 4 года назад знакомой 13-тилетней девочке "на один день поносить" в обмен на её старый обшарпанный, коим и пользуюсь до сих пор с удовольствием. Бо заряжаю его ровно раз в неделю. А вся наша молодежь в семье со своими лопатофонами бегает к зарядке ежедневно, а то и чаще. ))
Для приложений на основе рендеринга HTML уже есть готовый кроссплатформенный движок, называется Хромиум. Движок модульный, к движку есть плагины, т.е. своё приложение можно собрать без избыточных зависимостей.
Еще есть движок XULRunner от Мозиллы для ровно того же.
Никакие VM скриптов хостить не нужно, там уже и так в XULRunner есть всё что надо.
В крайнем случае, если, таки нужен JS, то в XULRunner есть XPCOM — кроссплатформенный аналог COM.
Т.е. связь скрипта и нейтива в XULRunner на порядки проще, чем в Хромиуме.
Поэтому, если стояла задача работать со скриптами, и учитывая, что уже давно скрипты в Лисе еще и исполняются быстрее чем в Хроме, я ХЗ чем надо было думать, чтобы взять Хромиум за основу.
Это залёт, курсант.
Re[5]: Программы в сохраненной html-странице -- почему не разви
Здравствуйте, vdimas, Вы писали:
V>Для приложений на основе рендеринга HTML уже есть готовый кроссплатформенный движок, называется Хромиум. Движок модульный, к движку есть плагины, т.е. своё приложение можно собрать без избыточных зависимостей.
Так CEF это и есть Хромиум https://en.wikipedia.org/wiki/Chromium_Embedded_Framework
V>Поэтому, если стояла задача работать со скриптами, и учитывая, что уже давно скрипты в Лисе еще и исполняются быстрее чем в Хроме, я ХЗ чем надо было думать, чтобы взять Хромиум за основу. V>Это залёт, курсант.
Спасибо. Я уже я уже знаю твое мнение.
У меня задача стояла использование из TS методы и свойства в том числе и статического любого класса .Net Core.
А там библиотек уже болеее чем достаточно, и скоро выйдет NetStandard 2/
Смысл моего проекта это перевести WPF приложения на CEF под Линукс и яблоко. Как в этом может помочь XPCOM о мой генералисимус?
и солнце б утром не вставало, когда бы не было меня
Re[9]: Программы в сохраненной html-странице -- почему не развиты?
Здравствуйте, vdimas, Вы писали:
S>>>IE показывает пустой экран, но внизу еле заметная кнопка "Allow blocked content", после нажатия на которую скрипт все таки запускается. bnk>>Чтобы в IE работало, используется Mark Of The Web
V>Прикольно! V>Исправленная версия: V>
Здравствуйте, bnk, Вы писали:
bnk>Здравствуйте, vdimas, Вы писали:
S>>>>IE показывает пустой экран, но внизу еле заметная кнопка "Allow blocked content", после нажатия на которую скрипт все таки запускается. bnk>>>Чтобы в IE работало, используется Mark Of The Web
V>>Прикольно! V>>Исправленная версия: V>>
Здравствуйте, Serginio1, Вы писали:
V>>Для приложений на основе рендеринга HTML уже есть готовый кроссплатформенный движок, называется Хромиум. Движок модульный, к движку есть плагины, т.е. своё приложение можно собрать без избыточных зависимостей. S> Так CEF это и есть Хромиум https://en.wikipedia.org/wiki/Chromium_Embedded_Framework
Я про дотнетную твою обертку говорю:
Это две VM, исполняющиеся в одном вшивом процессе мобильного телефона.
Голосую за то, чтобы оставить одну VM.
Т.я. я бы сделал две сборки — в одной использовать JS в кач-ве "клея", во второй только лишь дотнет, т.е. без вообще какой бы то ни было JS-машинки. В крайнем случае можно взять JS-машинку под дотнет, т.е. хотя бы у них будет будет общая VM/GC и отсутствующий маршаллинг.
V>>Поэтому, если стояла задача работать со скриптами, и учитывая, что уже давно скрипты в Лисе еще и исполняются быстрее чем в Хроме, я ХЗ чем надо было думать, чтобы взять Хромиум за основу. S>У меня задача стояла использование из TS методы и свойства в том числе и статического любого класса .Net Core.
И?
Ты вопрос услышал?
S>А там библиотек уже болеее чем достаточно, и скоро выйдет NetStandard 2/
Отлично!
S>Смысл моего проекта это перевести WPF приложения на CEF под Линукс и яблоко. Как в этом может помочь XPCOM о мой генералисимус?
Еще раз, медленно, почему именно CEF (Хром) если есть более пригодный для таких дел XULRunner (Лиса)?
У последнего:
— JS-машинка работает быстрее, чем v8;
— связь JS-объектов с внешним миром требует в десятки (!!!) раз меньше трудозатрат (через XPCOM).
— В идеале тебе вообще JS-машинка становится не нужна в случае XULRunner, т.к. ты можешь биндить XPCOM-компоненты прямо к дотнетным объектам, минуя JS, т.е. ты можешь работать с DOM напрямую из дотнета.
В итоге у тебя получается возможность выбирать конфигурацию и кол-во VM, запускающихся в приложении.
Ты сейчас хоть осознал всю, такскаать, потерю потерь, которая у тебя случилась из-за выбора CEF вместо XULRunner?
Re[10]: Программы в сохраненной html-странице -- почему не развиты?
Здравствуйте, bnk, Вы писали:
bnk>Прикинь, они умудрились эту фишку в Edge сломать
Странно, у меня работает прекрасно в Edge и без этой строчки.
Но я локальные политики настраивал когда-то после установки 10-ки, в том числе что-то выставлял для скриптов, поэтому повторно предполагаю, что дело может быть в этом.
Re[7]: Программы в сохраненной html-странице -- почему не ра
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Serginio1, Вы писали:
V>>>Для приложений на основе рендеринга HTML уже есть готовый кроссплатформенный движок, называется Хромиум. Движок модульный, к движку есть плагины, т.е. своё приложение можно собрать без избыточных зависимостей. S>> Так CEF это и есть Хромиум https://en.wikipedia.org/wiki/Chromium_Embedded_Framework
V>Я про дотнетную твою обертку говорю: V>
V>Это две VM, исполняющиеся в одном вшивом процессе мобильного телефона.
V>Голосую за то, чтобы оставить одну VM. V>Т.я. я бы сделал две сборки — в одной использовать JS в кач-ве "клея", во второй только лишь дотнет, т.е. без вообще какой бы то ни было JS-машинки. В крайнем случае можно взять JS-машинку под дотнет, т.е. хотя бы у них будет будет общая VM/GC и отсутствующий маршаллинг.
CEF ставится только на десктоп. Причем здесь мобильные устройства? V>>>Поэтому, если стояла задача работать со скриптами, и учитывая, что уже давно скрипты в Лисе еще и исполняются быстрее чем в Хроме, я ХЗ чем надо было думать, чтобы взять Хромиум за основу. S>>У меня задача стояла использование из TS методы и свойства в том числе и статического любого класса .Net Core.
V>И? V>Ты вопрос услышал?
Причем тут срипты. Скорость .Net Core вполне достаточно.
S>>А там библиотек уже болеее чем достаточно, и скоро выйдет NetStandard 2/
V>Отлично!
S>>Смысл моего проекта это перевести WPF приложения на CEF под Линукс и яблоко. Как в этом может помочь XPCOM о мой генералисимус?
V>Еще раз, медленно, почему именно CEF (Хром) если есть более пригодный для таких дел XULRunner (Лиса)?
Потому, что мне его посоветовали и он мне показался удобным. V>У последнего: V>- JS-машинка работает быстрее, чем v8; V>- связь JS-объектов с внешним миром требует в десятки (!!!) раз меньше трудозатрат (через XPCOM). V>- В идеале тебе вообще JS-машинка становится не нужна в случае XULRunner, т.к. ты можешь биндить XPCOM-компоненты прямо к дотнетным объектам, минуя JS, т.е. ты можешь работать с DOM напрямую из дотнета.
Меня не интересует скорость. Меня интересует удобство в программировании. Мне пришлось программировать на 5 языках
1С,С++,С#,TS,JS. Ты же мне помочь не собирался.
V>В итоге у тебя получается возможность выбирать конфигурацию и кол-во VM, запускающихся в приложении.
V>Ты сейчас хоть осознал всю, такскаать, потерю потерь, которая у тебя случилась из-за выбора CEF вместо XULRunner?
Неа. Как мне XULRunner позволит вызвать произвольный манагед код JS?
На CEF у меня все прекрасно работает. Только это никому не нужно.
И это мало кому интересно и на XULRunner.
Если тебе интересно напиши свою обертку и сравни с моей.
WebExtensions становятся новым стандартом для создания надстроек. В конце концов поддержка надстроек XPCOM будет устаревшей, поэтому вам следует начать исследовать портирование своих дополнений, чтобы использовать API WebExtensions, и сообщите о любых недостающих функциях, чтобы мы могли быть уверены в ваших проблемах. Работа над возможностями WebExtension продолжается, поэтому ваш вклад поможет расставить приоритеты и спланировать работу. Дополнительные сведения о видах изменений, которые будут необходимы, см. В разделе Сравнение с расширениями XUL / XPCOM. Кроме того, любые двоичные файлы, которые вы используете, затем должны быть преобразованы для использования с API-интерфейсом обмена сообщениями WebExtensions или составлены с помощью WebAssembly или Emscripten.
Поддержку CEF никто вроде отменять не собирается.
Да и вообще проблема не в CEF или XPCOM, а в том, что я никто и звать меня никак.
Вот если бы ты как генералисимус написал на XCOM то все ринулись бы использовать твою обертку вместо Elrctron
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
V>>Голосую за то, чтобы оставить одну VM. V>>Т.я. я бы сделал две сборки — в одной использовать JS в кач-ве "клея", во второй только лишь дотнет, т.е. без вообще какой бы то ни было JS-машинки. В крайнем случае можно взять JS-машинку под дотнет, т.е. хотя бы у них будет будет общая VM/GC и отсутствующий маршаллинг. S>CEF ставится только на десктоп.
А планшет или нетбук на Windows RT уже не считаются?
S>Причем тут срипты. Скорость .Net Core вполне достаточно.
Т.е. ты обращаешься к DOM по типизированным нейтивным интефейсам? Или, таки, через запрос JS-объектов?
V>>Еще раз, медленно, почему именно CEF (Хром) если есть более пригодный для таких дел XULRunner (Лиса)? S>Потому, что мне его посоветовали и он мне показался удобным.
А полноценное сравнение проводил? ))
Тебя твой советчик серьезно так подставил, походу.
Знаешь, есть такие советчики, которые в глаза не видели ни первого, ни второго, но мнение имеют.
Надо было самому проверить.
S>Меня не интересует скорость. Меня интересует удобство в программировании.
Дык, под XULRunner удобней намного.
Тебе же в случае Хрома надо каждый метод АПИ ручками маршаллить... Это же застрелиться. ))
S>Мне пришлось программировать на 5 языках S>1С,С++,С#,TS,JS. Ты же мне помочь не собирался.
Далее среди предоставляемых интерфейсов найди какой-нить evaluator и пихай в него свой JS и подавай свои аргументы.
Но когда ты набредешь на WEB IDL-компилятор там же, который сам делает тебе интерфейсы C#...
Вот тогда ты увидишь разницу при отсутствии ср-в автоматизации рутинной работы и при её наличии.
Там трудоёмкости в десятки раз отличаются, повторюсь.
И поле для ошибок тупо отсутствует.
S>На CEF у меня все прекрасно работает. Только это никому не нужно. S>И это мало кому интересно и на XULRunner.
Наоборот, на XULRunner очень популярно делать приложухи.
Поэтому есть хорошо отлаженные обертки.
Просто поставь nuget geckofx45.
Уже несколько лет принято кидать в дотнете на форму не WebControl на основе IE, а GeckoWebBrowser.
Для WPF тоже всё хорошо.
S>Если тебе интересно напиши свою обертку и сравни с моей.
Еще одну написать? ))
Есть ссылка на проект, там есть кучи тестов, вот как раз по тестам можно судить, что там да как.
S>WebExtensions становятся новым стандартом для создания надстроек. В конце концов поддержка надстроек XPCOM будет устаревшей, поэтому вам следует начать исследовать портирование своих дополнений, чтобы использовать API WebExtensions, и сообщите о любых недостающих функциях, чтобы мы могли быть уверены в ваших проблемах. Работа над возможностями WebExtension продолжается, поэтому ваш вклад поможет расставить приоритеты и спланировать работу. Дополнительные сведения о видах изменений, которые будут необходимы, см. В разделе Сравнение с расширениями XUL / XPCOM. Кроме того, любые двоичные файлы, которые вы используете, затем должны быть преобразованы для использования с API-интерфейсом обмена сообщениями WebExtensions или составлены с помощью WebAssembly или Emscripten.
Ох, мать ))
API WebExtensions — это АПИ расширения браузера, как законченного продукта.
А так-то Лиса как была построена на XPCOM, так и будет, просто не будет возможности загрузить бинарные плагины в Лису.
Но ты-то в своём приложении делай что хошь. И точно так же ты можешь предоставить какую-нить возможность расширения СВОЕГО конечного приложения. Например, тоже через API WebExtensions, ы-ы-ы.
S>Поддержку CEF никто вроде отменять не собирается.
Наоборот, Хром раньше Лисы избавляется от старых интерфейсов.
Просто ты путаешь браузеры Хром и Лису с библиотеками, на которых они построены.
S>Да и вообще проблема не в CEF или XPCOM, а в том, что я никто и звать меня никак. S>Вот если бы ты как генералисимус написал на XCOM то все ринулись бы использовать твою обертку вместо Elrctron
Electron — это куча мусора в одном месте.
Он родился как побочный продукт от редактора Atom в те далекие года, когда v8 была самымой быстрой VM — где-то в 2011-м.
С тех многое изменилось, v8 сливает двум основным конкурентам, поэтому смысла в Electron никакого.
Более того. У XUL есть ОЧЕНЬ интересный момент — его философия. Туда стоит копнуть.
Это расширяемый язык описания GUI.
Например, ты можешь разработать довольно-таки сложный составной контрол сугубо как композицию из имеющихся...
А потом, когда дойдут руки, сделать его "встроенным", т.е. не указывать композицию в исходном коде.
И вот именно легкость перевода первого во второе — это бомба сама по себе.
Вот такие вещи, кста, являются драйверами самомотивации, бо банально интересны.
А интересны потому, что дают серьезный выхлоп малыми усилиями.
А потому что архитектура была продумана на отлично, что бывает не часто, но когда такое видишь — испытываешь приятные эмоции.
А из Электрона тебе в реальности не будет нужно и 10-й его части в конечном приложении, но десяток с лишним метров исполняемый файл получи и распишись. Да еще в рантайм тормозит на не самых сильных компах.
Грустно.
Re[9]: Программы в сохраненной html-странице -- почему не ра
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Serginio1, Вы писали:
V>>>Голосую за то, чтобы оставить одну VM. V>>>Т.я. я бы сделал две сборки — в одной использовать JS в кач-ве "клея", во второй только лишь дотнет, т.е. без вообще какой бы то ни было JS-машинки. В крайнем случае можно взять JS-машинку под дотнет, т.е. хотя бы у них будет будет общая VM/GC и отсутствующий маршаллинг. S>>CEF ставится только на десктоп.
V>Мде? V>https://chromium.googlesource.com/chromium/src.git/+/master/ios/ V>https://chromium.googlesource.com/chromium/src.git/+/master/android_webview/
CEF и хромиум не совсем одно и то же http://opensource.spotify.com/cefbuilds/index.html S>>Причем здесь мобильные устройства?
V>А планшет или нетбук на Windows RT уже не считаются?
Нет. Там пока нет Net Core.
S>>Причем тут срипты. Скорость .Net Core вполне достаточно.
V>Т.е. ты обращаешься к DOM по типизированным нейтивным интефейсам? Или, таки, через запрос JS-объектов?
Я не обращаюсь к DOM из Net. Я из TS используюю библиотеки .Net Core V>>>Еще раз, медленно, почему именно CEF (Хром) если есть более пригодный для таких дел XULRunner (Лиса)? S>>Потому, что мне его посоветовали и он мне показался удобным.
V>А полноценное сравнение проводил? )) V>Тебя твой советчик серьезно так подставил, походу. V>Знаешь, есть такие советчики, которые в глаза не видели ни первого, ни второго, но мнение имеют. V>Надо было самому проверить.
Меня CEF вполне устраивает.
S>>Меня не интересует скорость. Меня интересует удобство в программировании.
V>Дык, под XULRunner удобней намного. V>Тебе же в случае Хрома надо каждый метод АПИ ручками маршаллить... Это же застрелиться. ))
Ты хоть проект то смотрел? Или опять не читал, но осуждаю.
Там всего несколько методов аналог IDispatch? только расширенный для использования асинхронных методов, событий, дженерик методов, итераторов.
Так CEF там все элементарно. У меня была использование в TS код .Net Core. Я её сделал.
Там все элементарно. При этом на стороне JS используется Proxy через который оборачиваются все вызовы и синтаксис максимально приближени к C#, за мелкими осключениями.
Задача решена. На чем не важно. Тебе шашечки или ехать.
Ты проект то смотрел? Или хоть статью то прочитал?
и солнце б утром не вставало, когда бы не было меня
Re[10]: Программы в сохраненной html-странице -- почему не ра
Здравствуйте, Serginio1, Вы писали:
S>Я не обращаюсь к DOM из Net. Я из TS используюю библиотеки .Net Core
Тогда зачем TS? Почему сразу не на дотнете?
V>>А полноценное сравнение проводил? )) V>>Тебя твой советчик серьезно так подставил, походу. V>>Знаешь, есть такие советчики, которые в глаза не видели ни первого, ни второго, но мнение имеют. V>>Надо было самому проверить.
S> Понимаешь ли я задавал вопросы S>Использование в TypeScript классов .Net S>http://rsdn.org/forum/web/6664070.flat
И вот зачём опять врать?
Там никаких вопросов ни по одной из ссылок, ты там лишь сообщал о том, что делаешь нечто на CEF.
S>Меня CEF вполне устраивает.
Судя по задаваемым тобой вопросам, тебе это обошлось в некоторую нехилую трудоёмкость.
А это залет. Я уже говорил.
Это ошибка проектирования.
Вызов из TS библиотек .Net через Gecko, во-первых прост как три копейки, во вторых уже есть готовый.
S>>>Меня не интересует скорость. Меня интересует удобство в программировании. V>>Дык, под XULRunner удобней намного. V>>Тебе же в случае Хрома надо каждый метод АПИ ручками маршаллить... Это же застрелиться. )) S>Ты хоть проект то смотрел? Или опять не читал, но осуждаю. S>Там всего несколько методов аналог IDispatch
Через рефлексию заполняешь? ))
Тю, блин, я бы через Web ILD интерфейсы для JS делал, чтобы дотнетовскую рефлексию в рантайм не дергать.
S> Так CEF там все элементарно. У меня была использование в TS код .Net Core. Я её сделал. S>Там все элементарно. При этом на стороне JS используется Proxy через который оборачиваются все вызовы и синтаксис максимально приближени к C#, за мелкими осключениями. S>Задача решена. На чем не важно. Тебе шашечки или ехать.
Мне ехать, конечно, но тебе, похоже, надо было поиграть в собственные шашечки. ))
S>Ты проект то смотрел? Или хоть статью то прочитал?
Ты предлагаешь мне погрузиться в твои исходники? ))
А в двух словах нельзя было пояснить, например, как ты реализуешь свой аналог IDispatch?
Пока что из куцых обрывков информации и из вот этих строк на SO:
var sb = System.Text.StringBuilder.New(args);
var list = System.List[System.Int32].New(args);
Ну или так:
var StringBuilder = System.Text.StringBuilder;
var IntList = System.List[System.Int32];
...
var sb = StringBuilder.New(args);
var list = IntList.New(args);
Или так:
var StringBuilder = System.Text.StringBuilder.New;
var IntList = System.List[System.Int32].New;
...
var sb = new StringBuilder(args);
var list = new IntList(args);
А можно просто всю сборку сделать видимой со стороны хоста:
Такая операция пусть добавляет лишь неймспейсы самого первого уровня, а остальные неймспейсы можно получать в ленивой манере, бо у нас достоверно однопоточность.
========
Просто я сам не раз хостил JS в дотнетных приложухах, испробовал различные способы.
Никогда более получаса на сам механизм хостинга не тратил, ес-но, а у тебя целый проект получился. ))
Да еще выхлоп неполноценный.
Тут ведь цель какая — дать возможность со стороны скрипта работать с конструкторами типов, с объектами и глобальными экспортируемыми в контекст исполнения ф-иями в более-менее естественной для скрипта манере. А у тебя вот это выглядит чужеродно:
let ApiExtensions = СборкаAngleSharp.GetType("AngleSharp.Extensions.ApiExtensions");
А вот эти строки вообще лишние:
let Net = NetObject.NetWrapper;
let $$ = NetObject.FlagDeleteObject;
Весь необходимый контекст можно было выставить до запуска скрипта.
А когда мне потребовалась эффективность запуска (хотел избежать рефлексии), то я не поленился для нужных объектов нарисовать интерфейс и реализовать его на дотнете. Так скрипт начинает полезную работу раньше, без притормаживания в начале своей работы.
Re[11]: Программы в сохраненной html-странице -- почему не р
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Serginio1, Вы писали:
S>>Я не обращаюсь к DOM из Net. Я из TS используюю библиотеки .Net Core
V>Тогда зачем TS? Почему сразу не на дотнете?
V>>>А полноценное сравнение проводил? )) V>>>Тебя твой советчик серьезно так подставил, походу. V>>>Знаешь, есть такие советчики, которые в глаза не видели ни первого, ни второго, но мнение имеют. V>>>Надо было самому проверить.
S>> Понимаешь ли я задавал вопросы S>>Использование в TypeScript классов .Net S>>http://rsdn.org/forum/web/6664070.flat
V>И вот зачём опять врать? V>Там никаких вопросов ни по одной из ссылок, ты там лишь сообщал о том, что делаешь нечто на CEF.
В первом сообщении про CEF вообще не было и речи. Я хотел использовать PNaCl/
Но скорость вызова с прокси порядка 45 000 вызовов в секунду.
Это выше чем по Tcp/Ip в 3 раза без прокси.
TCP/IP скорость обмена
Есть идея вызвать через Native Client Messaging System
Буду рад любым советам. И может это никому и не нужно и не стоит вообще писать в стол?
S>>Меня CEF вполне устраивает.
V>Судя по задаваемым тобой вопросам, тебе это обошлось в некоторую нехилую трудоёмкость. V>А это залет. Я уже говорил. V>Это ошибка проектирования. V>Вызов из TS библиотек .Net через Gecko, во-первых прост как три копейки, во вторых уже есть готовый.
Кроссплатформенный .Net Core?
S>>Ты хоть проект то смотрел? Или опять не читал, но осуждаю. S>>Там всего несколько методов аналог IDispatch
V>Через рефлексию заполняешь? )) V>Тю, блин, я бы через Web ILD интерфейсы для JS делал, чтобы дотнетовскую рефлексию в рантайм не дергать.
То есть не читал. То, что ты делал то ты молодец.
S>> Так CEF там все элементарно. У меня была использование в TS код .Net Core. Я её сделал. S>>Там все элементарно. При этом на стороне JS используется Proxy через который оборачиваются все вызовы и синтаксис максимально приближени к C#, за мелкими осключениями. S>>Задача решена. На чем не важно. Тебе шашечки или ехать.
V>Мне ехать, конечно, но тебе, похоже, надо было поиграть в собственные шашечки. ))
S>>Ты проект то смотрел? Или хоть статью то прочитал?
V>Ты предлагаешь мне погрузиться в твои исходники? )) V>А в двух словах нельзя было пояснить, например, как ты реализуешь свой аналог IDispatch? V>Пока что из куцых обрывков информации и из вот этих строк на SO: V>
V>Мне становится просто страшно. ))
V>Кароч, обычно с JS-хостом общаются не так. V>В него устанавливают т.н. "контекст", т.е. набор видимых переменных и ф-ий.
V>Весь необходимый контекст можно было выставить до запуска скрипта.
Это универсальная библиотека. Можно создавать типы заранее. Это не суть.
V>А когда мне потребовалась эффективность запуска (хотел избежать рефлексии), то я не поленился для нужных объектов нарисовать интерфейс и реализовать его на дотнете. Так скрипт начинает полезную работу раньше, без притормаживания в начале своей работы.
Это лишняя работа. Проще для TS сгенерить заголовочные файлы.
Но опять же. Это никому не нужно.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, bnk, Вы писали:
bnk>>Прикинь, они умудрились эту фишку в Edge сломать
V>Странно, у меня работает прекрасно в Edge и без этой строчки. V>Но я локальные политики настраивал когда-то после установки 10-ки, в том числе что-то выставлял для скриптов, поэтому повторно предполагаю, что дело может быть в этом.
Именно, Edge работает без этой строчки. А если эту строчку добавить — сломается (детали по ссылке выше). А IE — наоборот
Re[11]: Программы в сохраненной html-странице -- почему не развиты?
Ну мы же не совсем об этом. Мы говорим о случае, когда есть только обычный браузер, и ничего больше (ни CEF, ни NODE, ни .NET CORE)
То есть, правильно проверять так — открыть папку в экплорере, и дабл-кликнуть на файле index.html. По-прежнему работает?
Re[8]: Программы в сохраненной html-странице -- почему не развиты?
Здравствуйте, bnk, Вы писали:
bnk>Можешь попробовать например на чистой виртуалке, с только что установленной системой (Windows 10 или Server 2016, чтобы Edge из коробки)..
В Server нет Edge.
kalsarikännit
Re[9]: Программы в сохраненной html-странице -- почему не развиты?
Здравствуйте, IID, Вы писали:
IID>Здравствуйте, bnk, Вы писали:
bnk>>Можешь попробовать например на чистой виртуалке, с только что установленной системой (Windows 10 или Server 2016, чтобы Edge из коробки)..
IID>В Server нет Edge.
Упс. Значит только Windows 10.
Re[12]: Программы в сохраненной html-странице -- почему не развиты?
Здравствуйте, Shmj, Вы писали:
S>Так его же еще устанавливать нужно. А браузер у всех уже установлен.
Интерпретатор lua даже в микроконтроллеры умещается
Здравствуйте, Serginio1, Вы писали:
V>>А когда мне потребовалась эффективность запуска (хотел избежать рефлексии), то я не поленился для нужных объектов нарисовать интерфейс и реализовать его на дотнете. Так скрипт начинает полезную работу раньше, без притормаживания в начале своей работы. S>Это лишняя работа.
Это не лишняя работа, а целевая.
S>Проще для TS сгенерить заголовочные файлы.
Это ничего не даст в плане времени начала полезной работы скрипта.
S>Но опять же. Это никому не нужно.
Странный ты. А зачем делал?
Значит, всё-таки просто поиграться?
Ну так бы сразу и сказал, я бы не делал серьёзную мину, даже похвалил бы за творческий порыв, такскать. ))
===============
Я использовал в разное время разные скриптовые машинки именно потому, что это было нужно для конкретной задачи.
Понимаешь, твой подход — дать скрипту доступ "вообще ко всему дотнету" — он заведомо ущебный.
Весь дотнет удобней дергать из самого дотнета.
Когда я пользую скрипт, то я экспортирую в него только нужные ф-ии/объекты.
Нужные для конкретной решаемой задачи.
А раз таких экпортируемых в скрипт со стороны хоста сущностей получается вполне счётное кол-во, то мне вовсе не трудно описать эту сущности в виде отдельного IDL, благо одновремено с описанием оно является спецификацией.
И да, из Web IDL можно породить и твой TS.
Re[13]: Программы в сохраненной html-странице -- почему не р
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Serginio1, Вы писали:
V>>>А когда мне потребовалась эффективность запуска (хотел избежать рефлексии), то я не поленился для нужных объектов нарисовать интерфейс и реализовать его на дотнете. Так скрипт начинает полезную работу раньше, без притормаживания в начале своей работы. S>>Это лишняя работа.
V>Это не лишняя работа, а целевая.
Угу вместо того, что бы сразу использовать Net код, нужно писать еще и обертку.
S>>Проще для TS сгенерить заголовочные файлы.
V>Это ничего не даст в плане времени начала полезной работы скрипта.
Это даст в плане более быстрого и безопасногго написания кода. S>>Но опять же. Это никому не нужно.
V>Странный ты. А зачем делал? V>Значит, всё-таки просто поиграться? V>Ну так бы сразу и сказал, я бы не делал серьёзную мину, даже похвалил бы за творческий порыв, такскать. ))
Я хотел использовать свои наработки на которые ушли годы.
Проблема в том, что Линукм и эпл никому не нужны. Или нужны продукты от продвинутых фирм. А так я никто и звать меня никак. Я и работу найти не могу.
V>=============== V>Я использовал в разное время разные скриптовые машинки именно потому, что это было нужно для конкретной задачи. V>Понимаешь, твой подход — дать скрипту доступ "вообще ко всему дотнету" — он заведомо ущебный. V>Весь дотнет удобней дергать из самого дотнета. V>Когда я пользую скрипт, то я экспортирую в него только нужные ф-ии/объекты. V>Нужные для конкретной решаемой задачи.
И делаешь лишнюю работу. И здесь ты используешь не весь .Net? а только нужные сборки и классы
V>А раз таких экпортируемых в скрипт со стороны хоста сущностей получается вполне счётное кол-во, то мне вовсе не трудно описать эту сущности в виде отдельного IDL, благо одновремено с описанием оно является спецификацией.
V>И да, из Web IDL можно породить и твой TS.
Еще раз в моем подходе можно прямо из TS использовать .Net классы.
А что касается "дотнет удобней дергать из самого дотнета", то опять ты не читаешь. Для Линукса и Яблока нет аналога WPF.
Моя разработка помогает перенести приложения под WPF на Линукс и яблоко.
и солнце б утром не вставало, когда бы не было меня
Re[12]: Программы в сохраненной html-странице -- почему не развиты?
Здравствуйте, bnk, Вы писали:
bnk>Здравствуйте, Serginio1, Вы писали:
S>> Не знаю я вот CEF, ES6, Angular 2, WebPack 2 .Net Core десктопное приложение без серверной части S>>Специально создал 3 js файла в котрый упакованы шаблоны код и лежат рядом в папке scripts
S>> <app>Загрузка...</app> S>> Прекрасно открывается в Edge
bnk>Ну мы же не совсем об этом. Мы говорим о случае, когда есть только обычный браузер, и ничего больше (ни CEF, ни NODE, ни .NET CORE) bnk>То есть, правильно проверять так — открыть папку в экплорере, и дабл-кликнуть на файле index.html. По-прежнему работает?
Я был забанен. Но мое сообщение не касается CEF и Node. Оно касалось Edge.
А из Edge нельзя вызвать .Net Core.
Но страница загружаются, а вызвать .Net Core нельзя.
Но проблема в примере скорее всего касается вызова через ./
То есть вместо
<script src="foo.js" ></script>
Нужно исправить
<script src="./foo.js" ></script>
А то он начинает искать в корне директории
А вот, что касается <!-- saved from url=(0014)about:internet -->
То её же можно и удалить?
и солнце б утром не вставало, когда бы не было меня
Re[14]: Программы в сохраненной html-странице -- почему не р
Здравствуйте, Serginio1, Вы писали:
V>>Это не лишняя работа, а целевая. S>Угу вместо того, что бы сразу использовать Net код, нужно писать еще и обертку.
Потому что демагогию включаешь. Я уже на это писал:
твой подход — дать скрипту доступ "вообще ко всему дотнету" — он заведомо ущебный.
Весь дотнет удобней дергать из самого дотнета.
Когда я пользую скрипт, то я экспортирую в него только нужные ф-ии/объекты.
Нужные для конкретной решаемой задачи.
S>>>Проще для TS сгенерить заголовочные файлы. V>>Это ничего не даст в плане времени начала полезной работы скрипта. S>Это даст в плане более быстрого и безопасногго написания кода.
Еще раз, медленно. Намного быстрее под "весь дотнет" писать на самом дотнете.
Остальное — ущербно. Является инженерной ошибкой.
В скрипт надо отдавать только то, что невозможно или нецелесообразно, согласно конкретной задачи, делать на самом дотнете.
V>>Значит, всё-таки просто поиграться? V>>Ну так бы сразу и сказал, я бы не делал серьёзную мину, даже похвалил бы за творческий порыв, такскать. )) S>Я хотел использовать свои наработки на которые ушли годы.
Любые наработки из JS можно примерно со световой скоростью портировать на C#.
Попутно исправляя живущие в JS-версии колонии багов. ))
S>Проблема в том, что Линукм и эпл никому не нужны. Или нужны продукты от продвинутых фирм. А так я никто и звать меня никак. Я и работу найти не могу.
Для 1С-ников работы завались.
Для JS-кодеров и PHP — тоже.
В других областях надо быть в какой-то мере профи, сорри, чтобы быть востребованным.
А чтобы стать профи, нужен некий алгоритм накопления знаний и чертовски циничный подход к принятию инженерных решений.
У тебя отсутствует тот самый здравый цинизм, сорри.
Я вижу того самого "увлечённого молодого человека", которым не зазорно быть в ВУЗ-е, ну максимум первые пару лет после.
Ну и всё. А потом пора уже и по-взрослому. ))
S>А что касается "дотнет удобней дергать из самого дотнета", то опять ты не читаешь. Для Линукса и Яблока нет аналога WPF.
Есть. Называет XULRunner.
Не один в один, но близкая по смыслу технология.
S>Моя разработка помогает перенести приложения под WPF на Линукс и яблоко.
И как же оно поможет, если самого WPF там нет? ))
Если опять включить цинизм и быть честным с самим собой, то либы Хромиум НЕ предоставляют такого же уровня абстрагирования описания GUI от низлежащих подробностей, как это происходит в XUL или WPF. Потому что Хромиум был построен на сугубо HTML-движке эппловского WebKit, где всё прибито наглухо гвоздями к конечной цели отображения HTML.
И напротив, XUL был писан как универсальная GUI-платформа, где реализация HTML-рендеринга на ней — лишь одно из частных применений платформы.
Собсно, если бы внимательней посмотрел на устройство твоей либы Электрон, ты бы увидел, что это лишь болезненная и жутко неэффективная попытка сделать из Хромиума подобие XUL. Многократное Ы-Ы-Ы, как грится. ))
Re[15]: Программы в сохраненной html-странице -- почему не р
V>Еще раз, медленно. Намного быстрее под "весь дотнет" писать на самом дотнете. V>Остальное — ущербно. Является инженерной ошибкой. V>В скрипт надо отдавать только то, что невозможно или нецелесообразно, согласно конкретной задачи, делать на самом дотнете.
Не читаешь ты. Нет под линукс и эпл аналога WPF
V>>>Значит, всё-таки просто поиграться? V>>>Ну так бы сразу и сказал, я бы не делал серьёзную мину, даже похвалил бы за творческий порыв, такскать. )) S>>Я хотел использовать свои наработки на которые ушли годы.
V>Любые наработки из JS можно примерно со световой скоростью портировать на C#. V>Попутно исправляя живущие в JS-версии колонии багов. ))
А при чем из из JS на C#?
S>>Проблема в том, что Линукм и эпл никому не нужны. Или нужны продукты от продвинутых фирм. А так я никто и звать меня никак. Я и работу найти не могу.
V>Для 1С-ников работы завались. V>Для JS-кодеров и PHP — тоже. V>В других областях надо быть в какой-то мере профи, сорри, чтобы быть востребованным.
Ну конечно профи у нас только ты. Покажи кстати свои статьи.
V>А чтобы стать профи, нужен некий алгоритм накопления знаний и чертовски циничный подход к принятию инженерных решений. V>У тебя отсутствует тот самый здравый цинизм, сорри. V>Я вижу того самого "увлечённого молодого человека", которым не зазорно быть в ВУЗ-е, ну максимум первые пару лет после. V>Ну и всё. А потом пора уже и по-взрослому. ))
Ну мне 53 годика. Еще молод.
S>>А что касается "дотнет удобней дергать из самого дотнета", то опять ты не читаешь. Для Линукса и Яблока нет аналога WPF.
V>Есть. Называет XULRunner. V>Не один в один, но близкая по смыслу технология.
Где на линуксе WPF?
S>>Моя разработка помогает перенести приложения под WPF на Линукс и яблоко.
V>И как же оно поможет, если самого WPF там нет? ))
Есть Angular 2? который очень близок к WPF, а .Net код используется из JS.
вообще читаешь?
V>Если опять включить цинизм и быть честным с самим собой, то либы Хромиум НЕ предоставляют такого же уровня абстрагирования описания GUI от низлежащих подробностей, как это происходит в XUL или WPF. Потому что Хромиум был построен на сугубо HTML-движке эппловского WebKit, где всё прибито наглухо гвоздями к конечной цели отображения HTML.
Ты Angular 2 пробовал? V>И напротив, XUL был писан как универсальная GUI-платформа, где реализация HTML-рендеринга на ней — лишь одно из частных применений платформы.
V>Собсно, если бы внимательней посмотрел на устройство твоей либы Электрон, ты бы увидел, что это лишь болезненная и жутко неэффективная попытка сделать из Хромиума подобие XUL. Многократное Ы-Ы-Ы, как грится. ))
Электрон и моя разработка похожи, но они разные. У меня для расширения используются библиотеки .Net Core
И кстати эти электроном пользуется куча народа. Это к тому, что я никто и звать меня никак
и солнце б утром не вставало, когда бы не было меня
Re[13]: Программы в сохраненной html-странице -- почему не развиты?
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, bnk, Вы писали:
S> А вот, что касается <!-- saved from url=(0014)about:internet --> S>То её же можно и удалить?
Так в ней баг и состоит. В ссылке подробно расписано
Если её удалить, то все работает.
Re[16]: Программы в сохраненной html-странице -- почему не р
Здравствуйте, Serginio1, Вы писали:
V>>Еще раз, медленно. Намного быстрее под "весь дотнет" писать на самом дотнете. V>>Остальное — ущербно. Является инженерной ошибкой. V>>В скрипт надо отдавать только то, что невозможно или нецелесообразно, согласно конкретной задачи, делать на самом дотнете. S> Не читаешь ты. Нет под линукс и эпл аналога WPF
Это ты не читаешь. Есть XUL.
V>>Если опять включить цинизм и быть честным с самим собой, то либы Хромиум НЕ предоставляют такого же уровня абстрагирования описания GUI от низлежащих подробностей, как это происходит в XUL или WPF. Потому что Хромиум был построен на сугубо HTML-движке эппловского WebKit, где всё прибито наглухо гвоздями к конечной цели отображения HTML. S>Ты Angular 2 пробовал?
Пробовал. Это аналог PHP с тем отличием, что генерация страниц по шаблону реализована на JS, т.е. возможна так же на клиентской стороне, что и делается. Хотя, и на серверной стороне тоже можно генерить через Angular страницы, ес-но, просто никто в здравом уме не будет использовать шаблонный рендеринг на основе JS. Тут банальный нейтивный PHP-рендерер порвет JS как тузик грелку. ))
Тем более, что готовых классных GUI-шаблонов для PHP в Сети всяко больше, чем для Angular, я бы так оценил что больше на пару порядков...
А если речь про использование готового .Net-кода, то можно взять кроссплатформенный рендерер от ASP.Net: https://www.asp.net/core
и запускать его в своём дотнетном приложении — я так делал пару раз (тогда еще не было никакого Core, юзал от обычного дотнета).
Это тоже будет на порядки быстрее, чем любой JS-рендеринг по шаблону. Да это будет даже не сравнимо, бо можно заставить его скомпиллировать страницы в процессе билда приложения. )) А если еще и Net Native сверху скомпиллированных страниц натравить, то это будет совсем мега-фича, в сравнении той фигнёй, которой ты маешься (положа руку на).
А вот при чем тут твой WPF и Angular — это я ХЗ, это у тебя в голове какая-то каша.
S>Электрон и моя разработка похожи, но они разные. У меня для расширения используются библиотеки .Net Core
Причем, я уверен, что тонны технических моментов обыграны в GeckoFX всяко с большей тщательностью — это серьезная разработка.
Поэтому, я и говорю, что у тебя получилось "поиграться для себя".
S>И кстати эти электроном пользуется куча народа.
Я уже и на это тебе отвечал — когда начинали Электрон, то JS от Гугла показывал намного большее быстродействие, чем JS от Мозилы, т.е. на многое ТОГДА закрывали глаза. СЕЙЧАС такого преимущества гугловской v8 уже нет, поэтому можно перестать закрывать глаза на врождённые недостатки архитектуры Хромиума.
Re[17]: Программы в сохраненной html-странице -- почему не р
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Serginio1, Вы писали:
V>>>Еще раз, медленно. Намного быстрее под "весь дотнет" писать на самом дотнете. V>>>Остальное — ущербно. Является инженерной ошибкой. V>>>В скрипт надо отдавать только то, что невозможно или нецелесообразно, согласно конкретной задачи, делать на самом дотнете. S>> Не читаешь ты. Нет под линукс и эпл аналога WPF
V>Это ты не читаешь. Есть XUL.
Ссылочку плиз. Я знаю Авалонию https://github.com/AvaloniaUI/Avalonia но она в альфе V>>>Если опять включить цинизм и быть честным с самим собой, то либы Хромиум НЕ предоставляют такого же уровня абстрагирования описания GUI от низлежащих подробностей, как это происходит в XUL или WPF. Потому что Хромиум был построен на сугубо HTML-движке эппловского WebKit, где всё прибито наглухо гвоздями к конечной цели отображения HTML. S>>Ты Angular 2 пробовал?
V>Пробовал. Это аналог PHP с тем отличием, что генерация страниц по шаблону реализована на JS, т.е. возможна так же на клиентской стороне, что и делается. Хотя, и на серверной стороне тоже можно генерить через Angular страницы, ес-но, просто никто в здравом уме не будет использовать шаблонный рендеринг на основе JS. Тут банальный нейтивный PHP-рендерер порвет JS как тузик грелку. ))
Да уж. Razor рвет твой PHP как тузик грелку. Но ты все мыслишь технологиями 15 летней давности. Проснись!
V>Почему бы не взять в своё клиентское приложение какой-нить шустрый PHP-рендерер и не юзать его? V>Их полно на выбор: V>http://www.sitecrafting.com/blog/top-5-php-template-engines/
V>Тем более, что готовых классных GUI-шаблонов для PHP в Сети всяко больше, чем для Angular, я бы так оценил что больше на пару порядков...
V>А если речь про использование готового .Net-кода, то можно взять кроссплатформенный рендерер от ASP.Net: V>https://www.asp.net/core V>и запускать его в своём дотнетном приложении — я так делал пару раз (тогда еще не было никакого Core, юзал от обычного дотнета). V>Это тоже будет на порядки быстрее, чем любой JS-рендеринг по шаблону. Да это будет даже не сравнимо, бо можно заставить его скомпиллировать страницы в процессе билда приложения. )) А если еще и Net Native сверху скомпиллированных страниц натравить, то это будет совсем мега-фича, в сравнении той фигнёй, которой ты маешься (положа руку на).
Даааа!. Я тебе уже приводил скрорость работы по Tcp/Ip, а HTTP это надстройка.
Сорость вызова Net кода из JS-Cef-Net выше. Почитай статьи. Там все выкладки есть.
Плюс тебе еще нужно писать обвязки, сериализацию итд.
Ты хоть знаешь, что такое Net Native? И то что он привязан к UWP, а UWP на линксе и яблоени не работает.
V>А вот при чем тут твой WPF и Angular — это я ХЗ, это у тебя в голове какая-то каша.
Это по моему у ьебя в голове 15 летнии технологии, UWP на линуксе, PHP в 2017 году.
S>>Электрон и моя разработка похожи, но они разные. У меня для расширения используются библиотеки .Net Core
V>При этом есть готовый кроссплатформенный GeckoFX, который уже всё это может: V>https://www.nuget.org/packages/Geckofx45.64.Linux/
Это вообще я так понимаю Mono ориентированная на фрайворк 4.5.
Ну конечно он лучше
И как я из браузера буду использоать нетовский код? Мне нужен GUI для работы с данными.
V>Причем, я уверен, что тонны технических моментов обыграны в GeckoFX всяко с большей тщательностью — это серьезная разработка.
V>Поэтому, я и говорю, что у тебя получилось "поиграться для себя".
То есть это только твои предположения? И в априоре ты считаешь Геко лучше. Даже их не сравнивая?
S>>И кстати эти электроном пользуется куча народа.
V>Я уже и на это тебе отвечал — когда начинали Электрон, то JS от Гугла показывал намного большее быстродействие, чем JS от Мозилы, т.е. на многое ТОГДА закрывали глаза. СЕЙЧАС такого преимущества гугловской v8 уже нет, поэтому можно перестать закрывать глаза на врождённые недостатки архитектуры Хромиума.
Угу, а народ то этого не знает. Пишет себе на электроне.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>> Не читаешь ты. Нет под линукс и эпл аналога WPF V>>Это ты не читаешь. Есть XUL. S>Ссылочку плиз. Я знаю Авалонию https://github.com/AvaloniaUI/Avalonia но она в альфе
Уже давал ссылку на GeckoFX.
S>>>Ты Angular 2 пробовал? V>>Пробовал. Это аналог PHP с тем отличием, что генерация страниц по шаблону реализована на JS, т.е. возможна так же на клиентской стороне, что и делается. Хотя, и на серверной стороне тоже можно генерить через Angular страницы, ес-но, просто никто в здравом уме не будет использовать шаблонный рендеринг на основе JS. Тут банальный нейтивный PHP-рендерер порвет JS как тузик грелку. )) S>Да уж. Razor рвет твой PHP как тузик грелку.
разработчиками vk.com утверждается, что скорость выполнения кода в среде kPHP увеличилась более чем в 10 раз
S>Но ты все мыслишь технологиями 15 летней давности. Проснись!
Какие 15-тилетней давности, о чем ты шепчешь?
Это Разор — технология ровно 15-тилетней давности, с тех пор как вышел первый ASP.Net.
Тем более, что речь шла о сравнении с Angular.
Там и Разор и PHP-движки его порвут как тузик грелку на клиенте.
А не вру, в 99% случаев Разор не порвёт ни Angular, ни PHP-движки.
Потому что у 99% пользователей Разора руки растут из ж-пы и они его юзают динамически, прикинь?
Там самая главная его фишка — это построить assembly по шаблону страницы.
Так вот, криворукие дотнетчики почему-то почти никогда не делают это как часть процедуры билда приложения, они генерят сборку в рантайм, а шаблоны страниц пихают в ресурсы.
И это тормозит ты даже не знаешь как...
V>>А если речь про использование готового .Net-кода, то можно взять кроссплатформенный рендерер от ASP.Net: V>>https://www.asp.net/core V>>и запускать его в своём дотнетном приложении — я так делал пару раз (тогда еще не было никакого Core, юзал от обычного дотнета). V>>Это тоже будет на порядки быстрее, чем любой JS-рендеринг по шаблону. Да это будет даже не сравнимо, бо можно заставить его скомпиллировать страницы в процессе билда приложения. )) А если еще и Net Native сверху скомпиллированных страниц натравить, то это будет совсем мега-фича, в сравнении той фигнёй, которой ты маешься (положа руку на). S>Даааа!. Я тебе уже приводил скрорость работы по Tcp/Ip, а HTTP это надстройка.
Ты БРЕДИШЬ безбожно...
Какой в опу Tcp/Ip???
Имелся ввиду некий template engine, используемый напрямую в клиентской приложухе.
Берешь любой PHP template engine, натравливаешь на GUI-шаблоны страниц, получаешь скрипт на PHP, генерящий эти страницы.
Затем на этот PHP-скрипт натравливаешь конвертер его в С++ и компилишь в нейтивный код.
А что касается Разора, до того момента, когда ты вообще услышал слово "Razor", сам движок шаблонов от ASP.Net уже вовсю юзали много лет, кому надо. Просто раньше надо было произвести несколько магических пасов руками, чтобы заставить его работать вне сервака, а чиста как библиотечный элемент — генератор кода по шаблону. У меня в "избранных" где-то должен валяться код для инициализации шаблонного движка от старых версий ASP.Net.
S>Сорость вызова Net кода из JS-Cef-Net выше. Почитай статьи. Там все выкладки есть. S>Плюс тебе еще нужно писать обвязки, сериализацию итд.
Ты опять безбожно бредишь, надоел.
S>Ты хоть знаешь, что такое Net Native? И то что он привязан к UWP, а UWP на линксе и яблоени не работает.
И опять у тебя мысли разбежались во все стороны, аки тараканы. ))
Скажи, как связаны м/у собой принципиальная возможность построения дотнетной сбоки-генератора HTTP-текста в момент билда и, коль оно происходит в момент билда, возможность накатить потом сверху Net Native?
Там где нет Net Native, там просто остаётся первая часть.
Ну или берется PHP-шаблонизатор, вместо ASP-шаблонизатора. Тем более, что суть обоих похожа, но синтаксис PHP-шаблонизатора, ИМХО, немного читабельнее.
V>>А вот при чем тут твой WPF и Angular — это я ХЗ, это у тебя в голове какая-то каша. S>Это по моему у ьебя в голове 15 летнии технологии, UWP на линуксе, PHP в 2017 году.
Просто ты страшно далёк вообще от всего, о чем пытаешься спорить.
С таким багажом представлений надо скромно спрашивать, а не громогласно утверждать.
Там вообще на сайте исходники. Компиляй на чём хочешь.
Я просто показал, что под линухами тоже народ юзает аж в путь.
S>И как я из браузера буду использоать нетовский код? Мне нужен GUI для работы с данными.
Действительно, как?
Ну так и спрашивай.
Формулируй нормально вопросы.
V>>Причем, я уверен, что тонны технических моментов обыграны в GeckoFX всяко с большей тщательностью — это серьезная разработка. V>>Поэтому, я и говорю, что у тебя получилось "поиграться для себя". S>То есть это только твои предположения? И в априоре ты считаешь Геко лучше. Даже их не сравнивая?
А не с чем сравнивать. У тебя, считай, ноль функциональности, в сравнении с.
Дать доступ "вообще ко всему дотнету" много ума не надо.
Ум надо приложить к проектированию архитектуры GUI-движка, к продумыванию инструментария и т.д.
V>>Я уже и на это тебе отвечал — когда начинали Электрон, то JS от Гугла показывал намного большее быстродействие, чем JS от Мозилы, т.е. на многое ТОГДА закрывали глаза. СЕЙЧАС такого преимущества гугловской v8 уже нет, поэтому можно перестать закрывать глаза на врождённые недостатки архитектуры Хромиума. S>Угу, а народ то этого не знает. Пишет себе на электроне.
Народ пишет давно.
Но ты-то вот только недавно свою обертку писал, не в 2010-м году, верно?
Т.е. у них-то хоть техническое обоснование есть для их выбора ТОГДА, а вот какое у тебя обоснование для твоего выбора СЕЙЧАС — это вопрос вопросов, однако... Хотя, я же говорил — если чиста "поиграться для себя", т.е. в рамках процедуры самообразования — я же не против. Но не пытайся тогда обсуждать свои игрища на техническом форуме, потому что тут свои решения надо суметь обосновать.
Здравствуйте, vdimas, Вы писали:
Еще раз. Почему ты на десктопе используешь WPF, Model-View-ViewModel , а не используешь PHP?
Ах да ты же С++ ник. А с++ настолько крутые, что из GUI используют только консоль.
Сейчас в моде SPA, а сервер выполняет только доставу и прием сериализованных данных.
И кстати опять же зачем Гуггл тратит столько денег?
И ведь не загорами Angular 5
//Но ты-то вот только недавно свою обертку писал, не в 2010-м году, верно?
Тогда не было .Net Core.
//А не с чем сравнивать. У тебя, считай, ноль функциональности, в сравнении с.
//Дать доступ "вообще ко всему дотнету" много ума не надо.
//Ум надо приложить к проектированию архитектуры GUI-движка, к продумыванию инструментария и т.д.
Ну дык есть движок CEF, а из него можно использовать любой класс Net.
Кстати и почему, это до меня никто не сделал обертку к Net, раз это может сделать и любой безмозглый?
Там кстати моно. И GUI взят из Windows.Forms. На WPF они не замахнулись.
и солнце б утром не вставало, когда бы не было меня
Re[20]: Программы в сохраненной html-странице -- почему не р
Здравствуйте, Serginio1, Вы писали:
S>Еще раз. Почему ты на десктопе используешь WPF, Model-View-ViewModel , а не используешь PHP?
Я еще в своём уме, поэтому НИКОГДА не использую WPF. ))
Но я несколько раз делал HTML-based приложухи. В основном в начале 2000-х на основе IE-контрола и своих экспортируемых в скрипт COM-объектов.
S>Ах да ты же С++ ник. А с++ настолько крутые, что из GUI используют только консоль.
Тю, из ширпотреба QT, GTK+, ранее ATL/WTL, еще ранее MFC.
Сейчас вообще под плюсы столько GUI-либ, что никакому дотнету или там JS и не снилось.
Вот сколько ты можешь вспомнить популярных сугубо дотнетных GUI-библиотеки? Штуки 2? WinForms, WPF? ))
Под джаву штуки 3-4? ))
Для сравнения под плюсы их многие десятки, начиная от древнего SDL, до современных nanogui.
Если задашься целью, то за пол-часа накидаешь список на пару экранов таких либ.
S>Сейчас в моде SPA, а сервер выполняет только доставу и прием сериализованных данных.
Сейчас в моде в первую очередь экономные в плане потребления батареек приложухи.
Поэтому нейтив опять рулит.
А всё что ты говоришь — это значения не имеет от слова совсем.
Личные половые трудности разработчиков, как ты понимаешь, никого не интересуют.
Интересуют лишь св-ва конечного продукта.
Т.е., нравится там тебе что-то или не нравится — да всем нас-ть.
Ты дай маленькую приложуху с мгновенным запуском и не жрущее энергию.
А то если для нажать пару кнопок надо запускать приложение весом в браузер, а оттуда еще дергать дотнет, то сам понимаешь...
Это роспись в немощности.
S>И кстати опять же зачем Гуггл тратит столько денег?
Затем, чтобы перевести вас, бестолочей, на нейтив.
Сам не видишь, что ле?
S>И ведь не загорами Angular 5
Главное, что синхронно идёт Angular на Dart.
А там уже и компилятор есть.
Ты хоть просекаешь многоходовочку или еще лапша с ушей не спала?
S>//Но ты-то вот только недавно свою обертку писал, не в 2010-м году, верно? S>Тогда не было .Net Core.
При чем тут Net Core, если речь про кривой Хромиум и скорость его JS?
S>Ну дык есть движок CEF
Нету там никакого движка. Там прибитая к задаче отображения HTML какая-то херня.
S>а из него можно использовать любой класс Net.
Это банально не нужно.
S>Кстати и почему, это до меня никто не сделал обертку к Net, раз это может сделать и любой безмозглый?
Потому что именно в таком виде оно НЕ нужно.
Похоже, ты еще не задавался вопросом — а почему есть такая мощнейшая net-обертка над XUL, но нет ничего подобного для CEF?
Нет, не может быть... это просто будет приплызд... Не, ты действительно веришь в то, что "а вот просто до МЕНЯ никто не справился???"...
В общем ты это, голову-то иногда включай.
Такую обертку не сделали из-за её бессмысленности.
Потому что архитектура CEF не располагает совершенно.
S>Там кстати моно. И GUI взят из Windows.Forms. На WPF они не замахнулись.
А прикинь, замахнулись бы, ы? ))
Т.е., сначала парсинг WPF, потом из него генерация "сцены", которая генерирует текстовый HTML, который передаётся в джава-скрипт на страницу и тот уже вставляет генерируемые HTML-теги в документ... О-о-о, да при такой схеме твоя приложуха на три вшивые GUI-кнопки съест всю батарейку за 15 мин. )))
Re[15]: Программы в сохраненной html-странице -- почему не р
S>>Проблема в том, что Линукм и эпл никому не нужны. Или нужны продукты от продвинутых фирм. А так я никто и звать меня никак. Я и работу найти не могу.
V>Для 1С-ников работы завались.
1C ки для расширения языка используют COM. И кстати и мою COM овскую библиотеку тоже.
При этом в кроссплатформенном варианте
добавил поддержку методов с параметрами по умолчанию, вызов методов расширений, вывод типов для дженерик методов, поддержка объектов реализующих IDynamicMetaObjectProvider (ExpandoObject,DynamicObject), добавление синонимов к членам типа и асинхронное программирование на 1С!
например
СборкаAngleSharp=ъ(Врап.Сборка("AngleSharp"));
Assembly=ъ(СборкаAngleSharp.GetType());
Врап.ДобавитьСиноним(Assembly.ПолучитьСсылку(),"Тип","GetType");
// Теперь мы можем использовать синоним Тип
AngleSharp_Configuration=ъ(СборкаAngleSharp.Тип("AngleSharp.Configuration"));
// Или вызвать реальный метод GetType
HtmlParser=ъ(СборкаAngleSharp.GetType("AngleSharp.Parser.Html.HtmlParser"));
При этом эту ВК тоже качают и используют.
На самом то дело не в продукте, а в том, что я Никто и звать меня никак.
и солнце б утром не вставало, когда бы не было меня
Re[21]: Программы в сохраненной html-странице -- почему не р
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Serginio1, Вы писали:
S>>Еще раз. Почему ты на десктопе используешь WPF, Model-View-ViewModel , а не используешь PHP?
V>Я еще в своём уме, поэтому НИКОГДА не использую WPF. )) V>Но я несколько раз делал HTML-based приложухи. В основном в начале 2000-х на основе IE-контрола и своих экспортируемых в скрипт COM-объектов.
Во во оно и видно. Ты все еще мыслишь категориями 2000 и контролами.
Я S>>Ах да ты же С++ ник. А с++ настолько крутые, что из GUI используют только консоль.
V>Тю, из ширпотреба QT, GTK+, ранее ATL/WTL, еще ранее MFC.
Во во. Это технологии на уровне Вин формс.
V>Сейчас вообще под плюсы столько GUI-либ, что никакому дотнету или там JS и не снилось. V>Вот сколько ты можешь вспомнить популярных сугубо дотнетных GUI-библиотеки? Штуки 2? WinForms, WPF? )) V>Под джаву штуки 3-4? )) V>Для сравнения под плюсы их многие десятки, начиная от древнего SDL, до современных nanogui. V>Если задашься целью, то за пол-часа накидаешь список на пару экранов таких либ.
Которые в подметки WPF не годятся.
Под JS вагон и маленькая тележка. Но сейчас в тренде Angular 2 с кучей компонентов
Я недавно писал на UWP и Xamarin, так по мне ГУЙ нарисовать на ангулар даже проще.
Но это я немного на них пишу.
S>>Сейчас в моде SPA, а сервер выполняет только доставу и прием сериализованных данных.
V>Сейчас в моде в первую очередь экономные в плане потребления батареек приложухи. V>Поэтому нейтив опять рулит. V>А всё что ты говоришь — это значения не имеет от слова совсем. V>Личные половые трудности разработчиков, как ты понимаешь, никого не интересуют. V>Интересуют лишь св-ва конечного продукта. V>Т.е., нравится там тебе что-то или не нравится — да всем нас-ть. V>Ты дай маленькую приложуху с мгновенным запуском и не жрущее энергию. V>А то если для нажать пару кнопок надо запускать приложение весом в браузер, а оттуда еще дергать дотнет, то сам понимаешь... V>Это роспись в немощности.
Тогда это область мобильных приложений, а не браузеров.
Но опять же тот же Ionic-2 плевал на твои рассуждения.
Интересует быстрое написание ПО. S>>И кстати опять же зачем Гуггл тратит столько денег?
V>Затем, чтобы перевести вас, бестолочей, на нейтив. V>Сам не видишь, что ле?
Это каким это образом?
Кстати UWP и Xamarin прекрасно компилятся с помощью Net Native и AOT для IOS.
S>>И ведь не загорами Angular 5
V>Главное, что синхронно идёт Angular на Dart. V>А там уже и компилятор есть. V>Ты хоть просекаешь многоходовочку или еще лапша с ушей не спала?
Угу основным языком является TS, а дарт вообще нигде не упоминается.
Сними очки. Опять же и TS может компилироваться в Dart VM. S>>//Но ты-то вот только недавно свою обертку писал, не в 2010-м году, верно? S>>Тогда не было .Net Core.
V>При чем тут Net Core, если речь про кривой Хромиум и скорость его JS?
Это ты о чем то витаешь. Скорость вызова Net объекта из Хромиума порядка 45 000 вызовов в секунду.
На итераторах там где передаются только инты это 200 вызовов.
Ты опять же когда тесты делал. Все там нормально.
S>>Ну дык есть движок CEF
V>Нету там никакого движка. Там прибитая к задаче отображения HTML какая-то херня.
Во во не читал, но осуждаю.
S>>а из него можно использовать любой класс Net.
V>Это банально не нужно.
Тебе конечно. S>>Кстати и почему, это до меня никто не сделал обертку к Net, раз это может сделать и любой безмозглый?
V>Потому что именно в таком виде оно НЕ нужно. V>Похоже, ты еще не задавался вопросом — а почему есть такая мощнейшая net-обертка над XUL, но нет ничего подобного для CEF?
Угу если бы это было так, то была бы куча GUI приложений на линукс.
V>Нет, не может быть... это просто будет приплызд... Не, ты действительно веришь в то, что "а вот просто до МЕНЯ никто не справился???"... V>В общем ты это, голову-то иногда включай. V>Такую обертку не сделали из-за её бессмысленности. V>Потому что архитектура CEF не располагает совершенно.
Ну конечно. Ты один у нас архитектор. Электрон,TS говно, но им пользутся.
XUL и Dart супер, но ими не пользутся
S>>Там кстати моно. И GUI взят из Windows.Forms. На WPF они не замахнулись.
V>А прикинь, замахнулись бы, ы? )) V>Т.е., сначала парсинг WPF, потом из него генерация "сцены", которая генерирует текстовый HTML, который передаётся в джава-скрипт на страницу и тот уже вставляет генерируемые HTML-теги в документ... О-о-о, да при такой схеме твоя приложуха на три вшивые GUI-кнопки съест всю батарейку за 15 мин. )))
Ты опять же коворишь о контролах. Я говорю об использовании в HTML .Net.
Разницу чувствуешь?
На самом деле я тебе одну вещь скажу. Только ты не обижайся.
Я с тобой потратил кучу времени и главное, что оно не принесло мне никакой пользы.
Вот например Sinix
дает много интересного и у него можно многому поучится.
Я тебе тоже даю кучу ссылок. Но кроме минусов и ухмылок я ничего не получаю.
и солнце б утром не вставало, когда бы не было меня
Re[16]: Программы в сохраненной html-странице -- почему не р
Здравствуйте, DenisCh, Вы писали:
DC>Здравствуйте, Serginio1, Вы писали:
S>> workbookPart = ъ(doc.WorkbookPart);
DC>Эта ять — название функции? Not hired, next please.
Это же 1С
Функция Ъ(Ссылка)
// Создаем объект по ссылке полученной из методов .Net классов
//Физически это строка ёЁ<Ьъ>№_%)Э?&2 содержащее 12 символов для отделения их от других строк
//и индекс в спике исполуемых объектов на стороне .Net
рез = Новый("AddIn.NetObjectToNative.NetObjectToNative");
// И установим ссылку
рез.УстановитьСсылку(Ссылка);
возврат рез
КонецФункции // СоздатьОбъектПоСсылке()
// Сокращенное использование метода ВК Новый
// Создает объект по строковому представлению типа или по ссылке на тип
Функция ъНовый(стр)
возврат ъ(Врап.Новый(стр));
КонецФункции
и солнце б утром не вставало, когда бы не было меня
Re[22]: Программы в сохраненной html-странице -- почему не р
Здравствуйте, Serginio1, Вы писали:
V>>Но я несколько раз делал HTML-based приложухи. В основном в начале 2000-х на основе IE-контрола и своих экспортируемых в скрипт COM-объектов. S>Во во оно и видно. Ты все еще мыслишь категориями 2000 и контролами.
Ну ты же не знаешь, как я HTML-текст генерил, верно?
Заметь, кста, что ты уже десятки раз был пойман на том, что на вполне безобидные технические подробности, которые хорошо показывают суть времен (что тех с IE, что современных с нейтивным PHP) — ты непременно пытаешься плеваться какашками. И каждый раз мне приходится показывать, что твоё плевание вызвано банальным дилетанством. Тебе самому еще не надоело? Жизнь, смотрю, ничему не учит...
S>На самом деле я тебе одну вещь скажу. Только ты не обижайся. S>Я с тобой потратил кучу времени и главное, что оно не принесло мне никакой пользы.
Потому что тебе хотелось, чтобы тебя хвалили, а тебя критикуют, "обижают".
S>Вот например Sinix S>дает много интересного и у него можно многому поучится.
Ну, когда этого коллегу не заносит, он бывает весьма делен, верно.
Просто, как и большинству дотнетчиков, ему порой отказывает банальная объективность. ))
S>Я тебе тоже даю кучу ссылок. Но кроме минусов и ухмылок я ничего не получаю.
Потому что ты 1.демагог, 2.принципиально не способен обсуждать свои технические решения.
Тебя ж натурально типает. Из любого замечания сугубо технического плана у тебя выходит натуральная истерика...
При том, то самое главное моё замечание, оно ж простое — в твоей работе отсутствует "системный подход" как явление. Твой подход к техническим вещам хаотичен, а результаты — лишь нагромождение случайностей.
Re[16]: Программы в сохраненной html-странице -- почему не р
Здравствуйте, Serginio1, Вы писали:
S>При этом эту ВК тоже качают и используют. S>На самом то дело не в продукте, а в том, что я Никто и звать меня никак.
Кто ты такой — решать лишь тебе.
Пока что я увидел человека с отсутствующей совестью в этом обсуждении.
Похоже, ты действительно поставил на себе крест...
Re[18]: Программы в сохраненной html-странице -- почему не р
Здравствуйте, Serginio1, Вы писали:
S> S>> workbookPart = ъ(doc.WorkbookPart); S> DC>Эта ять — название функции? Not hired, next please. S> Это же 1С S> [code] S> Функция Ъ(Ссылка)
Not hired, next please.
Я сколько раз говорил, что твои извращения в 1с не нужны?
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Serginio1, Вы писали:
V>>>Но я несколько раз делал HTML-based приложухи. В основном в начале 2000-х на основе IE-контрола и своих экспортируемых в скрипт COM-объектов. S>>Во во оно и видно. Ты все еще мыслишь категориями 2000 и контролами.
V>Ну ты же не знаешь, как я HTML-текст генерил, верно?
то что генерится на сервере это уже 2000
и солнце б утром не вставало, когда бы не было меня
Re[19]: Программы в сохраненной html-странице -- почему не р
Здравствуйте, DenisCh, Вы писали:
DC>Здравствуйте, Serginio1, Вы писали:
S>> S>> workbookPart = ъ(doc.WorkbookPart); S>> DC>Эта ять — название функции? Not hired, next please. S>> Это же 1С S>> [code] S>> Функция Ъ(Ссылка)
DC>Not hired, next please.
DC>Я сколько раз говорил, что твои извращения в 1с не нужны?
Их использует куча народа. И я в том числе.
Проблема то не во мне. Есть обычный COM вариант на IReflect.
А вот 1С кроссплаформенность особо то и не нужна.
и солнце б утром не вставало, когда бы не было меня
Re[17]: Программы в сохраненной html-странице -- почему не р
Здравствуйте, 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?
Вот и вся тема нашего разговора. Кто пра, а кто нет пусть решают другие. Я прислушаюсь к их мнению.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>>Во во оно и видно. Ты все еще мыслишь категориями 2000 и контролами. V>>Ну ты же не знаешь, как я HTML-текст генерил, верно? S> то что генерится на сервере это уже 2000
Зачем на сервере? Нейтивная приложуха генерит HTML-текст по данным.
Ничего легковеснее для подобной схемы еще не придумали.
Да, с отделением шаблонов представлений от данных не возился, да это было и не нужно для почти одноразовых задач.
Во-первых, приличная часть такого разделения выполняется на стороне 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);
И что-то мне подсказывается, что если речь о ДЕЙСТВИТЕЛЬНО небольших мобильных приложениях на основе некоего HTML-фреймворка, типа XUL или CEF, то показанное мною явно предпочтительнее всех Электронов вместе взятых. ))
Тут вся польза в Электроне в этом смысле лишь в наличии "вылизанных" под конкретную тематику оформления CSS, больше ни в чем.
Здравствуйте, Shmj, Вы писали:
S>А ведь такая простая возможность создавать утилитные кроссплатформенные приложения упущена...
А чем сайт отличается от десктопного приложения в этом случае?
То есть, зачем пользоватею вообще десктопные приложения, что за утилиты имеются в виду?
Если подумать, чего не хватает сайту? Доступа к файлам пользователя?
Дак он есть, с разрешения (html5 file api). К тому же и файлы сейчас на компе все меньше хранятся (dropbox/onedrive/etc)
Доступ к устройствам (типа принтеров-сканеров-моей-любимой-адруины)? Пилят потихоньку (стандарт usbweb например — свежак). Распространенные (микрофон-звук-камера-gps) уже поддерживаются (html5, webrtc)
Или мало производительности? WebAssembly скоро будет.
Зачем еще десктоп-приложения?
Re[25]: Программы в сохраненной html-странице -- почему не р
Здравствуйте, 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.
При компиляции приложения в Visual Studio код в xaml-файлах также компилируется в бинарное представление кода xaml, которое называется BAML (Binary Application Markup Language). И затем код baml встраивается в финальную сборку приложения — exe или dll-файл.
По сути то можно обходиться и без XAML программно используя компоненты.
DependencyObject rootElement;
using (FileStream fs = new FileStream(xamlFile, FileMode.Open))
{
rootElement = (DependencyObject)XamlReader.Load(fs);
}
Очевидно, что динамическая загрузка XAML не будет столь же эффективной, как компиляция XAML в BAML с последующей загрузкой BAML во время выполнения, особенно в случае сложного пользовательского интерфейса. Тем не менее, она открывает ряд возможностей для построения динамических пользовательских интерфейсов
На этапе основной компиляции осуществляется компиляция файлов кода. Это происходит по логике, содержащейся в специфичных для языка файлах целей 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
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, DenisCh, Вы писали:
DC>Здравствуйте, Serginio1, Вы писали:
S>> DC>Я сколько раз говорил, что твои извращения в 1с не нужны? S>> Их использует куча народа. И я в том числе.
DC>Извини, я я лично не знаком с тобой. И не знаю, насколько ты большая куча.
DC>А вот твои извращения не нужны. Я тебе об этом не первый год говорю.
Еще раз. Если тебе не нужно, это не значит, что это не нужно всем.
и солнце б утром не вставало, когда бы не было меня
Re[26]: Программы в сохраненной html-странице -- почему не р
Здравствуйте, 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 компилируется в код.
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 нужен сугубо на этапе разработки.
Причем, предвидя возражения о возможности "динамического переключения шаблонов" — дык, аналогично, речь пойдёт о "переключении" кода, формирующего "сцену".
Есть, но используется крайне редко, почти никогда.
Я же не отрицаю сценарий динамической загрузки когда он нужен.
Я ысмеиваю динамическую загрузку когда она не нужна.
Как и 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-странице -- почему не р
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 встраивается в контейнер.
Э
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> S>> DC>Я сколько раз говорил, что твои извращения в 1с не нужны? S> S>> Их использует куча народа. И я в том числе. S> DC>Извини, я я лично не знаком с тобой. И не знаю, насколько ты большая куча. S> DC>А вот твои извращения не нужны. Я тебе об этом не первый год говорю. S> Еще раз. Если тебе не нужно, это не значит, что это не нужно всем.
Ну, например линух тоже не нужен. Но находятся извращенцы...
Может, просто лучше подбирать инструмент под задачу, а не заниматься любимим рсдн-овским делом с совой и глобусом?
DC>Ну, например линух тоже не нужен. Но находятся извращенцы...
DC>Может, просто лучше подбирать инструмент под задачу, а не заниматься любимим рсдн-овским делом с совой и глобусом?
Что касаетя Ъ, то это вопрос к 1С почему они не хотят возвращать объекты и передавать их в параметрах.
И опять же ты же не пишешт создателям JQuery про $
и солнце б утром не вставало, когда бы не было меня
Re[28]: Программы в сохраненной html-странице -- почему не р
Здравствуйте, 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-код сугубо в демонстрационных целях. ))
— подписка на события:
elm.LostFocus += (obj, args) => { ...
Итого, даже находясь в координатах C#, бери себе любую из указанных выше оберток над какой-нить браузерной либой — Gecko, Webkit или CEF (который с 13-го года сидит на Blink) — и вперёд.
И никакой JS тебе и даром не нужен, особенно если у тебя наработки из дотнета.
Здравствуйте, 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?
Угу ты уверен, что они дергают не через 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>Заметь, что оба указанных подхода сочетаются — но это не мой мопед, я просто переводил некий имеющийся JS-код сугубо в демонстрационных целях. ))
V>- подписка на события: V>
V>Итого, даже находясь в координатах C#, бери себе любую из указанных выше оберток над какой-нить браузерной либой — Gecko, Webkit или CEF (который с 13-го года сидит на Blink) — и вперёд.
V>И никакой JS тебе и даром не нужен, особенно если у тебя наработки из дотнета.
Еще раз ты говоришь про контейнеры. Для Net Core нет GUI. Есть Mono. Но он WebForms и умирающая технология с поддержкой 4.5.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Serginio1, Вы писали:
S>> Смотри S>>Есть XAML S>>Как бы не хранился XAML он компилируется в код.
V>Не компилируется XAML ни в какой код.
S>>Иначе бы к Entry нельзя обратиться и не изменял свойства через код, не добавлял новые элементы.
V>Происходит интерпретация XML в рантайм, т.е. биндинг создаётся при загрузке формы. V>А почему именно интерпретация — вопрос вопросов, однако.
Вот и верь тебе.
Специально сделал приложение, правда UWP
Серьезность Код Описание Проект Файл Строка Состояние подавления
Ошибка Error HRESULT E_FAIL has been returned from a call to a COM component.
Серьезность Код Описание Проект Файл Строка Состояние подавления
Ошибка CS0123 Нет перегруженного метода для "button1_Click", который соответствует делегату "RoutedEventHandler".
То есть ошибки олавливаются на этапе компиляции в CIL
и солнце б утром не вставало, когда бы не было меня
Re[30]: Программы в сохраненной html-странице -- почему не р
Здравствуйте, Serginio1, Вы писали:
V>>Происходит интерпретация XML в рантайм, т.е. биндинг создаётся при загрузке формы. V>>А почему именно интерпретация — вопрос вопросов, однако. S>Ну в итоге интерпретируется или все же компилируется при загрузке формы?
Т.е. ты до сих пор не понял?
А если есть сомнения, то что помешало самому проверить?
В таком подходе к делу я вижу лишь ту самую среду патологических лентяев, среди которых живут и размножаются слухи/мифы.
S>Да? То есть если мы программно создаем то интерпиртации нет, а вот из XAML то есть?
Именно так.
S>Есть две компиляции в il и в машинный код
Нет в WPF никакой компиляции в IL.
V>>Проблема еще в том, что при интерпретации XML в рантайм многие ошибки тоже будут сыпаться именно в рантайм (при неверном биндинге или неверной росписи триггеров), хотя львиную долю таких ошибок в рантайме можно было бы избежать, сообщив о них в момент сборки приложения. S>Непомню, помоему на этапе компиляции такие ошибки вылетают. Нужно проверить
Лучше бы было проверить, чем писать сюда очередное бессмысленное сообщение.
V>>И какие проблемы добавить или удалить элементы непосредственно через DOM без всякого промежуточного JS? S>И каким это образом?
Если это был вопрос, то вот встречный — ты в своём уме вообще? ))
В первую очередь DOM доступен прямо из языка, на котором написан — на С++.
А вот уже через одно место к нему прикручен биндинг на JS.
И да, существующие дотнетные обертки — они оборачивают нейтивный код, ес-но, а никакой не JS.
S>И в CEF дергантся через JS методы
Исходники открыты, что тебе помешало посмотреть на реализацию WebKit и на то, как идёт работа с ним из CEF?
Лень-матушка? ))
Ты же опять подставляешься по самые помидоры.
Выходит, ты работал с некоей технологией, но всё-равно обломался на неё толком посмотреть.
Очередное проявление бессовестности.
Давать ссылку и не удосуживаться прочесть инфу по ней хотя по диагонали.
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 и убедиться, что сие так и есть. )))
Не надо мне на хабр вообще ссылки приводить.
Тем более на некачественные статьи с ужасным исходным кодом.
Я тебе уже показывал примеры, как положено экспортировать в 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-странице -- почему не р
Здравствуйте, Serginio1, Вы писали:
V>>Происходит интерпретация XML в рантайм, т.е. биндинг создаётся при загрузке формы. V>>А почему именно интерпретация — вопрос вопросов, однако. S>Вот и верь тебе.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Serginio1, Вы писали:
V>>>Происходит интерпретация XML в рантайм, т.е. биндинг создаётся при загрузке формы. V>>>А почему именно интерпретация — вопрос вопросов, однако. S>>Вот и верь тебе.
V>А своему любимому SO веришь?
S>>Добавил кнопку в XAML
V>Слишком просто, низачот. V>Попробуешь еще раз?
Попробуй сам. Я тебе не из головы выдумал. И ошибки показал.
Кроме того UWP не совсем WPF, но XAML почти тот же. Нет времени проверять WPF. Там кстати и версия .Net 4,5,1
и солнце б утром не вставало, когда бы не было меня
V>>>Проблема еще в том, что при интерпретации XML в рантайм многие ошибки тоже будут сыпаться именно в рантайм (при неверном биндинге или неверной росписи триггеров), хотя львиную долю таких ошибок в рантайме можно было бы избежать, сообщив о них в момент сборки приложения. S>>Непомню, помоему на этапе компиляции такие ошибки вылетают. Нужно проверить
V>Лучше бы было проверить, чем писать сюда очередное бессмысленное сообщение.
Будешь извиняться за " очередное бессмысленное сообщение"
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-странице -- почему не р
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 удобнее.
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:
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
V>>Лучше бы было проверить, чем писать сюда очередное бессмысленное сообщение. S>Проверил http://rsdn.org/forum/flame.comp/6744672.1
V>>И да, существующие дотнетные обертки — они оборачивают нейтивный код, ес-но, а никакой не JS. S>Угу при этом создаются и добавляются именно объекты JS
Нет и еще раз нет.
Это у тебя идёт работа с JS.
Потому что ты лентяй, который пошел по кратчайшему (якобы кратчайшему) пути.
В итоге твой путь вышел на порядок длиннее.
V>>Выходит, ты работал с некоей технологией, но всё-равно обломался на неё толком посмотреть. S>Да да. Ты только болтун
Болтун тут только ты. Потому что склонен забалтывать суть вещей.
Твоя беготня от прямого обсуждения вещей технического и есть то самое бессовестное трольство.
Причем, ты так хитро бегаешь, что на самом деле не убегаешь никуда, а лишь пережидаешь "опасный момент", а потом, блин, опять начинаешь гнать ту же самую пургу, на которую тебе уже подробно отвечали.
Такое времяпрепровождение — это форменный идиотизм.
Тебе уже были даны аргументы — отвечай на них.
Не в состоянии ответить? — всё ясно, слился.
ЧТД. Т.е. На саму технологию ты так и не взглянул, ограничился биндом к JS.
Так и запишем...
Судя по твоему коду, ты поленился сделать самое главное в своей задаче — разобраться с GUI-библиотекой браузера. Многократное рука-лицо.
V>>Очередное проявление бессовестности. V>>Давать ссылку и не удосуживаться прочесть инфу по ней хотя по диагонали. S>И что тапм не так?
Там обсуждается биндинг сугубо к JS, хотя я тебе раз сто повторил уже, что эта прослойка для твоей задачи не нужна от слова совсем.
Ты же сам сформулировал задачу таким образом, что тебе надо кроссплатформенно переиспользовать свои наработки на C#.
Ну и при чём тут тогда вообще JS и галимый v8?
Или даже не в состоянии сформулировать задачу?
S>прежде чем заявлять о бессовестности покажи, что там не так. Я же даю СВОЙ код и знаю как устроено.
Что именно тебе не понятно из предыдущего абзаца?
Скажем так, до этого сообщения мне казалось, что ты злостно троллишь, когда делаешь вид, что не понимаешь, чем C#-обертка над нейтивной GUI-библиотекой отличается от того, что сделал ты.
Ан, нет, похоже, ты ДЕЙСТВИТЕЛЬНО не понимаешь ни хрена... Вау...
Вот это расклады...
V>>А я здесь причем? Это ж ты такое условие поставил несколькими сообщениями выше и в этом топике тоже. V>>Тебе оно нужно якобы для кроссплатформенности. S>Да при том, что я говорю о браузере, а не контороллере.
Ты наводишь тень на плетень в попытке оправдаться.
Будь мужиком, скажи честно — так мол и так, где я где увидел при беглом просмотре куда можно задешево "присосаться" к GUI, там и "присосался".
Но когда тебе говорят, что это можно было бы сделать напрямую, а не через обходной путь JS, то тебе надо было спросить — "а как напрямую"?
А ты чем занят?
Ты упорно делаешь вид, что ваапще не понимаешь, о чем речь.
Ну или действительно не понимаешь.
V>>Потому что ты вовсе не UWP имеешь ввиду во всей этой беседе, а банальный нейтивный WinRT. V>>И мне уже порядком надоело продираться сквозь чащу твоей неточности и поверхностности, положа руку на. S>
Во-во, опять не понимаешь, о чем речь.
UWP — это маркетинг, а WinRT — это технология описания АПИ ОС.
А Windows RT — это винды для ARM.
Всё три аббревиатуры обозначают разное.
Никакие шаблоны Студии разработчику не нужны, можно создать пустой проект и настроить используемые версии фреймворков.
А нужные зависимости и так часто добавлять руками приходится, т.е. занятие это привычное, поди.
Просто дело в том, что на любом даже "обрезанном" Windows RT — планшете можно установить полноценный дотнет.
V>>Ты предлагал некие результаты своих экспериментов. V>>А я тебе объяснял, почему не надо их предлагать. V>>Потому что если бы ты поставил себе себе задачу нормально, то ты бы её решил малость по-другому. S>Я тебе показывал решение, которое ты даже не удосужился просмотреть, но сразу начал хаять
Я посмотрел,смирись. Всё было просмотрено, вердикт выдан.
Ты решил не ту задачу, которую требовалось решить согласно твоей собственной формулировке.
Я же говорю — у тебя лишь результат неких хаотических игрищ с дотнетом и CEF.
V>>Как бы так подобрать сюда эпитеты, чтобы меня не забанили? )) V>>Ну ты хоть порассуждал бы... V>>Из JS недоступно никакой другой функциональности кроме той, которую экспортируют в его контекст исполнения, так? V>>Т.е., прежде чем что-то станет доступно из JS, оно должно быть доступно и без JS, напрямую, верно?
S>А что по твоему напрямую? По твоему нужно держать две модели одну на JS другую на нативе?
В то время как ты можешь маршаллить простые типы и структуры из/в C#/нейтив как есть, простым копированием или даже по простой ссылке, без копирования. У тебя есть чудеснейшая возможность пользоваться нейтивным кодом практически напрямую из C#.
Но ты упорно от этой возможности отказываешься и предпочитаешь потратить тонну тиков процессора даже для простого получения значения int.
S>Это как в .Net держать и манагед и натив одновременно. Так было в начале, но потом натив используется очень мало.
В C# достаточно разработать ограниченное кол-во disposable-оберток над нейтивными типами — элементами GUI библиотеки.
Ну или посмотри через dotPeek реализацию дотнетных оберток над нейтивными WinRT интерфейсом.
S>Во во поподробнее. Значит SomeNodeType, а JS объект будет оберткой над нативом? Зачем двойная диспетчеризация.
Это у тебя двойная диспетчеризация сейчас, потому что у тебя целевой код на C#, но работает он через прослойку JS.
S>Тогда зачем ты используешь dynamic а не интерфейсы?
Потому что COM-библиотеке MSHTML стукнуло 20 лет, а на момент её разработки не было никаких селекторов.
Я просто сэкономил ровно пару строк кода, работая с DOM через более современное АПИ.
Но ты-то можешь предоставить в C# любое АПИ, какое тебе надо, верно? И дергать его типизированно.
Я же там часть кода дёргаю вполне типизировано, если заметил, где старого АПИ хватило.
S>То есть мои статьи ты не читаешь, но споришь?
Ты опять мне хамишь, столь смело делая за меня некие предположения.
V>>Потому что ты ни исследования имеющихся решений под CEF не провел, ни архитектуру самого CEF смотреть не стал. V>>Потому что ты неисправимый лентяй. S> Так покажи.
Так я давал уже ссылки на GeckoFX.
S>>>Для Net Core нет GUI. V>>С чего ты взял-то? S>Я тебе приводил авалонию, но она в альфе. Приводи свой пример.
Так, ДЕЙСТВИТЕЛЬНО не смотрел ни одной дотнетной GUI-либы, кроме WinForms или WPF?
Это рука-лицо много раз.
Гуглить хотя бы GtkSharp или GTK#.
Это тонкие обертки над нейтивной GUI-либой.
В исходниках.
Покажи мне, что помешает собрать эти тонкие либы под Net Core?
S>>>Есть Mono. Но он WebForms и умирающая технология с поддержкой 4.5. V>>GUI и Mono как связаны? S>Как WebForm// Как ссылк которые ты давал на контрол браузера для МОНО
Брехня. Я давал ссылки на сам проект, где лежат его исходники, которые являются компилябельными как под виндовый дотнет, так и под моно, так и под Core, так и под вообще подо что угодно. Потому что единственное что требуется для таких оберток — это дотнетный Interop, а он идёт самый первый в любом дотнетном фреймворке, ы-ы-ы.
V>>Сколько дотнетных оберток над нейтивными GUI-либами ты вообще смотрел? V>>Их же много десятков. S> Покажи для .Net Core
Любая из них подходит под .Net Core.
Это ты мне покажи, какая из них откажется скомпиллироваться на Net Core.
V>>Если в Net Core есть стандартный интероп, то все эти десятки либ автоматом доступны из Net Core. S>Нужно сделать обертки.
Их нужно скомпиллить, а не сделать.
S>Пока Авалония только в альфе
Сравнил фигню с пальцем.
Авалония — это очередная наколенная поделка, которая скорее всего никогда так и не будет доведена до ума.
Я же тебе давал ссылки на достаточно mature проекты.
S>И я. К сожалению, я был большего мнения о тебе.
К сожалению, ты был большего мнения о себе.
А по факту разучился впитывать любую новую информацию.
Re[32]: Программы в сохраненной html-странице -- почему не р
Так вот же ссылки, специально оставил в процитированном.
S>Я тебе не из головы выдумал. И ошибки показал.
Ты показал некие зачатки простейшей валидации.
А я тебе даю ссылки (а их очень много в гугле вывалилось), что у людей валидация в comple-time прошла, а в рантайме сыпет ошибками.
Причем, вопрос у всех один и тот же — а как перехватить ошибку валидации в виде обычного исключения-то?? )))
S>Кроме того UWP не совсем WPF, но XAML почти тот же. Нет времени проверять WPF. Там кстати и версия .Net 4,5,1
Отучайся говорить глупости. Не UWP, а WinRT.
Одно не означает другого, даже если ты в Студии взял UWP-шаблон.
Это просто такое название шаблона проекта, который подключает сборки для WinRT.
Ты можешь точно так же сделать своими ручками, без всякого шаблона UWP. Это не сложно. ))
Re[33]: Программы в сохраненной html-странице -- почему не р
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Serginio1, Вы писали:
V>>>Лучше бы было проверить, чем писать сюда очередное бессмысленное сообщение. S>>Проверил http://rsdn.org/forum/flame.comp/6744672.1
Я тебе привожу РЕАЛЬНЫЙ код. Ты мне ссылки 3 х летней давности.
И при этом говришь о совести.
V>>>И да, существующие дотнетные обертки — они оборачивают нейтивный код, ес-но, а никакой не JS. S>>Угу при этом создаются и добавляются именно объекты JS
V>Нет и еще раз нет.
То есть JS являются обертками над нативом. Кстати какой там для них GC или подсчет ссылок? V>Это у тебя идёт работа с JS. V>Потому что ты лентяй, который пошел по кратчайшему (якобы кратчайшему) пути. V>В итоге твой путь вышел на порядок длиннее.
V>>>Выходит, ты работал с некоей технологией, но всё-равно обломался на неё толком посмотреть. S>>Да да. Ты только болтун
V>Болтун тут только ты. Потому что склонен забалтывать суть вещей. V>Твоя беготня от прямого обсуждения вещей технического и есть то самое бессовестное трольство. V>Причем, ты так хитро бегаешь, что на самом деле не убегаешь никуда, а лишь пережидаешь "опасный момент", а потом, блин, опять начинаешь гнать ту же самую пургу, на которую тебе уже подробно отвечали. V>Такое времяпрепровождение — это форменный идиотизм. V>Тебе уже были даны аргументы — отвечай на них. V>Не в состоянии ответить? — всё ясно, слился.
Где ссылки на свои утверждения. Я тебе кучу ссылок приводил.
S>>>>https://bitbucket.org/chromiumembedded/cef/wiki/JavaScriptIntegration.md
V>ЧТД. Т.е. На саму технологию ты так и не взглянул, ограничился биндом к JS. V>Так и запишем...
Так и что записываем ты хоть расскажи. Интересно ведь. V>Судя по твоему коду, ты поленился сделать самое главное в своей задаче — разобраться с GUI-библиотекой браузера. Многократное рука-лицо.
Ну да покажи ка свое творение на использование натива из браузера, а не испоьзование браузера как контрола.
V>>>Очередное проявление бессовестности. V>>>Давать ссылку и не удосуживаться прочесть инфу по ней хотя по диагонали. S>>И что тапм не так?
V>Там обсуждается биндинг сугубо к JS, хотя я тебе раз сто повторил уже, что эта прослойка для твоей задачи не нужна от слова совсем. V>Ты же сам сформулировал задачу таким образом, что тебе надо кроссплатформенно переиспользовать свои наработки на C#. V>Ну и при чём тут тогда вообще JS и галимый v8?
Мне нужно вызвать из JS манагед код.
Ага который использует JS объекты. Казалосьбы причем тут JS?
V>Или даже не в состоянии сформулировать задачу?
Ну вроде как понятно использование .Net классов из TS/ Что не понятно?
Но ты начинаешь развивать свое видение, которое никакого отношения к задаче не имеет. S>>прежде чем заявлять о бессовестности покажи, что там не так. Я же даю СВОЙ код и знаю как устроено.
V>Что именно тебе не понятно из предыдущего абзаца?
Я вижу только твою бессовестность. V>Скажем так, до этого сообщения мне казалось, что ты злостно троллишь, когда делаешь вид, что не понимаешь, чем C#-обертка над нейтивной GUI-библиотекой отличается от того, что сделал ты.
V>Ан, нет, похоже, ты ДЕЙСТВИТЕЛЬНО не понимаешь ни хрена... Вау... V>Вот это расклады...
Ну только ты один всезнайка.
V>>>А я здесь причем? Это ж ты такое условие поставил несколькими сообщениями выше и в этом топике тоже. V>>>Тебе оно нужно якобы для кроссплатформенности. S>>Да при том, что я говорю о браузере, а не контороллере.
V>Ты наводишь тень на плетень в попытке оправдаться. V>Будь мужиком, скажи честно — так мол и так, где я где увидел при беглом просмотре куда можно задешево "присосаться" к GUI, там и "присосался".
V>Но когда тебе говорят, что это можно было бы сделать напрямую, а не через обходной путь JS, то тебе надо было спросить — "а как напрямую"? V>А ты чем занят? V>Ты упорно делаешь вид, что ваапще не понимаешь, о чем речь. V>Ну или действительно не понимаешь.
V>>>Потому что ты вовсе не UWP имеешь ввиду во всей этой беседе, а банальный нейтивный WinRT. V>>>И мне уже порядком надоело продираться сквозь чащу твоей неточности и поверхностности, положа руку на. S>>
V>Во-во, опять не понимаешь, о чем речь. V>UWP — это маркетинг, а WinRT — это технология описания АПИ ОС. V>А Windows RT — это винды для ARM. V>Всё три аббревиатуры обозначают разное.
Еще раз я говорю об UWP/ Оно имеет свое определение которое работает только на семействе Win 10.
Под приложением UWP понимается GUI с использованием XAML V>Так вот, ты запросто можешь писать на WPF для UWP: V>https://www.hanselman.com/blog/HowToCallWinRTAPIsInWindows8FromCDesktopApplicationsWinRTDiagram.aspx V>Не знал ведь? )) V>Потому что подходящего "шаблона" в Студии нет? V>А руками зависимости и target прописать — это высшая математика? ))
Я стебя.. Я привел ошибку в тексе которой есть COM.
Это говорит о том, что ты даже не читаешь о чем я пишу. Ты правда думаешь, что я не знаю, что такое WinRT?
И при этом говоришь о совести.
V>Никакие шаблоны Студии разработчику не нужны, можно создать пустой проект и настроить используемые версии фреймворков. V>А нужные зависимости и так часто добавлять руками приходится, т.е. занятие это привычное, поди.
И какие же версии в UWP?
И кстати например DataGrid UWP не поддерживает. Как впрочем .Net Core не поддерживате DataTable/
V>Просто дело в том, что на любом даже "обрезанном" Windows RT — планшете можно установить полноценный дотнет.
Полноценный нельзя! Это вообще песочница со многими ограничениями.
Например по файловой системе https://metanit.com/sharp/uwp/12.1.php
V>>>Ты предлагал некие результаты своих экспериментов. V>>>А я тебе объяснял, почему не надо их предлагать. V>>>Потому что если бы ты поставил себе себе задачу нормально, то ты бы её решил малость по-другому. S>>Я тебе показывал решение, которое ты даже не удосужился просмотреть, но сразу начал хаять
V>Я посмотрел,смирись. Всё было просмотрено, вердикт выдан. V>Ты решил не ту задачу, которую требовалось решить согласно твоей собственной формулировке. V>Я же говорю — у тебя лишь результат неких хаотических игрищ с дотнетом и CEF.
Еще раз ты утверждаешь, что в браузере существует две модели.
Основными являются нативные, а JS это обертка над нативными?
И учитвываем, что JS объекты могут компилироваться в натив.
Ну так это оберка над чем, Над
V>Так вот, тебе вся эта двойная хрень не требуется совершенно. V>Да просто чтобы передать банальное значение простого типа в JS нужно ужас сколько всего сделать: V>https://hg.mozilla.org/releases/mozilla-beta/file/39c86569861c/dom/bindings/ToJSValue.cpp
V>В то время как ты можешь маршаллить простые типы и структуры из/в C#/нейтив как есть, простым копированием или даже по простой ссылке, без копирования. У тебя есть чудеснейшая возможность пользоваться нейтивным кодом практически напрямую из C#.
Ты мне объясняешь как детсадовцу. Если бы посмотрел код то я как раз все это маршалю, а объекты передаю индекс в хроанилище и оборачиваю через JS объект. V>Но ты упорно от этой возможности отказываешься и предпочитаешь потратить тонну тиков процессора даже для простого получения значения int.
Угу. У меня весь код в .Net, а на вызов пару методов тратися немного кода. Скорости хватает.
S>>Это как в .Net держать и манагед и натив одновременно. Так было в начале, но потом натив используется очень мало.
V>В C# достаточно разработать ограниченное кол-во disposable-оберток над нейтивными типами — элементами GUI библиотеки.
Казалось бы при чем тут .Net Core, Линукс? V>Ну или посмотри через dotPeek реализацию дотнетных оберток над нейтивными WinRT интерфейсом.
Еще раз причем тут .Net Core, Линукс?
Для десктопа есть UWP,WPF.
S>>Во во поподробнее. Значит SomeNodeType, а JS объект будет оберткой над нативом? Зачем двойная диспетчеризация.
V>Это у тебя двойная диспетчеризация сейчас, потому что у тебя целевой код на C#, но работает он через прослойку JS.
Я спрашиваю, как хранится SomeNodeType и как осуществляется доступ из JS
S>>Тогда зачем ты используешь dynamic а не интерфейсы?
V>Потому что COM-библиотеке MSHTML стукнуло 20 лет, а на момент её разработки не было никаких селекторов. V>Я просто сэкономил ровно пару строк кода, работая с DOM через более современное АПИ. V>Но ты-то можешь предоставить в C# любое АПИ, какое тебе надо, верно? И дергать его типизированно. V>Я же там часть кода дёргаю вполне типизировано, если заметил, где старого АПИ хватило.
А то есть COM интерфейсов 20 лет назад не было?
S>>То есть мои статьи ты не читаешь, но споришь?
V>Ты опять мне хамишь, столь смело делая за меня некие предположения.
Посмотри на себя.
V>>>Потому что ты ни исследования имеющихся решений под CEF не провел, ни архитектуру самого CEF смотреть не стал. V>>>Потому что ты неисправимый лентяй. S>> Так покажи.
V>Так я давал уже ссылки на GeckoFX.
GeckoFX это контрол. И его нельзя использовать из .Net Core.
Но ты упорно это игнорируешь. А потом говоришь о совести. S>>>>Для Net Core нет GUI. V>>>С чего ты взял-то? S>>Я тебе приводил авалонию, но она в альфе. Приводи свой пример.
V>Так, ДЕЙСТВИТЕЛЬНО не смотрел ни одной дотнетной GUI-либы, кроме WinForms или WPF? V>Это рука-лицо много раз. V>Гуглить хотя бы GtkSharp или GTK#. V>Это тонкие обертки над нейтивной GUI-либой. V>В исходниках. V>Покажи мне, что помешает собрать эти тонкие либы под Net Core?
Вот и я думаю почему это кроме авалонии нет других проектов.
Опять же ты говоришь о возможности, но реальных продуктов нет.
S>>>>Есть Mono. Но он WebForms и умирающая технология с поддержкой 4.5. V>>>GUI и Mono как связаны? S>>Как WebForm// Как ссылк которые ты давал на контрол браузера для МОНО
V>Брехня. Я давал ссылки на сам проект, где лежат его исходники, которые являются компилябельными как под виндовый дотнет, так и под моно, так и под Core, так и под вообще подо что угодно. Потому что единственное что требуется для таких оберток — это дотнетный Interop, а он идёт самый первый в любом дотнетном фреймворке, ы-ы-ы.
Ну вот ты покажи не ссылки на исходники, а реальные обертки под Net Core? что бы из .Net Core можно использовать GUI по линукс.
А пока одна болтовня.
V>>>Сколько дотнетных оберток над нейтивными GUI-либами ты вообще смотрел? V>>>Их же много десятков. S>> Покажи для .Net Core
V>Любая из них подходит под .Net Core. V>Это ты мне покажи, какая из них откажется скомпиллироваться на Net Core.
Скомпилируй и посмотрим. V>>>Если в Net Core есть стандартный интероп, то все эти десятки либ автоматом доступны из Net Core. S>>Нужно сделать обертки.
V>Их нужно скомпиллить, а не сделать.
Так сделай. Очень много народу будут тебе благодарны.
S>>Пока Авалония только в альфе
V>Сравнил фигню с пальцем. V>Авалония — это очередная наколенная поделка, которая скорее всего никогда так и не будет доведена до ума. V>Я же тебе давал ссылки на достаточно mature проекты.
Ты не дал на реальное использование, только ссылки на исходники.
Вот например мои проекты бери и используй.
S>>И я. К сожалению, я был большего мнения о тебе.
V>К сожалению, ты был большего мнения о себе. V>А по факту разучился впитывать любую новую информацию.
Мое мнение о себе не изменилось. Но мне честно жалко тебя.
и солнце б утром не вставало, когда бы не было меня
Re[33]: Программы в сохраненной html-странице -- почему не р
Еще раз это не UWP и ссылки трех летней давности. Сейчас 4.6.1
Опять же ты не удосужился сам сделать проверку. И .Net Native крайне ограничен по рефлексии.
И там нет JIT. А значит все зависимости должны быть сделаны еще на этапе компиляции.
Но веды же дал ссылки совсем на другое. И при этом неудосужился проверить S>>Я тебе не из головы выдумал. И ошибки показал.
V>Ты показал некие зачатки простейшей валидации. V>А я тебе даю ссылки (а их очень много в гугле вывалилось), что у людей валидация в comple-time прошла, а в рантайме сыпет ошибками. V>Причем, вопрос у всех один и тот же — а как перехватить ошибку валидации в виде обычного исключения-то?? )))
Нет в Net Native comple-time потому что нет JIT.
Вернее на этапе в Debug там используется .Net Core CLR.
Но я собирал в режиме Debug
NGEN по-прежнему полагается на полную среду CLR для таких сервисов, как загрузка сборок, удаленное и локальное взаимодействие, управление памятью, сбор мусора и, при необходимости, JIT-компиляция. В .NET Native многие из этих сервисов являются либо ненужными (JIT-компиляции), либо разрешаются во время построения и включаются в сборку приложения. Остальные сервисы, наиболее важным из которых является сбор мусора, включены в гораздо более компактную, оптимизированную среду выполнения mrt100_app.dll.
S>>Кроме того UWP не совсем WPF, но XAML почти тот же. Нет времени проверять WPF. Там кстати и версия .Net 4,5,1
V>Отучайся говорить глупости. Не UWP, а WinRT. V>Одно не означает другого, даже если ты в Студии взял UWP-шаблон. V>Это просто такое название шаблона проекта, который подключает сборки для WinRT. V>Ты можешь точно так же сделать своими ручками, без всякого шаблона UWP. Это не сложно. ))
Вот именно WinRT это общая нативная библиотека, а UWP это надстройка на .Net Native? так приложения UWP компилируются в .Net Native/
Например в WinRt нет GC.
А WinRt я могу использовать откуда угодно, только это никакого отношение не имеет к Xaml
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
V>>Потому что ты вовсе не UWP имеешь ввиду во всей этой беседе, а банальный нейтивный WinRT. V>>И мне уже порядком надоело продираться сквозь чащу твоей неточности и поверхностности, положа руку на.
S> Я говорил прежде всего о Xaml. То есть декларативном описании интерфейса. S>А его используют WPF, UWP
Режет глаз такая безграмотность...
Я могу под UWP использовать WPF.
S>И главное можно разделить работу верстальщика и программиста.
Такие тулзы есть под большинство популярных GUI-библиотек.
S>В свое время на Xamarin можно было писать только код. Затем появился XAML. С XAML удобнее.
Если там нет компиляции шаблона в код, то тоже на помойку, ес-но.
Если есть, то респект.
Сможешь собрать простейший проект, залезть в него через dotPeek и посмотреть — что там реально происходит? Выполняется ли код построения сцены или интерпретируется XAML/BAML?
S>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.
Это маркетинг. ))
S>Так, что посмотри наконец на себя. Оцени свои высказываия. У тебя много знаний, но они либо устаревшие, либо поверхностные.
Либо у меня перед глазами нейтивное SDK Windows 10 и там сплошное WinRT. ))
S>
S>Теперь сделаем простейшее приложение. Визуально приложение UWP представлено через страницы — отдельные объекты Page. По умолчанию в проекте есть только одна страница — MainPage. Код этой страницы и определяет то, что мы увидим на экране при запуске приложения. И теперь немного изменим ее.
S>Итак, откроем файл MainPage.xaml:
Вот, для хомячков. А на деле ты можешь разработать WinRT приложение вообще без страниц или на основе DirectX или даже OpenGL (тоже поддерживается в AppStore-приложухах).
====================
Кароч, попробую распутать это нагромождение легенд, слухов и мифов.
Параллельно с чтением можно открыть у себя папку:
C:\Program Files (x86)\Windows Kits\10\Include
И выбрать одно из SDK для Windows 10.
Если там в include содержатся только CRT-заголовки, то скачай себе Windows 10 SDK (выбрать галочку — устанавливать только само SDK).
А потом рядом открыть папку:
C:\Program Files (x86)\Windows Kits\8.1\Include
Натравить какой-нить инструмент сравнения папок и поржать.
Например, поржать с того, что всё WindowsRT-like API для 10-ки лежит в подпапке winrt, ес-но, как и в SDK от Windows 8.1.
=================
Итак, вернёмся в прошлое.
С каждой версией Windows добавлялось какое-нить новое АПИ, которых не было в предыдущих версиях.
Например, я писал нейтивную приложуху для WindowsXP, отрисовывал контролы с текущей темой, ОК.
Но мне надо было, чтобы прложуха работала так же и под Windows 2000.
Мои действия?
Я в рантайм определял версию Windows и, если она была WindowsXP или выше, загружал библиотеку отрисовки тем Windows XP, если ниже, то рисовал через стандартную прорисовку контролов из либы User32.
Позже, под Windows Vista, Windows 7, Windows 10 djn ctqxfc — это всё так же прекрасно работает, т.е. прекрасно работает еще та приложуха, которая обыгрывает ситуацию с Windows XP или ВЫШЕ, динамически подгружает библиотеку прорисовки и рисует согласно текущей темы.
Теперь рассмотрим приложения AppStore. Что это за приложения такие? — это приложения, для которых исходный Win32 API был урезан до подмножества только "безопасных" ф-ий. Ну и плюс к этому новое развитое АПИ WinRT.
Так вот, проблема в том, что ф-ия АПИ LoadLibrary недоступна в урезанном АПИ ОС для приложух из магазина. А значит, я не смогу загрузить динамически какую-нить DLL в зависимости от версии ОС, на которой исполняется моё приложение. Более того, теперь от версий Windows отказались, считай, есть только версия обновления, а номер 10 теперь навечно. ))
Но рано или поздно некие АПИ будут добавляться, верно?
Или в неких устройствах, наоборот, может присутствовать урезанная версия АПИ, верно?
Итого, требуется некая функциональность динамического определения наличия некоего АПИ и пользования этим АПИ.
Так вот, в 10-ку в АПИ WinRT добавили эту функциональность, см. файл winrt\windows.foundation.metadata.idl, в нем интерфейс IApiInformationStatics.
Разумеется, такую функциональность добавили сугубо в виде WinRT-АПИ, ы-ы-ы:
Вот прямо тут можно запрашивать наличие неких интерфейсов и наличие в них методов/св-в.
Такой подход они назвали "универсальным", отсюда новый маркетинговый мем UWP, опять и снова ы-ы-ы.
И да, ввиду того, что Windows 10 совместима сверху вниз, то приложения WinRT 8.0 и приложения WinRT 8.1 будут прекрасно работать в "обычной" WinRT 10.0. Точно так же, как под Windows 7 прекрасно работали приложения, писанные под Windows XP. Например, в Windows 10 обновились коды енумов ActivationKind, но имеющиеся ранее для Windows 8.1 так же прекрасно работают, ес-но.
Далее.
Почему я настаиваю на упоминании WPF vs WinRT вместо WPF vs UWP?
Да потому что я запросто могу создать UWP-приложение на основе WPF.
Это вносит путаницу.
Но у нас в обсуждении подразумевалась та разница, КАК именно реализован движок GUI — практически полностью в дотнете (WPF) или в виде тонкой обертки над нейтивным WinRT API, верно?
=============
Весьма надеюсь, что я достаточно разъяснил суть моих поправок...
Re[33]: Программы в сохраненной html-странице -- почему не р
Здравствуйте, vdimas, Вы писали:
V>Далее. V>Почему я настаиваю на упоминании WPF vs WinRT вместо WPF vs UWP? V>Да потому что я запросто могу создать UWP-приложение на основе WPF. V>Это вносит путаницу. V>Но у нас в обсуждении подразумевалась та разница, КАК именно реализован движок GUI — практически полностью в дотнете (WPF) или в виде тонкой обертки над нейтивным WinRT API, верно?
BAML — это и есть XML. Там всей разницы, что его парсинг чуть быстрее.
Но все остальное происходит динамически — поиск зависимых св-в контролов по имени, определение типа зависимого св-ва, биндинг к ним и т.д.
Это не что иное как интерпретация данных, и вот она — одна из самых тормозных частей WPF.
При том что если сгенерировать код построения "сцены", то обращение к зависимым св-вам будет статически-типизированным.
S>Тот же UWP вообще компилируется в натив.
Нейтив не означает отсутствие динамики.
Все твои динамические языки писаны на нейтиве, если что. ))
S>Еще раз посмотри Net Native и UWP
На что именно посмотреть?
UWP — это лишь ограниченный набор WinAPI + ср-ва по динамическому определению наличия некоего АПИ.
V>============= V>Весьма надеюсь, что я достаточно разъяснил суть моих поправок...
Да ты можешь настаивать на чем угодно, только в UWP нет кучи возможностей WPF и наоборот.
И для меня эта разница очевидно. В одном случае это .Net CLR? а во втором .Net Native
Но вот в качестве работы с GUI они используют XAML как и Xamarin.Forms
Кстати
Например Особый интерес представляет Windows 10 IoT Core. Это новая редакция Windows, которой ранее не было. В ней нету привычного пользовательского интерфейса Windows, но есть вся необходимая инфраструктура для запуска UWP приложений. https://dou.ua/forums/topic/16860/
и солнце б утром не вставало, когда бы не было меня
Re[34]: Программы в сохраненной html-странице -- почему не р
Здравствуйте, Serginio1, Вы писали:
V>>Хреново проверил, я тебе ссылки дал. S>Я тебе привожу РЕАЛЬНЫЙ код. Ты мне ссылки 3 х летней давности.
Да хоть 10-тилетней давности.
Ничего не изменилось.
S>И при этом говришь о совести.
Потому что я даю тебе пример, который приводит к ошибке загрузки страницы в рантайме, хотя валидация прошла, а ты мне отвечаешь примером, который не прошёл валидацию. Хорошо себя чувствуешь?
V>>Нет и еще раз нет. S>То есть JS являются обертками над нативом.
Да. Причем, весьма непростыми обертками.
А потом ты эти непростые обертки опять оборачиваешь непростыми обертками C#.
S>Где ссылки на свои утверждения. Я тебе кучу ссылок приводил.
Мне не надо отвечать ссылками, не надо разбрасывать по сторонам моё внимание.
Я хотел услышать обоснование, почему именно так?
Обоснований не услышал.
И да, я тебе давал ссылки только потому что ты споришь с очевидным, утверждая, что к нейтивному DOM можно подцепиться только через JS.
А я сразу и говорил, что для движка Gecko это НЕ так, там проще подцепиться прямо к нейтиву, а в случае Хромиум прямо к нейтиву подцепиться чуть сложнее. По крайней мере у меня сложилось такое ощущение, когда я его смотрел лет ~5 назад.
S>Ну да покажи ка свое творение на использование натива из браузера, а не испоьзование браузера как контрола.
Опять эта пурга...
Любое приложение-браузер — это и есть использование "браузера как контрола" на некоей "форме".
Более того, возьми обычный Хром, попробуй в нём открыть произвольный JS с твоим Net-хелпером. Заработало? Нет? А чего так? ))
V>>Там обсуждается биндинг сугубо к JS, хотя я тебе раз сто повторил уже, что эта прослойка для твоей задачи не нужна от слова совсем. V>>Ты же сам сформулировал задачу таким образом, что тебе надо кроссплатформенно переиспользовать свои наработки на C#. V>>Ну и при чём тут тогда вообще JS и галимый v8? S>Мне нужно вызвать из JS манагед код.
А зачем JS на клиентской приложухе?
Юзверю будет предоставлена возможность динамически править этот JS и перезапускать его?
S>Ну вроде как понятно использование .Net классов из TS/ Что не понятно?
Непонятно, зачем тут TS.
S>Но ты начинаешь развивать свое видение, которое никакого отношения к задаче не имеет.
Это ты уже придумываешь новые условия задачи на ходу. Ты говорил, что тебе надо использовать наработки из дотнета. Но проще всего использовать наработки из дотнета на самом дотнете.
V>>Скажем так, до этого сообщения мне казалось, что ты злостно троллишь, когда делаешь вид, что не понимаешь, чем C#-обертка над нейтивной GUI-библиотекой отличается от того, что сделал ты. V>>Ан, нет, похоже, ты ДЕЙСТВИТЕЛЬНО не понимаешь ни хрена... V>>Вот это расклады... S> Ну только ты один всезнайка.
Да тут не требуется семи пядей во лбу. Тут требуется любопытство здорового человека.
S>Еще раз я говорю об UWP/ Оно имеет свое определение которое работает только на семействе Win 10.
S>Под приложением UWP понимается GUI с использованием XAML
Нет. Под приложением UWP понимается способность программы динамически опрашивать наличие неких АПИ в той версии ОС, на которой оно исполняется. Именно отсюда растут ноги у первой буквы в этой аббревиатуре.
Еще раз и по русски. Или это опять был ответ не на то, что ты оставляешь для цитирования?
S>Это говорит о том, что ты даже не читаешь о чем я пишу. Ты правда думаешь, что я не знаю, что такое WinRT?
Я достоверно знаю, что ты не знаешь, что такое UWP.
Один раз поправил, два, но ты же опять предпочитаешь включать воинственное невежество.
Неужели тебе не любопытно то, с чем ты работаешь?
V>>Никакие шаблоны Студии разработчику не нужны, можно создать пустой проект и настроить используемые версии фреймворков. V>>А нужные зависимости и так часто добавлять руками приходится, т.е. занятие это привычное, поди. S>И какие же версии в UWP?
Для Windows 8.1 номер WinRT АПИ указан как 1.3, для Windows 10 WinRT АПИ идёт за номером 1.4.
В ресурсах указана строка, например для Windows 10 (твоё UWP): "WindowsRuntime 1.4".
S> И кстати например DataGrid UWP не поддерживает. Как впрочем .Net Core не поддерживате DataTable/
V>>Просто дело в том, что на любом даже "обрезанном" Windows RT — планшете можно установить полноценный дотнет.
S> Полноценный нельзя! Это вообще песочница со многими ограничениями. S>Например по файловой системе S>https://metanit.com/sharp/uwp/12.1.php
Это для AppStore-приложений, бо они в песочнице исполняются.
А кто тебе мешает установить UWP-приложение обычным копированием, ы? )))
Вот за что я не люблю т.н. "шаблоны приложений" Visual Studio, что они вносят натуральную путаницу.
Потому что тебе, вообще-то доступно АПИ WinRT в твоих обычных приложухах.
Для этого не обязательно размещать приложуху в AppStore.
То посмотри там же — для нейтива вообще ничего особенного делать не надо — просто бери да пользуйся. ))
V>>Обрати внимание на virtual JSObject* WrapObject(...) S>JSObject это что?
Это та самая обертка, создания которой хотелось бы избежать.
S>Еще раз ты утверждаешь, что в браузере существует две модели. S>Основными являются нативные, а JS это обертка над нативными?
Ну я же тебе исходники даже дал, бо на слово ты не веришь... Хотя там всё очевидно. ))
S>И учитвываем, что JS объекты могут компилироваться в натив.
Не могут.
Всё-равно компиллируется динамический вызов обертки.
Потому что JS-движок знает устройство "своих" JS-объектов, но понятия не имеет об устройстве внешних объектов.
Поэтому вызов идёт через аналог IDIspatch.
S>Ну так это оберка над чем, Над
Даже в нейтиве лишняя обертка — это лишние тормоза.
А если еще и каждый метод вызывается через сложный код оберкти — то это ж-па полная.
Хана батарейке.
V>>В то время как ты можешь маршаллить простые типы и структуры из/в C#/нейтив как есть, простым копированием или даже по простой ссылке, без копирования. У тебя есть чудеснейшая возможность пользоваться нейтивным кодом практически напрямую из C#. S>Ты мне объясняешь как детсадовцу.
И меня это самого давно бесит, заметь.
Ты, блин, как рыба на крючке... вроде бы уже вижу, что понимаешь и даже где-то согласен... а нет, потом что-то у тебя перещелкивает и ты срываешься с крючка, опять надолго исчезая в мутной воде )))
S>Если бы посмотрел код то я как раз все это маршалю, а объекты передаю индекс в хроанилище и оборачиваю через JS объект.
Но ты оборачиваешь обертку.
Вот в чем ж-па. ))
Даже если тебе Ионика (или кто там) нагенерила тебе красивую страничку (ведь она тебе только для этого нужна, верно?), то раздай ты нужным контролам некие ID и потом из нейтива, вернее, из своей дотнетной обертки, присоединённой непосредственно к нейтивному АПИ запроси эти контролы и подпишись на события от нейтива, а не от JS. Ву а ля, или еще нет?
V>>В C# достаточно разработать ограниченное кол-во disposable-оберток над нейтивными типами — элементами GUI библиотеки. S>Это ты все WinForms вспоминаеь. Он уже умер.
Это в тебе инженер умер. WinForms тут не при чём.
S>Казалось бы при чем тут .Net Core, Линукс?
А там что, какой-то особенный interop, что ле?
Такой же точно.
V>>Ну или посмотри через dotPeek реализацию дотнетных оберток над нейтивными WinRT интерфейсом. S>Еще раз причем тут .Net Core, Линукс?
Всё то же самое через такой же точно interop.
V>>Потому что COM-библиотеке MSHTML стукнуло 20 лет, а на момент её разработки не было никаких селекторов. V>>Я просто сэкономил ровно пару строк кода, работая с DOM через более современное АПИ. V>>Но ты-то можешь предоставить в C# любое АПИ, какое тебе надо, верно? И дергать его типизированно. V>>Я же там часть кода дёргаю вполне типизировано, если заметил, где старого АПИ хватило. S>А то есть COM интерфейсов 20 лет назад не было?
Не было библиотеки MSHTML.
S>GeckoFX это контрол. И его нельзя использовать из .Net Core.
GeckoFX — это исходники. В том числе в этих исходниках содержатся контролы для WinForms, WPF, GTK.
Тебе ведь все-равно нужно окно верхнего уровня в линухах? Вот бери GTK для окна верхнего уровня, бросай на него свой браузер и радуйся.
И только попробуй еще раз озвучить, что под .Net Core это нельзя использовать. Прокляну. )))
S>Но ты упорно это игнорируешь. А потом говоришь о совести.
Я 100 раз тебе на это отвечал, ты игноришь мои ответы. Поэтому я обвиняю тебя в отсутствии совести.
Ты не имеешь права повторять те свои аргументы, на которые уже был дан ответ. Это если речь идёт о техническом обсуждении, а не о ругани на базаре, ес-но.
Ты можешь дать свои новые аргументы или не дать никаких.
Например, я 100 раз говорил, что interop под .Net Core был реализован одним из первых, бо это вообще фундамент дотнета.
А значит ЛЮБЫЕ интеропные обертки прекрасно в .Net Core компиллируются и работают.
Собсно, сам этот .Net Core в первую очередь для таких оберткок и предназначался — чтобы их можно было не только на Windows собирать, но и под другие платформы.
V>>Гуглить хотя бы GtkSharp или GTK#. V>>Это тонкие обертки над нейтивной GUI-либой. V>>В исходниках. V>>Покажи мне, что помешает собрать эти тонкие либы под Net Core? S>Вот и я думаю почему это кроме авалонии нет других проектов.
S>Опять же ты говоришь о возможности, но реальных продуктов нет.
GtkSharp и GTK# — это самые что ни на есть реальные продукты.
Бери да пользуйся.
Если возникнут непреодолимые сложности с компиляцией их в .Net Core — обращайся.
V>>Брехня. Я давал ссылки на сам проект, где лежат его исходники, которые являются компилябельными как под виндовый дотнет, так и под моно, так и под Core, так и под вообще подо что угодно. Потому что единственное что требуется для таких оберток — это дотнетный Interop, а он идёт самый первый в любом дотнетном фреймворке, ы-ы-ы. S>Ну вот ты покажи не ссылки на исходники, а реальные обертки под Net Core?
А может ты меня попросишь еще твои исходники для тебя компиллировать? ))
Без няньки уже никак?
S>что бы из .Net Core можно использовать GUI по линукс. S>А пока одна болтовня.
Т.е., вместо того, чтобы честно сказать: "так мол и так, у меня есть одна постыдная проблема — я не знаю как скомпиллировать дотнетные исходники для .net Core..." ты устроил весь этот цирк?
Ну так не удивляйся, что теперь в бессовестных ходишь. ))
Здравствуйте, Serginio1, Вы писали:
V>>Но у нас в обсуждении подразумевалась та разница, КАК именно реализован движок GUI — практически полностью в дотнете (WPF) или в виде тонкой обертки над нейтивным WinRT API, верно? S>Нет. Ты утверждал, что XAML интерпретируется в любой библиотек.
Это независимые утверждения, оба верные.
V>>Весьма надеюсь, что я достаточно разъяснил суть моих поправок... S> Да ты можешь настаивать на чем угодно, только в UWP нет кучи возможностей WPF и наоборот.
Я тебе уже дал ссылку на дотнет 4.5.2 для UWP.
S>И для меня эта разница очевидно.
Если бы ты ВНИМАТЕЛЬНО прочитал мои объяснения, то разница тебе стала бы понятна.
Ты можешь запросто написать WPF-приложение из которого вызываешь UWP АПИ.
В этом и есть суть возникающей путаницы.
S>В одном случае это .Net CLR? а во втором .Net Native
Во втором случае это тоже может быть обычным дотнетом, просто с дополнительными зависимыми сборками — тонкими обертками над WinRT API.
Неужели так сложно добавить несколько референсных дотнетных сборок в приложение? В чем проблема-то?
Ты не знаешь где их искать на своей машине? Так спроси у гугла или у меня.
S>Но вот в качестве работы с GUI они используют XAML как и Xamarin.Forms
Я еще не щупал Xamarin.Forms, поэтому по нему ничего сказать не могу.
Речь была не об этом всём. Обсуждались несколько моментов:
— интерпретация XAML в рантайм — сие плохо;
— WPF писан на дотнете, WinRT нейтивный, для дотнета там только тонкие обертки.
И ничего друг другу не противоречит — ты можешь использовать и те и те сборки одновременно в одном приложении.
Ссылку на пример я давал.
S>Например Особый интерес представляет Windows 10 IoT Core. Это новая редакция Windows, которой ранее не было. В ней нету привычного пользовательского интерфейса Windows, но есть вся необходимая инфраструктура для запуска UWP приложений. S>https://dou.ua/forums/topic/16860/
Здравствуйте, Shmj, Вы писали:
S>Берем пишем прогу на JS внутри HTML-страницы. Сохраняем на диск на компьютере. Когда нужно -- запустили, все открылось. Все работает. Причем все работает и в Win и в Lin и в Mac OS. А еще ведь браузеры есть и во всех моб. телефонах (даже не самых современных), значит и там можно сделать чтобы работало.
S>А ведь такая простая возможность создавать утилитные кроссплатформенные приложения упущена...
Бывает, что JS не одинаково работает в разных браузерах и разных версиях одного браузера.
Как правило, пользователю нужно сохранять результаты своей работы, а потом — открывать, ранее сохранённые, данные. JS не позволяет сохранять данные локально. А если добавить такую возможность в браузеры, то это будет дырой в безопасности.
Re[2]: Программы в сохраненной html-странице -- почему не развиты?
Здравствуйте, AleksandrN, Вы писали:
AN>Как правило, пользователю нужно сохранять результаты своей работы, а потом — открывать, ранее сохранённые, данные. JS не позволяет сохранять данные локально. А если добавить такую возможность в браузеры, то это будет дырой в безопасности.
Не работает. Получается уже привязка к браузеру есть.
