Возможно кому-то окажется полезным, а кто-то захочет принять участие.
Это маленькая и простая для использования (однако по возможностям практически не уступающая обертке HTMLayout из проекта Nabu).
В отличии от Nabu обертка построена над Sciter.
Основная идея — GUI оставить Скайтеру. Получать уведомления от Скайтера о событиях и предавать Скайтеру данные для изображения.
Скайтер может общаться с Хостом (Вашей программой) путем вызова метода view.callback либо определения behavior:script-host для любого из элементов и далее вызова метода xcall этого елемента. Второй метод более естественный, так как не ограничивает кол-во аргументов и позволяет вызывать функцию хоста по символьному имени.
Кода Скайтер вызывает Хост происходит событие CallHost в котором доступны аргументы и можно вернуть значение.
Хост может общаться со Скайтер посредством фукций Call (вызов функции Скайтера) и Eval.
Параметры и возвращаемые значения конвертируются между типами .NET и Скайтер автоматически (хотя и есть определённые ограничения)
Спасибо ребятам из проекта Nabu. Их работа позволила мне за 3-4 часа создать эту обёртку.
Текущая версия — это первый взгляд (оценка того, стоит или нет использовать эту технологию), поэтому пока в исходных текстах отсутствует корректная обработка ошибок, возвращаемых Скайтер API (дело будущего). Кто будет использовать имейте это в виду.
Куча заметок, не в порядке важности, а как в голову пришло
Каким образом derivative от LGPL стала вдруг попала под Apache License? Некоторые куски кода явно скопипастены.
AnkhSVN глючит, мне как владельцу проекта с открытым исходным кодом дали VisualSVN на халяву.
Файл с интеропом надо называть не Native.cs, а NativeMethods.cs, SafeNativeMethods.cs, UnsafeNativeMethods.cs
SciterEeventGroups — опечатка.
Нажимай Ctrl+K, Ctrl+D в студии.
Отступы пробелами дело твоё, меня не вставляет.
Наследовать часть перечислений от int, а часть от uint тоже не айс.
Класс Helper является хорошим примером паттерна усыновитель
Про "практически не уступающая обертке HTMLayout из проекта Nabu" это ты весело пошутил. Краеугольный камень, причина многочисленных научных споров и бессонных ночей, класс HtmlTag в проекте отсутствует вообще.
Как хост взаимодействует со Скайтером не ясно, примеров нет.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Аноним, Вы писали:
A>Куча заметок, не в порядке важности, а как в голову пришло
A>
A> Каким образом derivative от LGPL стала вдруг попала под Apache License? Некоторые куски кода явно скопипастены. A> AnkhSVN глючит, мне как владельцу проекта с открытым исходным кодом дали VisualSVN на халяву. A> Файл с интеропом надо называть не Native.cs, а NativeMethods.cs, SafeNativeMethods.cs, UnsafeNativeMethods.cs A> SciterEeventGroups — опечатка. A> Нажимай Ctrl+K, Ctrl+D в студии. A> Отступы пробелами дело твоё, меня не вставляет. A> Наследовать часть перечислений от int, а часть от uint тоже не айс. A> Класс Helper является хорошим примером паттерна усыновитель A> Про "практически не уступающая обертке HTMLayout из проекта Nabu" это ты весело пошутил. Краеугольный камень, причина многочисленных научных споров и бессонных ночей, класс HtmlTag в проекте отсутствует вообще. A> Как хост взаимодействует со Скайтером не ясно, примеров нет. A>
Не коим образом не хотел кого-то обидеть или задеть. Именно Вам я и высказал благодарность, за проект Nabu с помощью которого (в том числе с помощью копи-пасте за 3-4 часа создал этот код). Спасибо Вам еще раз (если 2 ранее не достаточно).
Честно признать про лицензию не задумывался. Возможно не прав. Поправьте.
AnkhSVN глючит, согласен. Но меня устраивает.
Спасибо, что поделились Вашим мнением как надо называть файлы. Но я пока буду называть так-как мне удобно.
Еще раз повторю, это эксперимент на предмет исследования технологии. Я не претендую на конечный продукт. Это взгляд на проблему, которой может поможет еще кому-то. Возможно что-то не так. (Вспомните Вашу первую реализацию Nabu.Forms.Html это-ли не был АД?)
Суть подхода — убираем Ваш краeугольный КАМЕНЬ HtmlTag — получаем легкую обертку. Это ли не решение? GUI-для Скайтер, остальное для .NET?
Как хост взаимодействует со Скайтером? У контрола Sciter есть метод Call. В Скайтере определяем функцию SuperNiceFunction. И вызываем ее: var rerVal = Control.Call("SuperNiceFunction", arg1, arg2, arg3)
Что удивительно, пока регистрировал свой код на google, обнаружил замечательнейший проект, которой покрывает 2 подхода (с "КРАЕУГОЛЬНЫМ КАМНЕМ" и без него). Ссылка: http://code.google.com/p/expemerent/
Здравствуйте, vabe, Вы писали:
V>Не коим образом не хотел кого-то обидеть или задеть.
Ты не обидел и не задел, прости если показался груб. Ещё одному HTMLayout'овцу я всегда рад
V>Честно признать про лицензию не задумывался. Возможно не прав. Поправьте.
Ну вот надо подумать.
V>AnkhSVN глючит, согласен. Но меня устраивает.
Просто Visual SVN дают на халяву, так что why not?
V>Спасибо, что поделились Вашим мнением как надо называть файлы.
Это стандарт .Net, а не мнение.
V>Еще раз повторю, это эксперимент на предмет исследования технологии. Я не претендую на конечный продукт. Это взгляд на проблему, которой может поможет еще кому-то. Возможно что-то не так. (Вспомните Вашу первую реализацию Nabu.Forms.Html это-ли не был АД?)
Первая реализация была говно.
Даже сейчас не всё шикарно. Скажем HtmlTag штука тяжёлая и сомнительной архитектурной красоты, но ничего лучше я не придумал пока. Попытки декомпозиции пока что были исключительно неудачными. W3C DOM model и реалии DOM IE/Mozilla заставляют думать, что видно у HtmlTag судьба такая
V>Суть подхода — убираем Ваш краeугольный КАМЕНЬ HtmlTag — получаем легкую обертку. Это ли не решение? GUI-для Скайтер, остальное для .NET?
Спорное утверждение. Скажем надо уметь вставлять .Net элементы управления. Меня об этом часто просят, вот скоро видимо руки дойдут сделать. То есть только возможностей HTML для GUI вообще говоря не хватает.
V>Как хост взаимодействует со Скайтером? У контрола Sciter есть метод Call. В Скайтере определяем функцию SuperNiceFunction. И вызываем ее: var rerVal = Control.Call("SuperNiceFunction", arg1, arg2, arg3)
Не, интересно из Sciter позвать что-то .Net.
V>Что удивительно, пока регистрировал свой код на google, обнаружил замечательнейший проект, которой покрывает 2 подхода (с "КРАЕУГОЛЬНЫМ КАМНЕМ" и без него). Ссылка: http://code.google.com/p/expemerent/
userstvo странная личность. Он до того сделал мёртвый Си++ проект lua-app представлявший собой Lua скрипт прикрученный к HTMLayout. Мне эта тема была интересна в какой-то момент, я ему писал (15 июня 2008), он мне даже не ответил. Сейчас вот expemerent. Видимо у человека навязчивая идея сделать такую же штуку как скайтер, но другую. Большого смысла для .Net я в этом не вижу, попытки сотрудничества прекратил.
Лично моё мнение, что с приходом CSSS! скайтер вообще потерял для .Net какой-либо интерес. Бизнес-логика на двух разных языках — зло. Я даже VB.Net с C# не смешиваю, а тут какой-то TIScript. Динамическая компиляция есть, ASP.Net-образный препроцессор генерирующий HTML сделать — пара пустяков. Я такое написал за день и ещё пару дней прикручивал разные наворотки (см Nabu.Text.Template*). Лично для меня use case вообще не очевиден. То есть если без фанатизма "хачу GUI на Sciter", то я не понимаю почему нельзя или сложнее тоже самое сделать на C#. Не восприми как наезд "гы-гы, ты сделал никому не нужную вещь", у меня опыт быть может и большой, быть может даже и больше чем у других, но специфический, от этого не убежать, и я какие-то вещи могу не понимать. Иногда Андрей что-то делает что я просто не понимаю, он мне говорит, объясняет, как об стенку горох В конце концов я просто принимаю его решения как обстоятельство. Так что давай подумаем можем ли мы продуктивно сотрудничать, куда кому развиваться и что надо от нас народу.
Здравствуйте, adontz, Вы писали:
A>Не, интересно из Sciter позвать что-то .Net.
1) В .NET: реакция на событие CallHost
(В параметре события доступно какой метод (или если угодно какое это событие) надо обработать, какие переданы аргументы и какое будет
возвращаемое значение.
2) В Sciter
Первый способ — view.callback(channel, p1, p2)
Второй способ — <widget #host style="behavior:script-host" /> и self#host.xcall("FuncName", p1,....pX)
A>Лично моё мнение, что с приходом CSSS! скайтер вообще потерял для .Net какой-либо интерес. Бизнес-логика на двух разных языках — зло. Я даже VB.Net с C# не смешиваю, а тут какой-то TIScript. .....
Но Вы уже сделали шаг от Вашего утверждения (Бизнес-логика на двух разных языках — зло). Вы используете 1) HTML 2) CSS — уже 2 языка, один для разметки, другой для стилей. Если Вы используете базы данных, то еще и SQL. Делаете свои — шаблоны, опять таки что-то вроде языка(Еще один?).
В конечном итоге применение различных языков в проектах это просто необходимость так-как один конкретный язык слишком ограничен для своевременного создания с минимальными затратами коммерческого решения.
Представление данных для пользователя — это скорее не бизнес логика, а ее визуализация. Она может отличаться для разных пользователей одного проекта, для разных проектов (для разных заказчиков) с одинаковой бизнес логикой. Помимо разработки, возникает еще одна проблема при предложении программного продукта компаниям, работающим в конкурирующей области. Они, например, отказываются сотрудничать (или прекращают), если узнают, что аналогичные решения Вы, как разработчик, предлагаете их конкурентам. В этом случае простой способ избежать этого — зарегистрировать новое юридическое лицо и "натянуть на программу новое лицо". В случае со Sciter натягивание нового "лица" становиться простым, при этом "лицо" может быть таким, что "не узнает родная мама".
В конечном итоге у меня ряд ребят которые работали в области WEB приложений (HTML,JavaScript) и ничего не знают про С#, а подход со Sciter мне дает возможность использовать их навыки в новой области.
Здравствуйте, vabe, Вы писали:
A>>Лично моё мнение, что с приходом CSSS! скайтер вообще потерял для .Net какой-либо интерес. Бизнес-логика на двух разных языках — зло. Я даже VB.Net с C# не смешиваю, а тут какой-то TIScript. .....
V>Но Вы уже сделали шаг от Вашего утверждения (Бизнес-логика на двух разных языках — зло). Вы используете 1) HTML 2) CSS — уже 2 языка, один для разметки, другой для стилей. Если Вы используете базы данных, то еще и SQL. Делаете свои — шаблоны, опять таки что-то вроде языка(Еще один?).
Да, но на HTML и CSS я не бизнес-логику описываю.
V>В конечном итоге у меня ряд ребят которые работали в области WEB приложений (HTML, JavaScript) и ничего не знают про С#, а подход со Sciter мне дает возможность использовать их навыки в новой области.
Ах вот оно как. Так может продуктивнее было бы взять Nabu как есть и добавить качественную обёртку над TIScript, которая бы за счёт Reflection (включая кодогенерацию), внедряла бы в скрипт произвольные объекты .Net? Собственно, почему бы не взять, в конце концов, JavaScript.Net если аудитория — веб-разработчики?
Здравствуйте, adontz, Вы писали:
A>Да, но на HTML и CSS я не бизнес-логику описываю.
Так и я не предлагаю. Меджу Sciter и Хостом существует "контракт" или API, по которому они обмениваются необходимыми данными и событиями. Sciter рисует на экране. Хост решает остальное.
V>>В конечном итоге у меня ряд ребят которые работали в области WEB приложений (HTML, JavaScript) и ничего не знают про С#, а подход со Sciter мне дает возможность использовать их навыки в новой области.
A>Ах вот оно как. Так может продуктивнее было бы взять Nabu как есть и добавить качественную обёртку над TIScript, которая бы за счёт Reflection (включая кодогенерацию), внедряла бы в скрипт произвольные объекты .Net? Собственно, почему бы не взять, в конце концов, JavaScript.Net если аудитория — веб-разработчики?
Продуктивнее чем что? Чем то-что уже написано за 4 часа и реализует основную идею и функционально достаточно(возможно пока написано не совсем красиво)?
Может поступить так (в опозицию Вашему предложению) — взять идею и сделать ее красивой в реализации?
Что касается обертки над TIScript, если Вам это интересно, то посмотрите на проект userstvo (про которого Вы не очень уважительно высказывались, как мне показалось). У него она уже есть, возможно не такая, как Вы указали. Можно написать класс на С# и использовать его в TIScript. Этот уникальный человек реализовал надстройки в одном коде над HTMLayout и Sciter (старой версии) одновременно. Поистине титанический и красивый труд (хотя и смахивает на Сизифов).
Здравствуйте, adontz, Вы писали:
A>Первая реализация была говно. A>Даже сейчас не всё шикарно. Скажем HtmlTag штука тяжёлая и сомнительной архитектурной красоты, но ничего лучше я не придумал пока. Попытки декомпозиции пока что были исключительно неудачными. W3C DOM model и реалии DOM IE/Mozilla заставляют думать, что видно у HtmlTag судьба такая
V>>Суть подхода — убираем Ваш краeугольный КАМЕНЬ HtmlTag — получаем легкую обертку. Это ли не решение? GUI-для Скайтер, остальное для .NET?
A>Спорное утверждение. Скажем надо уметь вставлять .Net элементы управления. Меня об этом часто просят, вот скоро видимо руки дойдут сделать. То есть только возможностей HTML для GUI вообще говоря не хватает.
Для sciter.net обертки (могу кстати сайт такой отдать в хорошие руки).
Создание control'ов делается путем написания
type Control: Behavior { }
в sciter.
V>>Как хост взаимодействует со Скайтером? У контрола Sciter есть метод Call. В Скайтере определяем функцию SuperNiceFunction. И вызываем ее: var rerVal = Control.Call("SuperNiceFunction", arg1, arg2, arg3)
A>Не, интересно из Sciter позвать что-то .Net.
Host в принципе должен контролировать вызовы UI.
Идея единственного view.callback (UI <-> BL gate) представляется разумной.
A>Лично моё мнение, что с приходом CSSS! скайтер вообще потерял для .Net какой-либо интерес. Бизнес-логика на двух разных языках — зло. Я даже VB.Net с C# не смешиваю, а тут какой-то TIScript. Динамическая компиляция есть, ASP.Net-образный препроцессор генерирующий HTML сделать — пара пустяков. Я такое написал за день и ещё пару дней прикручивал разные наворотки (см Nabu.Text.Template*). Лично для меня use case вообще не очевиден. То есть если без фанатизма "хачу GUI на Sciter", то я не понимаю почему нельзя или сложнее тоже самое сделать на C#. Не восприми как наезд "гы-гы, ты сделал никому не нужную вещь", у меня опыт быть может и большой, быть может даже и больше чем у других, но специфический, от этого не убежать, и я какие-то вещи могу не понимать. Иногда Андрей что-то делает что я просто не понимаю, он мне говорит, объясняет, как об стенку горох В конце концов я просто принимаю его решения как обстоятельство. Так что давай подумаем можем ли мы продуктивно сотрудничать, куда кому развиваться и что надо от нас народу.
По ряду технических причин DOM в Sciter представлен лучше чем в htmlayout DOM .NET.
Например каждый мой внутренний html::view регистрирует себя как GC callback — т.е. у меня проблема сильных/слабых references не стоит.
Технически изоляция UI name/memory space и BL/DL name/memory space это good thing (tm) — разные времена и ритмы жизни.
Т.е. я бы не был столь категоричен про "потерял для .Net какой-либо интерес".
Я бы скорее говорил про ".Net потерял для Sciter какой-либо интерес" но эту пестню я уже спел не раз
Поскольку есть проект http://code.google.com/p/expemerent/ (надстройка для .NET над Sciter и HTMLayout вместе), где можно УЖЕ реализовать аналогичную идею
анонс потерял актуальность (как и необходимость в таком проекте). Проект удален с GOOGLE.
Здравствуйте, c-smile, Вы писали:
CS>По ряду технических причин DOM в Sciter представлен лучше чем в htmlayout DOM .NET. CS>Например каждый мой внутренний html::view регистрирует себя как GC callback — т.е. у меня проблема сильных/слабых references не стоит.
Собственно, я забыл анонсировать, но мне удалось эту проблему достаточно просто решить. То есть того кошмара с reference counting больше нет.
CS>Технически изоляция UI name/memory space и BL/DL name/memory space это good thing (tm) — разные времена и ритмы жизни. CS>Т.е. я бы не был столь категоричен про "потерял для .Net какой-либо интерес". CS>Я бы скорее говорил про ".Net потерял для Sciter какой-либо интерес" но эту пестню я уже спел не раз
Не, ну Андрей, это не серьёзно Sciter не покрывает возможностей .Net Framework. Про средства разработки и говорить не приходится. HTML Layout Engine это да, актуально, этого нет. Более того, по объективным причинам библиотеки типа HTMLayout или AGG на .Net писать не стоит. Но ещё один скрипт, когда есть DLR? Да ну, нафиг.
Дело даже не в интеропе с unmanaged библиотекой, не в удобстве способа взаимодействия и не в синтаксисе. Дело в том, что при хостинге скрипта, штуки типа CAS делают жизнь радостной. Blizzard внедряя Lua в World of Warcraft перелопатили половину стандартной библиотеки, выкинули некоторые модули, порезали другие. Всё ради того, чтобы аддоны не хакали компьютеры пользователей. Знал бы ты как я намучался с этим кастратом... А в .Net надо 15 минут чтобы вручную настроить AppDomain по своему усмотрению. TIScript не так уж плохо, но зачем? Сейчас, ничто мне не мешает использовать C#, VB.Net, Managed JScript, Boo, IronPython, IronRuby, кучу других языков, даже смешивать их и точно знать, что не будет AV, других багов, что ни один язык не прочтёт файл с диска С и что соединяться они могут только с my-cool-script-host.org:4951, что у них одни и те же региональные настройки. К тому же это всё компилируется. Не, хостить unmanaged скрипт нет абсолютно никакого резона.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, c-smile, Вы писали:
CS>>По ряду технических причин DOM в Sciter представлен лучше чем в htmlayout DOM .NET. CS>>Например каждый мой внутренний html::view регистрирует себя как GC callback — т.е. у меня проблема сильных/слабых references не стоит.
A>Собственно, я забыл анонсировать, но мне удалось эту проблему достаточно просто решить. То есть того кошмара с reference counting больше нет.
CS>>Технически изоляция UI name/memory space и BL/DL name/memory space это good thing (tm) — разные времена и ритмы жизни. CS>>Т.е. я бы не был столь категоричен про "потерял для .Net какой-либо интерес". CS>>Я бы скорее говорил про ".Net потерял для Sciter какой-либо интерес" но эту пестню я уже спел не раз
A>Не, ну Андрей, это не серьёзно Sciter не покрывает возможностей .Net Framework. Про средства разработки и говорить не приходится. HTML Layout Engine это да, актуально, этого нет. Более того, по объективным причинам библиотеки типа HTMLayout или AGG на .Net писать не стоит. Но ещё один скрипт, когда есть DLR? Да ну, нафиг.
Действительно, переборщил. Sciter хорош с С++. Но так-ли хорош С++?
A>Дело даже не в интеропе с unmanaged библиотекой, не в удобстве способа взаимодействия и не в синтаксисе. Дело в том, что при хостинге скрипта, штуки типа CAS делают жизнь радостной. Blizzard внедряя Lua в World of Warcraft перелопатили половину стандартной библиотеки, выкинули некоторые модули, порезали другие. Всё ради того, чтобы аддоны не хакали компьютеры пользователей. Знал бы ты как я намучался с этим кастратом... А в .Net надо 15 минут чтобы вручную настроить AppDomain по своему усмотрению. TIScript не так уж плохо, но зачем? Сейчас, ничто мне не мешает использовать C#, VB.Net, Managed JScript, Boo, IronPython, IronRuby, кучу других языков, даже смешивать их и точно знать, что не будет AV, других багов, что ни один язык не прочтёт файл с диска С и что соединяться они могут только с my-cool-script-host.org:4951, что у них одни и те же региональные настройки. К тому же это всё компилируется. Не, хостить unmanaged скрипт нет абсолютно никакого резона.
Microsoft поставляет Вам расширения для автоматизации действий в виде командных файлов вместе с операционной системой (как Blizzard — Lua для World of Warcraft). Но ведь не приходи в голову
запускать любой CMD файл, который можно скачать из Интернет?
Здравствуйте, vabe, Вы писали:
V>Действительно, переборщил. Sciter хорош с С++. Но так-ли хорош С++?
Для написания некоторых типов библиотек и приложений Си++ не просто хорош, он уникален.
V>Microsoft поставляет Вам расширения для автоматизации действий в виде командных файлов вместе с операционной системой (как Blizzard — Lua для World of Warcraft). Но ведь не приходи в головузапускать любой CMD файл, который можно скачать из Интернет?
Под Вистой? Почему бы и нет? Если что, будет rights elevation запрос. Идея, что программа изначально обладает всеми правами пользователя себя не оправдала. Идея что библиотека обладает всеми правами процесса — тоже. Microsoft активно внедряет идеологию "все мои потомки — засранцы" и это здорово. Я пишу программу, выкладываю SDK и точно знаю что ни один из aддонов написанных кем бы то ни было не украдёт у пользователя пароль ICQ. Ну разве не прелесть?
Здравствуйте, vabe, Вы писали:
V>Поскольку есть проект http://code.google.com/p/expemerent/ (надстройка для .NET над Sciter и HTMLayout вместе), где можно УЖЕ реализовать аналогичную идею V>анонс потерял актуальность (как и необходимость в таком проекте). Проект удален с GOOGLE.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, c-smile, Вы писали:
CS>>По ряду технических причин DOM в Sciter представлен лучше чем в htmlayout DOM .NET. CS>>Например каждый мой внутренний html::view регистрирует себя как GC callback — т.е. у меня проблема сильных/слабых references не стоит. A>Собственно, я забыл анонсировать, но мне удалось эту проблему достаточно просто решить. То есть того кошмара с reference counting больше нет.
CS>>Технически изоляция UI name/memory space и BL/DL name/memory space это good thing (tm) — разные времена и ритмы жизни. CS>>Т.е. я бы не был столь категоричен про "потерял для .Net какой-либо интерес". CS>>Я бы скорее говорил про ".Net потерял для Sciter какой-либо интерес" но эту пестню я уже спел не раз
A>Не, ну Андрей, это не серьёзно Sciter не покрывает возможностей .Net Framework. Про средства разработки и говорить не приходится. HTML Layout Engine это да, актуально, этого нет. Более того, по объективным причинам библиотеки типа HTMLayout или AGG на .Net писать не стоит. Но ещё один скрипт, когда есть DLR? Да ну, нафиг.
"Ай опьять за рибу гроши..."
Это .NET не покрывает возможностей Sciter. Я абсолютно серьёзно.
By default VM алоцирует 2mb+2mb памяти на heap. И например scide за эти пределы и не выходит (7.8mb в памяти). Для сравнения Programmer's notepad (pnotepad.exe) в памяти 3.8mb. Т.е. фактически затраты по памяти это и есть мой преаллоцированный хип (4mb) для скрипта.
Компактность это design goal. Например у тебя elem.attributes это аллоцированный объект в heap (GC и все такое)
а у меня attributes, style, state это просто value (this, interfaceRef). И так далее.
Меньше требований по памяти — менее критичные требования к GC — более простая/компактная имплементация — выше скорость работы (начальная загрузка и в runtime).
Короче, это все зело философично.
"Sciter не покрывает возможностей .Net Framework" — "нонсенс твои слова есть". .Net Framework не покрывает все воможности C++, Windows, Apache, you name it. Нужна возможность добавить ту или иную функциональность (embeddability) и все будет нормально.
"Про средства разработки и говорить не приходится". Тоже спорное утверждение.
Если тебе для имплементации некоей вселенской абстракции требуется пара-тройка классов вместо одной функции то да, появляется потребность в intellisense и class tree. К слову в своих проектах (htmlayout,sciter) я не использую указанные фичи. Как-то нет потребности. Хватает голимого VS6.
"Но ещё один скрипт, когда есть DLR". Начать с того что DLR еще нет по хорошему.
И вообще я не понимаю зачем мне в одном и том же memory space одновременно IronRuby, IronPython, CLR, Interop и прочая...
Желаю видеть мух отдельно от чахахбили. То же самое про UI, логику и DAL.
Здравствуйте, c-smile, Вы писали:
CS>Это .NET не покрывает возможностей Sciter. Я абсолютно серьёзно. CS>By default VM алоцирует 2mb+2mb памяти на heap. И например scide за эти пределы и не выходит (7.8mb в памяти). Для сравнения Programmer's notepad (pnotepad.exe) в памяти 3.8mb. Т.е. фактически затраты по памяти это и есть мой преаллоцированный хип (4mb) для скрипта. CS>Компактность это design goal. Например у тебя elem.attributes это аллоцированный объект в heap (GC и все такое) CS>а у меня attributes, style, state это просто value (this, interfaceRef). И так далее. CS>Меньше требований по памяти — менее критичные требования к GC — более простая/компактная имплементация — выше скорость работы (начальная загрузка и в runtime).
У .Net GC многопоточный и основан на поколениях, а не mark&sweep, так что его запуск не тормозит программу, так что тут как раз TIScript в пролёте. value типы в .Net есть, аргумент мимо кассы. Насчёт требований по памяти... .Net приложения, конечно, любят выделять память впрок, но легко эту лишнюю память отдают ОС при необходимости, так что никакой такой катастрофы с памятью нет.
CS>"Sciter не покрывает возможностей .Net Framework" — "нонсенс твои слова есть". .Net Framework не покрывает все воможности C++, Windows, Apache, you name it. Нужна возможность добавить ту или иную функциональность (embeddability) и все будет нормально.
Ну возможности Windows .Net Framework не покрывает, потому что это ОС и, скажем, Kernel API и не должны быть доступны. Кроме того есть достаточно удобный Interop. Что, разве stdlib покрывает все возможности Windows?
Си++ язык, зачем его сравнивать с библиотекой? Возвожности CRT и STL .Net Framework покрывает.
Что касается Apache, есть WCF — полноценный веб-хостинг не хуже IIS. Собственно, считай, что это IIS 7.0
CS>"Про средства разработки и говорить не приходится". Тоже спорное утверждение. CS>Если тебе для имплементации некоей вселенской абстракции требуется пара-тройка классов вместо одной функции то да, появляется потребность в intellisense и class tree. К слову в своих проектах (htmlayout,sciter) я не использую указанные фичи. Как-то нет потребности. Хватает голимого VS6.
На проектах от 3х человеко-месяцев отсутствие IntelliSence сказывается значительно. У меня друг в 1С шурует, там тоже на IntelliSence большей частью забили. Жутко неудобно.
CS>"Но ещё один скрипт, когда есть DLR". Начать с того что DLR еще нет по хорошему.
CLR есть, значит CAS и прочие прелести налицо.
CS>И вообще я не понимаю зачем мне в одном и том же memory space одновременно IronRuby, IronPython, CLR, Interop и прочая...
Тебе — незачем, проекту в целом, на которым работает много людей, вполне может быть надо. Ядро пишут одни, расширения — другие, возможно на другом языке. Обычное дело в большом проекте.
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, vabe, Вы писали:
V>>Поскольку есть проект http://code.google.com/p/expemerent/ (надстройка для .NET над Sciter и HTMLayout вместе), где можно УЖЕ реализовать аналогичную идею V>>анонс потерял актуальность (как и необходимость в таком проекте). Проект удален с GOOGLE.
CS>А чего так круто?
Так не жалко, поскольку ничего особого и не было... Была идея — попробовал, вроде работает. Обнаружил, что обёртка (для идеи) уже есть.
Зачем плодить одинаковый код и тратить время?
Другое дело, что как-бы попроще "завернуть" в Sciter из .NET перечислимые данные (не в смысле emum-ов). Что-то вроде virtual-grid и data-source.
Получается немного накладно конвертировать длинные массивы в JsonValue для передачи их в качестве параметров (конечно, можно попробовать получать данные частями с помощью вызова функций .NET из Sciter). Вроде логично выглядит, если мы в Sciter передаем данные, то эта передача должна быть максимально оптимизирована. Если у Вас есть какие-нибудь идеи. С удовольствием их выслушаю.
О.. Сообщение прошлое пропало. Придется повторить....
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, vabe, Вы писали:
V>>Поскольку есть проект http://code.google.com/p/expemerent/ (надстройка для .NET над Sciter и HTMLayout вместе), где можно УЖЕ реализовать аналогичную идею V>>анонс потерял актуальность (как и необходимость в таком проекте). Проект удален с GOOGLE.
CS>А чего так круто?
Так если есть уже реализация, зачем повторять? Тем более, что реализация не самоцель. Цель эффект от реализации
Тольк вот есть еще одна проблема. Как эффективно работать с большим кол-вом данных? Передавать их массивами немного накладно. На мой взгляд есть 3 варианта.
1) Отказаться от длинных списков и просматривать страницами (вызывая из Sciter функции .NET)? Заказчики не в восторге от постраничного просмотра...
2) Как-то оптимизировать передачу данных из .NET в Sciter (что-бы не было конвертирования .NET->JsonValue всего массива при передаче)?
3) Вернуть в Sciter возможность создания элементов управления через HWND как в HTMLayout (или оно там есть, просто в другом месте?) и создать легкие обертки для них.
(по сути-то нужен только Grid с возможностью сортировки и фильтрации, ну может Tree)
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, c-smile, Вы писали:
A>У .Net GC многопоточный и основан на поколениях, а не mark&sweep, так что его запуск не тормозит программу, так что тут как раз TIScript в пролёте. value типы в .Net есть, аргумент мимо кассы. Насчёт требований по памяти... .Net приложения, конечно, любят выделять память впрок, но легко эту лишнюю память отдают ОС при необходимости, так что никакой такой катастрофы с памятью нет.
Да понимаешь... если твоя система, как стадо макак, только и умеет что гадить квадратно гнездовым методом то тогда да, тебе нужен супер-пупер многопоточный garbage коллайдер который умеет на нюх различать поколения макакских эскрементов. Но если твоя система состит из индивидов с интеллектом то задача уборки территории состоит в тривиальном опустошении урн и биотуалетов.
Я доходчиво концепт изложил?
CS>>"Sciter не покрывает возможностей .Net Framework" — "нонсенс твои слова есть". .Net Framework не покрывает все воможности C++, Windows, Apache, you name it. Нужна возможность добавить ту или иную функциональность (embeddability) и все будет нормально.
A>Ну возможности Windows .Net Framework не покрывает, потому что это ОС и, скажем, Kernel API и не должны быть доступны. Кроме того есть достаточно удобный Interop. Что, разве stdlib покрывает все возможности Windows?
Вот. Ключевое слово Interop. Interop это бездна в которой тонут все усилия по безопасности (все макаки, см. выше, считают своим долгом чего-нить непотребное засунуть). Не... ну надо делать все из из себя такое managed и оставлять Interop чтобы потом куча умельцев прямо из UI туда лезла.
Между BL/DAL и UI должен быть один gate с простым протоколом "дай данные"/"на тебе данные" — нечто типа http ajax шлюза — чтобы можно было бы зерна от плевел отличать. UI как правило statefull а BL/DAL сугубо функционально stateless — разные времена жизни объектов — разные политики GC и пр.
A>Си++ язык, зачем его сравнивать с библиотекой? Возвожности CRT и STL .Net Framework покрывает.
А детерминирванный С++ очень себя хорошо чувствует на logic layer где он свободен от многопарадигмной каши UI.
Связка SciterUI + С++ на самом деле более устойчивая чем просто "C++ везде" — достаточно глянуть в WTL чтобы ощутить "сиротство как блаженство".
То же самое и про "С# везде" — ну не может чистый OOP язык быть одинаково хорошим и для UI и для логики.
HTMLayout вот получил CSSS! не от хорошей жизни. Все что можно сделать в нём можно сделать и средствами Nabu.
Но руки тянутся к CSSS!, да? По простой собственно причине — UI это просто набор мелких штук типа "enable this when click on that". Мутить
твердотельные классы на каждый такой пук просто технически неоправдано.
A>Что касается Apache, есть WCF — полноценный веб-хостинг не хуже IIS. Собственно, считай, что это IIS 7.0
Кул. Вот там .NETу и место. Там ему хорошо.
CS>>"Про средства разработки и говорить не приходится". Тоже спорное утверждение. CS>>Если тебе для имплементации некоей вселенской абстракции требуется пара-тройка классов вместо одной функции то да, появляется потребность в intellisense и class tree. К слову в своих проектах (htmlayout,sciter) я не использую указанные фичи. Как-то нет потребности. Хватает голимого VS6.
A>На проектах от 3х человеко-месяцев отсутствие IntelliSence сказывается значительно. У меня друг в 1С шурует, там тоже на IntelliSence большей частью забили. Жутко неудобно.
IntelliSense это строгая типизация. Не все задачи в неё одинаково хорошо укладываются.
IntelliSense это удобно, но это понижение порога вхождения со всеми вытекющими. Когда развитие задачи "выходит на редан" то IntelliSense приходится отключать ибо тормозит — быстрее напечатать.
CS>>И вообще я не понимаю зачем мне в одном и том же memory space одновременно IronRuby, IronPython, CLR, Interop и прочая...
A>Тебе — незачем, проекту в целом, на которым работает много людей, вполне может быть надо. Ядро пишут одни, расширения — другие, возможно на другом языке. Обычное дело в большом проекте.
Ну дык и я о том — есть UI его пишем в терминах легко модифицируемо настраиваемых HTML/CSS/Script ибо это величина переменная по определению.
Но есть и логика — некий черно-ящичный-конечный-автомат подключенный к безобразию UI через контролируемый шлюз. И неважно находятся эти UI и логика внутри одного процесса или разнесены по сетке — принципы должны быть те же. Layers придуманы не на пустом месте.
Здравствуйте, c-smile, Вы писали:
CS>Да понимаешь... если твоя система, как стадо макак, только и умеет что гадить квадратно гнездовым методом то тогда да, тебе нужен супер-пупер многопоточный garbage коллайдер который умеет на нюх различать поколения макакских эскрементов. Но если твоя система состит из индивидов с интеллектом то задача уборки территории состоит в тривиальном опустошении урн и биотуалетов. CS>Я доходчиво концепт изложил?
Да, я только не понял почему System.Object тупая макака, а вот объект TIScript — индивид с интеллектом.
CS>Вот. Ключевое слово Interop. Interop это бездна в которой тонут все усилия по безопасности (все макаки, см. выше, считают своим долгом чего-нить непотребное засунуть). Не... ну надо делать все из из себя такое managed и оставлять Interop чтобы потом куча умельцев прямо из UI туда лезла.
Причём тут безопасность? Выключаем через CAS интероп и никто его не сможет использовать. Делов то.
CS>Между BL/DAL и UI должен быть один gate с простым протоколом "дай данные"/"на тебе данные" — нечто типа http ajax шлюза — чтобы можно было бы зерна от плевел отличать. UI как правило statefull а BL/DAL сугубо функционально stateless — разные времена жизни объектов — разные политики GC и пр.
BL и DAL не stateless, потому что транзакция. Хорошо, когда тебе удаётся запихать транзакцию целиком в вызов BL из UI, но такое бывает редко. Кроме того, твой подход приводит к дублированию данных, двойному перерасходу памяти и невозможности использования bindable коллекций.
CS>То же самое и про "С# везде" — ну не может чистый OOP язык быть одинаково хорошим и для UI и для логики.
А кто сказал, что C# — чистый ООП? У C# куча декларативных возможностей.
CS>HTMLayout вот получил CSSS! не от хорошей жизни. Все что можно сделать в нём можно сделать и средствами Nabu. CS>Но руки тянутся к CSSS!, да? По простой собственно причине — UI это просто набор мелких штук типа "enable this when click on that". Мутить твердотельные классы на каждый такой пук просто технически неоправдано.
Для меня дело не в лени, а в single responsibility. Если надо сделать что-то специфичное для UI — я там и сделаю. Красивая анимация — CSSS!, проверка корректности введённых значений — C#. Каждому своё.
A>>На проектах от 3х человеко-месяцев отсутствие IntelliSence сказывается значительно. У меня друг в 1С шурует, там тоже на IntelliSence большей частью забили. Жутко неудобно. CS>IntelliSense это строгая типизация. Не все задачи в неё одинаково хорошо укладываются.
У 1С достаточно строгая типизация, просто, например, параметры метода не типизированы, объект переданный в метод теряет информацию о типе и что делать с параметром не ясно совсем.
CS>IntelliSense это удобно, но это понижение порога вхождения со всеми вытекющими. Когда развитие задачи "выходит на редан" то IntelliSense приходится отключать ибо тормозит — быстрее напечатать.
Когда у тебя 2-3 тысячи классов, ты просто не помнишь что печатать, хотя и догадываешься, ибо предметная область и naming style. Я сам, в своих же программах написанных пол-года, год назад чуть-чуть блуждаю. То есть в принципе понятно что оно и как, но помнить всю иерархию я не в состоянии. Всякие Go to definition, Find References и проч. рулят немеряно.
A>>Тебе — незачем, проекту в целом, на которым работает много людей, вполне может быть надо. Ядро пишут одни, расширения — другие, возможно на другом языке. Обычное дело в большом проекте.
CS>Ну дык и я о том — есть UI его пишем в терминах легко модифицируемо настраиваемых HTML/CSS/Script ибо это величина переменная по определению. CS>Но есть и логика — некий черно-ящичный-конечный-автомат подключенный к безобразию UI через контролируемый шлюз. И неважно находятся эти UI и логика внутри одного процесса или разнесены по сетке — принципы должны быть те же. Layers придуманы не на пустом месте.
В .Net контролируемым шлюзом является observable model, какой-нибудь IBindingList. В Си++ родных событий нет и механизм не прижился.
На самом деле такой шлюз очень удобен, я полностью контролирую все действия UI, могу отменить любое изменение или скорректировать его, с одной стороны. С другой стороны меня не принуждают к формату хранения, коллекция даже не обязательно должна быть целиком в памяти. Я использую это на практике, реально пишу на порядок меньше кода, чем с ручным перекидыванием данных в UI и обратно. Описывается всё тоже замечательно.
MyDataGrid.DataSource = MyCollection;
Он сам вытянет элементы, спросит у коллекции ReadOnly и если да, то спрячет кнопку Add New.
Собственно, если взять Nabu.Collections.BindingListEx вместо стандартного, то там вообще можно творить чудеса
Здравствуйте, vabe, Вы писали:
V>Кстати, если кому-то нужен http://code.google.com/p/expemerent/ исправленный для текущей версии Sciter, я могу поделиться.
Если не сложно, поделитесь; модификацию для WM делали?
Некоторые куски кода явно скопипастены.
У C# куча декларативных возможностей.
