Pull to refresh

Comments 34

UFO just landed and posted this here
bootstrap для кучи, если самому захочется поэксперементировать, да и что бы понимать как это все устроено
Вот смотрю я на развитие Angular 2 Ionic 2 Это очень близко к WPF. Сейчас для .Net Core нет кроссплатформенного декстопного GUI. Но вот есть идея скрестить Angular 2 и .Net Core. В свое время я сделал обертку для использования классов .Net Core из неуправляемого кода Мои статьи

В обертке реализован доступ к классам из сборок, итераторы, вывод типов для дженериков, методы расширения, поддержка событий. То есть можно писать код близкий к C# на 1С. К моему огромному сожалению 1С это оказалось не нужно. В том плане, что они не хотят модернизировать Native Api для передачи в параметрах объектов и возврате объектов из методов. Поэтому ссылки на объекты передаются виде строки и из которых создаются объекты ВК. Это очень неудобно.

Но вот подумалось, что эту технологию можно прикрутить к браузеру через плагин. То есть можно создавать обертку на стороне браузера. При этом можно для TypeScript генерить интерфейсы (в свое время предлагал псевдоинтерфейсы для динамиков в .Net) и использовать IntelliSense на полную катушку. То есть можно как в Xamarin писать единую общую часть в Dll, а GUI писать отдельно. Я знаю, что 1С использует технологию «Создание компонент с использованием технологии Native API». и в Web клиенте через плагины. Буду благодарен за конструктивную критику, идеи и ссылки на создание плагинов.
Не знаю конечно, как для веба, все таки там и обычная связка с вторым Ангуляром отлично работает, а вот скрестить что-то похожее на Electron.js, второй Ангуляр и .NET, это было бы интересно)
спасибо. Интересно. Сейчас стал изучать хромовский Native Client SDK

Скачал по ссылке https://developer.chrome.com/native-client/sdk/download хромовского клиента.
Нашел часто используемую структуру в файле ..\nacl_sdk\pepper_49\include\ppapi\c\ppVar.h

