Announcement

Collapse
No announcement yet.

Documentation of how to make a plugin

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

    Documentation of how to make a plugin

    Hello I would like to create a plugin for my ajax atutomaticamente. Already I realized I have to refer to "Bridge.Builder.dll" abistrair the "IPlugin" or Class "AbstractPlugin" then compiled and placed in the "Bridge \ plugins" just did not.
    I would also use the debugger.

    Thank you

    Original em Português
    Documentação de como fazer um plugin

    Olá gostaria de fazer um plugin para criar meu ajax atutomaticamente. Ja percebi que tenho que referenciar a "Bridge.Builder.dll" abistrair a "IPlugin" ou Classe "AbstractPlugin", depois compilei e coloquei na pasta "Bridge\plugins" só que não funcionou.
    Gostaria de usar o debugger tambem.

    Obrigado

    #2
    Hello rafaelleonel! Welcome to Bridge.NET forums!

    Nem sempre que você quer criar um plugin para suportar sua biblioteca AJAX é preciso utilizar o IPlugin e acessar ao Builder (compilador). Não sei exatamente o que quis dizer com "criar meu ajax automaticamente" mas acredito que o que você precise aí é implementar a interface C# para o JavaScript correspondente só. Ou seja, construir suporte Bridge.Net à sua biblioteca. De repente, se você tiver um exemplo (simplificado) do que você quer fazer, ajudaria a entendermos sua necessidade.

    Sobre o debugger, por enquanto não temos suporte a source maps do código JavaScript gerado, está na nossa lista de tarefas para implementarmos no médio prazo. Mas se a dúvida é usar o debugger para depurar a própria compilação do código C# -> JS, você pode utilizar o debugger se compilar o Bridge.NET a partir do código fonte (em inglês).

    (english)
    User question was:
    - Would like to create a plugin to make my AJAX code automatically. I noticed I have to reference "Bridge.Builder.dll", "IPlugin" or "AbstractPlugin" and then build and add it to "Bridge\plugins" but it didn't work. I wanted to use the debugger as well.

    Reply (translated from above)
    Not always when one wants to make a plugin to support your AJAX library is necessary to use IPlugin to access Bridge Builder (compiler). Not sure exactly what you meant with "create my AJAX code automatically" but I believe that you just want to implement a C# interface for the JavaScript corresponding code. In other words, implement Bridge.Net support to your library. Maybe if you have a simplified sample illustrating what your want to achieve, it would help us to understand your needs.

    About debugger, we don't have support for source maps in the generated JavaScript code yet. It is in our priority list to implement in the middle term. But if the matter is to debug the builder itself, you may use the debugger if you build Bridge.NET from sources.

    Comment


      #3
      Hello thanks for the reply :D
      But really can not explain quite what I wanted, I will try by code.

      Class common use
      class ObjTeste1 : Server<Interfaces.IObjTeste1>
          {
              public ObjTeste1()
              {
                  Window.Alert(this.Server.TesteCall("Teste"));
              }
          }
      Interface in a project part (to be used on the server as well)
      public interface IObjTeste1
          {
              string TesteCall(string vTexto);
          }
      Class to facilitate ajax (the same Test1 object of the project)
      class Server<T>
      {
              [Ignore]
              public T Server{get;set;}
      
              // Here would have to create the methods of the "T"
              // interface for varial Server
      }
      I wanted to create a plugin to automatically create the methods of the generic type "T" already with ajax.

      __________________________________________________ ___________________________

      (Original em português)
      Olá obrigado pela resposta :-D
      Mais realmente não consegui explicar bem o que eu queria, vou tentar por código.

      Class uso comum
      class ObjTeste1 : Server<Interfaces.IObjTeste1>
          {
              public ObjTeste1()
              {
                  Window.Alert(this.Server.TesteCall("Teste"));
              }
          }
      Interface em um protejo a parte (Para ser usada na parte server também)
      public interface IObjTeste1
          {
              string TesteCall(string vTexto);
          }
      Class para facilitar ajax (No mesmo projeto do ObjTeste1 )
      class Server<T>
      {
              [Ignore]
              public T Server{get;set;}
      
              // Aqui teria que criar os metodos da interface "T"
              // para a varial Server 
      
      }
      Queria criar um plugin para criar automaticamente os métodos do tipo genérico "T" já com o ajax.

      Comment


        #4
        Olá, ainda não consegui entender bem o que você quer fazer. Em reunião com o resto da equipe, mostrei o tópico pra eles e também não ficou muito claro pra nós seu objetivo. Então vamos tentar explorar mais a sua idéia para que entendamos.

        Já existe tratamento de métodos genéricos no Bridge.NET, então você (a princípio) não precisa fazer um plugin só pra essa funcionalidade. Você define o método/classe genérica, e quando a utilizar, Bridge já emite (esperamos que) o código correto. Já que JavaScript não é fortemente tipada, muitas vezes você pode reparar numa chamada genérica que não exista uma especificação do tipo.

        Mas provavelmente você já tenha percebido que Bridge.NET manipula tipos genéricos., e ainda assim queira fazer algo específico que não ficou muito claro quando disse "criar automaticamente os métodos do tipo genérico "T" já com o ajax". Não entendi exatamente a frase e também o significado que você associou ao termo AJAX neste caso. Eu pessoalmente entendo AJAX como um conjunto de técnicas empregadas para tornar uma página dinâmica. Algo utilizado no nosso exemplo Async-await, por exemplo.

        Talvez se você mostrasse o código no Bridge.NET e o código que você esperasse sair no JavaScript ajudasse-nos a entender. Outra idéia seria um exemplo escrito na interface Live Bridge, mostrando o que falta para seu cenário funcionar.

        Ou, talvez o foco interessante aqui seja simplesmente um pedido para que façamos um guia sobre como construir o seu próprio plugin no Bridge.NET sem necessariamente entendermos o seu objetivo. Afinal, estamos querendo saber seu objetivo porque possivelmente existe alternativas de conseguir fazer o que quer sem necessidade de construir plug-ins.

        Atualmente temos um guia sobre como adicionar suporte a novos frameworks JavaScript (algo como fazer um novo pacote Bridge.jQuery2 -- mas para outra biblioteca JS). Só faltam algumas poucas revisões para que tenha aprovação de ficar disponível ao público.

        (english)
        Hello, I still don't understand well what you want to achieve. During our meeting I asked the rest of the team if any of them could understand your request and nobody had a very clear idea on what that was. So, well, lets try and explore more your question so we can understand it.

        There's already means to treat generic methods/classes in Bridge.NET so you (in a first thought) don't need to make a plugin for this functionality. You define the generic method/class and when you use it in your code, Bridge.NET emits (hopefully) the expected code. As JavaScript is not strongly typed, sometimes you can notice some calls to generics do not have a type specification nor cast.

        But probably you already noticed it and still you want something specific that was not really clear to us when you used the phrase "automatically create the methods of the generic type "T" already with ajax". Specificly I am not quite sure on the meaning you bound to AJAX in your phrase. To me AJAX is just a group of techniques applied to imbue a page with dynamic content. One example of AJAX use could be our async-await Bridge.NET example.

        Maybe if you show the Bridge.NET code and what you expected to show up in JavaScript might help us understand your needs. Another idea would be a sample written in the Live Bridge interface, showing what is left in order to your scenario to work.

        Or, even just leave this thread as a feature request to make a nice howto write a Bridge.NET plugin. Not necessarily knowing what your really want to do here. After all, we want to understand your objective just to evaluate whether there's an easier way thru it without making plug-ins.

        Actually, we have a howto to add JavaScript frameworks to Bridge.NET. Something like making a new Bridge.jQuery2 package -- but for another JS lib. There's just a few reviews left and the howto will be publicly available.

        Comment


          #5
          I think I understand what he is wanting to do. Let me take a shot at this and I will let somebody else either translate to Portuguese via translator or if they can do it natively better than a translator can.

          TestCall is a method that resides on the server. When you call Server.TestCall in your C# Bridge.Net Application something generates the necessary boilerplate code to call the method on the server.

          Doing this is more complex and involved than one might originally have thought. This requires that you expose your class (Server) to the web for consumption.
          Common examples of this would be exposing the Server class through WebPI, an MVC or a WCF Service.

          To consume this you would need to make several assumptions (some of these assumptions can be driven by decorating classes with attributes perhaps).
          Knowing where this method is exposed to the web
          Knowing how this method is exposed to the web

          When the code for the method call of Server.TestCall is being executed Bridge.Net would instead replace the following
          Window.Alert(this.Server.TesteCall("Teste"))
          with something like
          window.alert($.ajax('/Server/TesteCall/', { "vTexto" : "Teste" });

          I think that rafaelleonel is asking about what would need to be done too hook into making the above transformation happenand potentially the generation of any server side boilerplate code required. The latter is far more difficult though could probably be accomplished transparently through WCF and maybe some T4 templating.

          I think/feel I more understood the problem being described and less the actual question being asked.
          Last edited by TheSpiceMustFlow; 2015-12-06 @ 03:51 PM.

          Comment


            #6
            Ah came pretty close even ^^ Thank you !!
            I am actually quite studied the bridge and acheguei the conclusion that the only ject to do this is using an "interface" to ensure equality in the client and server. The problem is that bridge still does not export the methods of the "interface" to the javascript still, and also does not read any external references. I will have to wait for these resources to be able to use the bridge.
            Thanks for attention.

            _____________________________
            Português(Brasil)

            Ahh chegou bem perto mesmo ^^ Obrigado !! ;)

            é na verdade estudei bastante o bridge e acheguei a conclusão que o unico jeto de fazer isto é usando uma "interface" para garantir igualdade no client e server. O problema é que bridge ainda não exporta os metodos da "interface" para o javascript ainda, e tambem não lê referencias externas. Vou ter que aguardar estes recursos para poder usar o bridge.

            Muito obrigado pela atenção. :)

            Comment


              #7
              The problem is that bridge still does not export the methods of the "interface" to the javascript still
              Created an Issue:
              https://github.com/bridgedotnet/Bridge/issues/784

              and also does not read any external references
              Could you, please, elaborate on this comment with any details?

              Comment


                #8
                The problem is that bridge still does not export the methods of the "interface" to the javascript still
                Could you, please, also clarify a use case for emitting an "interface" to JavaScript?



                Comment


                  #9
                  Re: emitting interfaces to JavaScript

                  Currently, we don't know any use case except Reflection which is not supported and is not going to supported in Bridge v1. Fortunately, Reflection is already supported in Bridge v2.0 (private still) and most likely the issue will just disappear with Bridge v2.0 release. We leave the issue open to review in the future with releasing v2.0.

                  Comment


                    #10
                    Hi rafaelleonel,

                    In response to your post regarding type information of intefaces, Bridge (since v15.0) supports reflection.

                    You can read interface members info like you do in .Net.
                    http://deck.net/d924162947ee6188b31ea76f916802df:
                    public class Program
                    {
                        public static void Main()
                        {
                            var members = typeof(Interface1).GetMembers();
                            
                            foreach (var m in members)
                            {
                               Console.WriteLine(m.Name);
                            }
                        }
                    }
                    
                    [Reflectable]
                    public interface Interface1
                    {
                        int Count { get; set; }
                        void DoSomething();
                    }
                    Please note attribute [Reflectable]. By default, to minimize generated output, Bridge does not emit reflection data.
                    To enable it, just apply the attribute on types required, on assembly or in bridge.json config (more info here).

                    Comment

                    Working...
                    X