Comments 13
По поводу вызова C# из JavaScript. Обычно используется перехват перехода по ссылке с использованием своего метапротокола. В коде пишутся вещи подобные такой.
Все ссылки с нормальынми протоколами вроде http обрабатываются как положено, а такие парсятся и выполняются как нравится.
document.location = "mycoolprotocol:execute?function=sin&x=1.23"Все ссылки с нормальынми протоколами вроде http обрабатываются как положено, а такие парсятся и выполняются как нравится.
В Webkit.NET вебкит-инспектор судя по всему просто отключили, хотя папка с ресурсами инспектора все еще есть в дистрибутиве.
Еще есть подозрения, что Webkit.NET уже не разрабатывается: последняя версия вышла 30 июня 2011 г. Используется старый рендерер, не поддерживающий аппаратное ускорение и WebGL. Например, вы можете наблюдать там вот такой баг: bugs.webkit.org/show_bug.cgi?id=84245
К минусам можно отнести тот факт, что Webkit.NET основан на сборке Cairo Windows Port, разработкой которого занимается всего один человек, если я не ошибаюсь — github.com/bfulgham/
Еще есть подозрения, что Webkit.NET уже не разрабатывается: последняя версия вышла 30 июня 2011 г. Используется старый рендерер, не поддерживающий аппаратное ускорение и WebGL. Например, вы можете наблюдать там вот такой баг: bugs.webkit.org/show_bug.cgi?id=84245
К минусам можно отнести тот факт, что Webkit.NET основан на сборке Cairo Windows Port, разработкой которого занимается всего один человек, если я не ошибаюсь — github.com/bfulgham/
А какой профит от использования такой «неочевидной» связки вебкита с .NET? Хотелось бы узнать какие плюсы по сравнению с Winforms и WPF?
WPF нет под Mono, а WinForms приложения выглядят под Mono достаточно страшно, так что если возникнет потребность портировать приложение под Mono, то, возможно, будет проще. Но основной плюс, на мой взгляд, заключается в том, что можно иметь идентичный интерфейс на десктопе, в мобильном приложение и вебе. Это стало основной причиной использования такой «неочевидной» связки. Если этого не требуется, то конечно проще разработать приложение на WinForms или WPF.
Webkit уже давно отрисовывает графику с аппаратным ускорением, что, бесспорно, является плюсом в интерфейсостроении.
К тому же между Silverlight и HTML я выберу HTML из-за CSS
И попробуйте на WinForms наклепать больше 40-50 контролов на форму или фоновый рисунок для окна сделать (без костылей и нетривиальных твиков). Тормоза? То-то и оно
К тому же между Silverlight и HTML я выберу HTML из-за CSS
И попробуйте на WinForms наклепать больше 40-50 контролов на форму или фоновый рисунок для окна сделать (без костылей и нетривиальных твиков). Тормоза? То-то и оно
Я вообще много хаков всяких повидал и этот вот
«Чтобы решить эту проблему нам пришлось разработать свой собственный протокол вызовов JavaScript из C#. Идея заключается в следующем:
1. для передачи параметров используется div с заданным идентификатором
2. C# сериализует имя и массив параметров для JavaScript функции в JSON строку и помещает ее в заданный div
3. JavaScript извлекает JSON, десериализует его и вызывает указанную функцию»
точно займет достойное место в коллекции.
Предполагается что это все еще и работает с удовлетворительной скоростью, да?
«Чтобы решить эту проблему нам пришлось разработать свой собственный протокол вызовов JavaScript из C#. Идея заключается в следующем:
1. для передачи параметров используется div с заданным идентификатором
2. C# сериализует имя и массив параметров для JavaScript функции в JSON строку и помещает ее в заданный div
3. JavaScript извлекает JSON, десериализует его и вызывает указанную функцию»
точно займет достойное место в коллекции.
Предполагается что это все еще и работает с удовлетворительной скоростью, да?
Да, работает хорошо. Тем более у нас обычно небольшой JSON передается, так что его сериализация/десериализация не создает никаких проблем.
Честно, я думал я один такой
Sign up to leave a comment.
Об использовании WebKit .NET