typedef enum {
   /**
   * Represents a JavaScript object. This vartype is not currently usable
   * from modules, although it is used internally for some tasks. These objects
   * are reference counted, so AddRef() and Release() must be used properly to
   * avoid memory leaks.
   */
  PP_VARTYPE_OBJECT = 6,


Эх теперь с С разбираться.
Выложил на обсуждение свое видение
Использование в TypeScript классов .Net
Суть в том, что используя Native Client Messaging System, Proxy и Promise vs можем вызывать методы .Net классов асинхронно через await

   
  let HttpClient=await NetWrap.GetType("System.Net.Http.HttpClient","System.Net.Http.dll"); 
     let HttpClientHandler = await NetWrap.GetType("System.Net.Http.HttpClientHandler","System.Net.Http.dll"); 

    let client=await NetWrap.new(HttpClient); 
    let responst= await (await client.GetStringAsync("https://msdn.microsoft.com/ru-ru/library/hh551745(v=vs.118).aspx")).Result(); 
//Result вызываем как функцию 


Для чего это нужно.

Возьмем пример нынешнего Xamarin. Xamarin.Forms очень беден, поэтому многие делают общую логику отдельно (которая может быть сложной),
а морду рисуют для каждой ОС отдельно.

Сейчас для отличных от Win декстопов нет UI.
Но например у тебя есть приложение на UWP или WPF. Можно выделить логику отдельно, а морду нарисовать на Angular 2
Разница использования .Net кода только в том, что все методы асинхронные. При этом можно подписываться к событиям 1С,.Net Core. Динамическая компиляция класса обертки для получения событий .Net объекта в 1С. Для Вэб апи нужно городить SignalR или WebSocket.
То есть перенести приложение достаточно легко, в отличие от web api-host.

То есть вы даже не догадались Task переводить в promise?

Это просто набросок. Кроме того Task можно использовать через ContinueWhith или WhenAll итд

А у вас уже реализована нормальная передача из js-кода в .Net-код делегатов?

У меня есть только взаимодействие 1С с .Net Core. Но пока все это в стол. Хотя есть на стороне .Net поддержка и параметы массивы, ref параметры, автовывод дженерик типов, поиск методов расширений и опять же с дженериками.
Подержка событий через динамическую компиляцию оберток для событий. Просто так или иначе я один не то что не потяну, а нет смысла писать в стол.
А реализовать можно взаимодействие и с JS объектами через DynamicObject по аналогии с COM объектами http://infostart.ru/public/466196/
Просто нет подсчета ссылок, но можно только на время вызова держать ссылку
Кроме того можно динамически скомпилировать нужный класс подписаться на событие из него получить ссылку на делегат и передать эту ссылку.
 static Delegate ПолучитьДелегатПоТипу(IPropertyOrFieldInfo Свойcтво)
        {
            var ReturnType = Свойcтво.GetPropertyType();

            if (ReturnType == typeof(Action<string, string, object>)) return new Action<string, string, object>(ВызватьВнешнееСобытиеСОбъектом);

            if (ReturnType == typeof(Action<string, string, string>)) return new Action<string, string, string>(AutoWrap.ВызватьВнешнееСобытие1С);

            throw new Exception("Не не нужного типа  " + ReturnType.ToString());
        }
        public static void УстановитьДелегатДляВызоваВнешнегоСобытия(object объект, string ИмяДелегата)
        {

            var Свойcтво = НайтиСвойство(объект, ИмяДелегата);
            var value = ПолучитьДелегатПоТипу(Свойcтво);

            Свойcтво.SetValue(объект, value);
        }


Но можно ввести служебное слово например async

 let response= await client.async.GetStringAsync("https://msdn.microsoft.com/ru-ru/library/hh551745(v=vs.118).aspx")

В этом нет смысла. Достаточно проверять возвращаемое значение на Task и отдельно его обрабатывать.

Смысл есть. Опять же мне нужен массив для Task.WhenAll. Кроме того это лишнее взаимодействие между нативом и Net. Не все так просто. То есть нужно в натив возвращать флаг, что это Task для того, что бы натив не вызывал событие, передавал ключ в Net а дальше для задачи вызывался await или ContinueWhith с событием которое вызывает метод натива с передачей ключа и результата.

Мне лично await client.async.GetStringAsync нравится.
Кроме того для дженерик методов где нельзя вывести тип у меня применяется in
например
C# вариант
var HtmlAnchorElement = document.QuerySelector<IHtmlAnchorElement>(rowSelector);


может выглядеть так

let HtmlAnchorElement = avait doc.in(IHtmlAnchorElement).QuerySelector(rowSelector));


Кроме того иногда нужно получить интерфейс (у него свои методы)

let obj= await obj.as("IEnumerable");
или
let obj= await obj.as(IEnumerable);

Вам не нужен Task.WhenAll потомучто есть Promise.all

Понятно, но это уже дикое смешение. На самом деле хоть какой то вариант заработал. Но проблема в том, что я 1С ник и занимаюсь в всободное время. .Net знаю неплохо, но вот с С++ и С очень мало практики. Кроме того привык к VS а например Debugging with Visual Studio только для VS 2010 и 2012. Под 2012 у меня не получилось скомпилировать даже пример. Но по обсуждению я так понимаю, что мало кому это нужно. А время на это тратить нужно и не мало. И больше не на реализацию, а на обучение плагинописанию.
Почитал, это все очень интересно. Можно подключать любую class Library с асинхронными методами?
Еще я нашел вот такой вот интересный проект: Edge.js, правда не знаю, как у него с производительностью и использованием памяти.

Нет, его решение позволяет подключить любую class Library с синхронными методами и (важно!) без событий и обратных вызовов.

А с другой стороны, было бы интересно иметь возможность работы как асинхронно, так и синхронно, при этом имея возможность удобно маппить объекты TS в объекты c#(пусть и в виде DTO, уже что-то), и вызывая любую функцию с любой сигнатурой, а не Func<object,Task
На счет событий и асинхронного кода у меня есть статьи 1С,.Net Core. Динамическая компиляция класса обертки для получения событий .Net объекта в 1С

.Net Core, 1C, динамическая компиляция, Scripting API

Асинхронное программирование в 1С через .Net Native ВК

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

 public static object СоздатьОберткуДляСобытий(Object ОбъектССобытиями)
        {

            Type тип = ОбъектССобытиями.GetType();
            Type genType = typeof(КомВраперДляСобытий<>);
            Type constructed = genType.MakeGenericType(new Type[] { тип });
            var ИмяСвойства = "СоздательОбертки";

              var fi = constructed.GetField(ИмяСвойства);
              Delegate функция = (Delegate)fi.GetValue(null);
             // Получили делегат
             // И из него получим объект обертку для событий который передадим в 1С для хранения ссылки на него
            object обертка = функция.DynamicInvoke(new Action<string,string,object>(ВызватьВнешнееСобытиеСОбъектом), ОбъектССобытиями);
            return обертка;

        }


Правда пока обертка делается ко всем событиям. Но можно ограничить.
Я 16 лет занимаюсь разработкой на 1С, немного меньше на C#.
НО! Никогда не пытаюсь смешивать английский и русский в коде. Ведь всего-то надо подумать о названии метода по английски и освоить для себя <summary/>.
А то, задумайтесь, как 1С-программист, как бы вы работали с модулями конфигурации, если бы часть переменных и методов были на английском, часть на французском, а все то, что касается встроенного языка (и прикладных объектов) — по-русски.
Так-то и именование методов в lowerCamelCase: sendEcho, addMessage, etc. — какой-то Java-style.
Там суть такова, что для JSON и наименования методов практикуется Кэмел нотация. А на стороне клиента все методы будут в Кэмел. Поэтому, что бы не путаться проще задать им названия сразу в Кэмел
Там же вроде как есть аттрибут для именования полей со стороны клиента(Именуем в Паскаль кейс, вешаем аттрибут для клиентского именования и вуаля).
Можно и так. Просто я в статье ориентировался на интерфейс который создавался на стороне Asp.Net и по нему создавался класс на TS. В дальнейшем можно кодогенератор прикрутить как для TS так и .Net клиентов
А у меня так повсеместно. Я использую Использование классов .Net в 1С для новичков. А там все классы на английском.
Кроме того и сама 1С использует Руслиш. HttpСоединение, ФабрикаXDTO, ЗаписьXML итд.
Просто привыкаешь самодокументироваться на русском.
Просто я не очень хорошо знаю английский, поэтому мне приходится тратить время на осмысленные названия. И при этом давать комментарии на русском.
Не стоит так делать. Стиль 1С — не лучшая практика. С# далеко не 1С, может стоит в нем придерживаться стандартов(английские название, camelcase, etc.)?
Так в этой статье всего один метод и один параметр.
Кроме того самодокументация лучше чем английское название и русский комментарий, особенно сложных названий, там где на английском будет неоднозначное определение. Но я уже кучу копий по поводу руслиша сломал. Можно почитать все предыдущие статьи.
В статье нет упоминания, как добавить SignalR в проект .Net Core. А между тем, на данный момент это не такая простая задача. Так что, статья точно не «для чайников».
Согласен. Упустил. На данный момент есть описание для .VS 2017 с Angular 2
Но и тогда можно найти в интернете Real-time applications using ASP.NET Core, SignalR & Angular


Единственно, что нужно добавить либо в студии в диспетчере пакетов NuGet источники пакетов ссылку на

Asp.Net Core NuGet «https://dotnet.myget.org/F/aspnetcore-ci-dev/api/v3/index.json» /

либо в NuGet.config file

<packageSources>
    <add key="AspNetCore" value="https://dotnet.myget.org/F/aspnetcore-ci-dev/api/v3/index.json" />
    <add key="NuGet" value="https://api.nuget.org/v3/index.json" />
  </packageSources>


А все ссылки на нужные пакеты есть в project.json
Sign up to leave a comment.

Articles