Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.
Comentário: DI-2679

O projeto do tipo Plugin permite desenvolver, de forma high-code, plugins Cronapp para componentes visuais e blocos de programação cliente ou servidor. 


Dica

Atualmente o Cronapp permite criar blocos de programação servidor customizados de forma low-code, acesse o tópico "Criar blocos low-code customizados" em Bloco de programação e a documentação Importar e exportar bibliotecas

A criação de plugins no Cronapp é de forma high code no momento atual e , através da seleção de modelos, é possível criar plugins do tipo servidor, cliente e componente

.


Novo plugin

Ao clicar no ícone novo botão Novo Projeto (seta da Figura 1), será aberta a janela de criação de projeto. 


Image Added

Figura 1 - Criar plugin na IDE Cronapp


Para criar um plugin,

selecione a opção plugin (1 da Figura 1) na aba high-code, devendo informar um nome para esse plugin  (2 da Figura 1) e selecionar uma fonte (3 da Figura 1). Ao clicar em finalizar, será aberta as janelas de configuração conforme o tipo da fonte selecionada.

siga os passos abaixo:

  1. Tipo do Projeto: selecione a opção "Plugin" na aba "High-code".
  2. Nome do projeto: informe um nome para seu projeto plugin.

  3. Origem do novo projeto:

    • O projeto

Image Removed

Figura 1 - Criar plugin na IDE Cronapp

Projeto
    • está sob controle de versão?

Se o projeto do tipo plugin 
    • : se seu projeto plugin já foi

criado
    • iniciado e está

versionado, deve-se marcar esta opção para abrir a janela controle de versão (Figura 1.1) que importará o projeto.
    • em um servidor Git, marque esta opção e, na próxima tela, informe a URL, a branch e outras informações do repositório (mais detalhes em Importar e exportar projetos).

    • Baseado em Modelo existente: essa opção cria um projeto de plugin com o escopo mínimo necessário.

    • O projeto está em um arquivo ZIP?: permite importar projetos compactados. Após finalizar, outra tela será aberta para selecionar o arquivo (mais detalhes em Importar e exportar projetos).


Ao final, clique em Finalizar.

Âncora
plugin-modelo
plugin-modelo

Baseado em modelo existente

Após selecionar essa opção na tela inicial, será

Image Removed

Figura 1.1 - Janela de controle de versão

  • Protocolo: seleciona o protocolo de controle de versão, nesse caso o GIT;
  • URL do Repositório: informa a URI do repositório que contém o projeto do tipo plugin;
  • Anônimo: ao marcar essa caixa, é possível importar projetos que estejam como públicos sem informar o usuário e a senha;
  • Usuário: informa o usuário do serviço do protocolo, nesse caso o serviço GIT;
  • Senha: informa a senha do serviço do protocolo, nesse caso o serviço GIT;
  • Nome do autor: preenchido automaticamente com os dados cadastrados no Cronapp, é o nome que será informado ao realizar uma atualização no arquivo;
  • Email do autor: preenchido automaticamente com os dados cadastrados no Cronapp, é o e-mail que será informado ao realizar uma atualização no arquivo;
  • Branch: seleciona a branch desejada do projeto.

Baseado em modelo existente

Se o projeto é novo, deve-se marcar esta opção. Será aberta a janela de modelos (Figura 1.21) existentes na IDE para projetos do tipo plugin, podendo ser do tipo componente, cliente para bloco de programação e servidor para bloco de programação.


Image RemovedImage Added

Figura 1.2 1 - Modelos da IDE para criar criar plugins


O projeto está em um arquivo ZIP?

Permite importar projetos do tipo plugin compactados. Será aberta uma janela para selecionar o arquivo no computador do usuário (Figura 1.3).

 Image Removed

Figura 1.3 - Selecionar projeto compactado

Modelos da IDE


Selecione uma das opções e clique em Finalizar.

Modelos de plugins

Os tópicos abaixo apresentam os 3 modelos de projetos pluginsExiste três modelos para criar plugins que são componente visual, cliente para bloco de programação e servidor para bloco de programação e cada um desses modelos tem suas particularidades.

Âncora
modelo-componente-visual
modelo-componente-visual

Plugin de componente visual

Ao selecionar o modelo componente visual (Figura 1.1), será direcionado para a janela de informe dos campos no qual deve ser informado um nome tanto para ID do componente quanto para o nome do componente (Figura 2.1.1).

Image Removed

campos ID do componenteNome do componente Descrição do componente, ambos são gerados automaticamente com base no nome que foi dado ao criar o projeto, mas podem ser alterados (Figura 2).


Image Added

Figura 2 Figura 2.1.1 - Campos para criar componente


Ao finalizar, a estrutura do projeto será mostrada na árvore de arquivos e é criada tanto para mobile quanto para web (Figura 2.1.2). Se o plugin vai ser somente web - basta somente excluir a pasta mobile (mobileapp/) e vice-versa.Image Removed


Image Added

Figura 2.1 .2 - Estrutura do do plugin do tipo componente visual


Por padrão, ambas as pastas apresentam os seguintes arquivos são criados:

Âncora
componente-template-html
componente-template-html

Arquivo *.template.html

O *.template.html, seja ele web ou mobile, deve conter toda estrutura HTML do componente a ser criado (Figura 2.1.32). Ele precisa seguir a nomenclatura padrão:   id_do_componente.template.html e também precisa estar contida na pasta que também vem por padrão (nesse caso, a pasta templatetemplates/).


Image RemovedImage Added

Figura 2.1.3 - Arquivo 2 - Arquivo *.template.html

Âncora
componente-components-json
componente-components-json

Arquivo *.components.json

O *.components.json, seja ele web ou mobile, deve conter todas as propriedades e eventos necessários para o componente a ser criado (Figura 2.1.43). Ele precisa seguir a nomenclatura padrão:   id_do_componente.components.json e também precisa estar contida na pasta que também vem por padrão (nesse caso, a pasta components/).

Dica
Para mais detalhes sobre a estrutura desse arquivo, acesse a documentação Entendendo o Components json.


Image RemovedImage Added

Figura 2.1.4 - Arquivo 3 - Arquivo *.components.json

Âncora
componente-js
componente-js

Arquivo *.js

O arquivo JavaScript, seja ele web ou mobile, onde deve conter toda a parte lógica para o componente a ser criado (Figura 2.1.54). Ele precisa seguir a nomenclatura padrão:   id_do_componente.js e também precisa estar contida na pasta que também vem por padrão (nesse caso, a pasta js/).


Image RemovedImage Added

Figura 2.1.5 4 - Arquivo JavaScript do componente

Âncora
modelo-bloco-cliente
modelo-bloco-cliente

Plugin para bloco cliente

Ao selecionar o modelo plugin cliente para bloco de programaçãoprogramação (Figura 1.1), será direcionado para a janela a janela de informe dos campos (Figura 2.2.1) no qual deve ser preenchido os seguintes campos:3).


Image Added

Figura 3 - Campos para criar bloco cliente


  • Nome do arquivo: campo para informar o nome do arquivo JavaScript a ser criado;.
  • Nome da função: campo para informar o nome da função do arquivo JavaScript a ser criado e que será exibido no bloco quando utilizar o plugin; nome do bloco de programação gerado a partir da primeira função JavaScript.
  • Nome reduzido da função: campo para informar o nome reduzido da primeira função JavaScript do arquivo JavaScript;.
  • Descrição da função: campo para descrever descreve a finalidade da função;.
  • Categoria: campo para criar a categoria em que esse bloco se encontrará quando o plugin for utilizado.

Image Removed

Figura 2.2.1 - Campos para criar bloco cliente


Ao finalizar, a estrutura do projeto será mostrada na árvore de arquivos e contém as pastas webmobile com seus respectivos arquivos JavaScript como também contém os arquivos properties  (Figura 23.2.21). Se o plugin vai ser somente para web - basta somente remover a pasta mobile (mobileapp/) e vice versa.


Image RemovedImage Added

Figura 23.2.2 1 - Estrutura do do plugin do tipo bloco cliente

Arquivo *.cronapi.js

O arquivo JavaScript criado, tanto para web quanto para mobile, precisa seguir a nomenclatura padrão: nome_do_arquivo.cronapi.js e também precisa estar contida na pasta que também vem por padrão (a pasta cronapi/). O código O código base do arquivo criado vem com alguns parâmetros (anotações) tidos como padrão e eles podem ser modificados a depender da necessidade, mas eles são essenciais para garantir a funcionalidade.

Image Removed

Figura 2.2.3 - Arquivo JavaScript

  • @type: define o tipo da função, nesse caso function;
  • @name: nome da função;
  • @description: descrição sobre a funcionalidade da função;
  • @multilayer: define se o componente criado estará disponível tanto no bloco cliente quanto no servidor (true) ou somente no bloco cliente (false);
  • @param: define o tipo do parâmetro de entrada da função, podendo ser LIST, JSON, DOUBLE, DATETIME, DATASET, BOOLEAN, BLOCK ou class;
  • Dica
    Veja mais detalhes sobre as anotações na documentação Criando blocos cliente customizados (mobile e web).


    Image Added

    Figura 3.2 - Arquivo JavaScript

    @returns: define qual o tipo de retorno da função, podendo ser LIST, JSON, DOUBLE, DATETIME, DATASET, BOOLEAN, BLOCK ou class.

    Âncora
    modelo-bloco-servidor
    modelo-bloco-servidor

    Plugin para bloco servidor

    Ao selecionar o modelo plugin servidor para bloco de programação (Figura 1.1), será direcionado para a janela a janela de informe dos campos (Figura 2.3.1) no qual deve ser preenchido os seguintes campos:4).


    Image Added

    Figura 4 - Campos para criar bloco servidor


    • ID do plugin: gerado automaticamente com base no nome do projeto.
    • Nome da classe: campo para informar o nome da classe Java a ser criada;.
    • Nome da função: campo para informar o nome da função da classe Java a ser criada e que será exibida no bloco quando utilizar o plugin; nome do bloco de programação gerado a partir do primeiro método Java.
    • Nome da função reduzida: campo para informar o nome reduzido da função da classe Java; informa o primeiro método Java do arquivo.
    • Descrição da função: campo para descrever descreve a finalidade da função;do método.
    • Categoria: campo para criar a categoria em que esse bloco se encontrará quando o plugin for utilizado.

    Image Removed

    Figura 2.3.1 - Campos para criar bloco servidor


    Ao finalizar, a estrutura do projeto será mostrada na árvore de arquivos. Além da classe Java criada, a estrutura também apresenta o arquivo Maven (pom.xml) e os arquivos properties (Figura 24.3.21).


    Image RemovedImage Added

    Figura 24.3.2 1 - Estrutura do do plugin do tipo bloco servidor

    Arquivo *.java

    O arquivo Java criado precisa seguir a nomenclatura padrão: nome_da_classe.java e também precisa estar contida na pasta que também vem por padrão (a pasta cronapi/). O código O código base da classe vem com alguns parâmetros (anotações) tidos como padrão e eles devem estar incluidos pois garantem incluídos pois garantem a funcionalidade, principalmente a anotação @CronapiMetaData que deve aparecer acima da classe e também acima de cada função método (Figura 4.2.3.3) existente na classe.

    Notatip

    Acessa a documentação sobre anotações Criando blocos servidor customizados para saber mais.


    Image RemovedImage Added

    Figura 24.2 .3 - Arquivo Java

    Arquivo pom.xml

    É o arquivo XML que contém todas as configurações dependências necessárias para que o Maven interaja corretamente com o projeto (Figura 24.2.43).

    Informações

    Para saber mais sobre o Maven, acesse sua documentação oficial.


    Image RemovedImage Added

    Figura 24.2.4 3 - Arquivo pom.xml


    É necessário adicionar a propriedade abaixo no arquivo template.properties para que as dependências Maven do Plugin sejam adicionadas no projeto que instalar o plugin.

    Bloco de código
    firstline1
    titleArquivo template.properties
    linenumberstrue
    maven.dependencies.resolve=true

    Arquivo template.properties

    Todos os modelos apresentarão Qualquer seja o modelo escolhido, ele apresenta o arquivo template.properties que possui informações que podem ajudar no momento da instalação do plugin. O que conteúdo do arquivo pode variar conforme o modelo selecionado, como é o caso do modelo componente visualplugin cliente para bloco de programação que apresentam informações das modificações que ocorrerão nas páginas index.html (web e/ou mobile) do projeto que o plugin for instalado.Basicamente, esses modelos tem em seu conteúdo template.properties no arquivo ele informa o caminho dos arquivos do plugin (src) que serão incluidos no index.html, passando o caminho (resource) dele e eles devem seguir uma ordem (definida pela numeração) e são em pares - ou seja, para cada arquivo no plugin (src) tem que ter seu próprio meio específicado para o index (resource) do projeto que o plugin será instalado (Figura 2.4.1)., através dele é possível definir em quais arquivos do projeto instalado serão feitas as chamadas de Scripts (destaque 1 da figura 5), CSS (2) e Controller (3) ou definir os parâmetros utilizados durante a instalação do plugin. 


    Image Added

    Figura 5 - Arquivo template.properties


    Para cada chamada serão necessárias 2 linhas, na primeira é definida o endereço do arquivo fonte (src) ou (name), enquanto que na segunda linha será informado o endereço do arquivo que irá conter a chamada do arquivo fonte (resource).

    Dica

    Caso seja controller, a sintaxe mudaria de src para name, exemplo: html.<tipo>.<ordem>.name=<arquivo importado>

    html.<tipo>.<ordem>.src=<arquivo importado>  

    html.<tipo>.<ordem>.resource=<arquivo alterado>


    Image Added

    Figura 5.1 - Detalhamento da sintaxe


    1. <tipo>: tipo do arquivo (ex.: script, css ou controller).
    2. <ordem>: ordem de execução, se houver mais de uma chamada do mesmo tipo, deverá conter a numeração diferente em ordem.
    3. <name ou src>: endereço do arquivo importado, que será incluído na chamada.
    4. <resource>: endereço do arquivo a ser atualizado com a chamada.


    Após a conclusão do plugin, que contém o arquivo template.properties conforme mostrado na figura 5, o projeto Cronapp low-code que o instalar terá os arquivos index.html e customModules.js das aplicações web e mobile atualizados, conforme destacado nas figuras abaixo.


    Exemplo de chamada e alteração feita no index.html com a chamada do tipo Script (Figura 5.2).


    Image Added

    Figura 5.2 - Chamada adicionada pelo arquivo template.properties 


    Exemplo de chamada e alteração feita no index.html com a chamada do tipo CSS (Figura 5.3).


    Image Added

    Figura 5.3 - Chamada adicionada pelo arquivo template.properties 


    Exemplo de chamada e alteração feita no customModules.js com a chamada do tipo Controller (Figura 5.4).


    Image Added

    Figura 5.4 - Chamada adicionada pelo arquivo template.properties 


    Nota

    Caso a pasta web ou a pasta mobile tenha sido removida do plugin, deve-se retirar todas as informações existentes no template.properties sobre a pasta removida - ou seja, remove remover o par que faz referência a pasta pasta web ou pasta mobile removida.

    Image Removed

    Figura 2.4.1 - Arquivo template.properties

    Adicionando parâmetros

    É também Também é no arquivo properties que podem ser adicionados parâmetros (destaque da Figura 25.4.25) para que eles sejam serão exibidos no momento da instalação do do plugin no projeto. Por exemplo, um parâmetro que pede a licença. Além de adicionar o parâmetro, é possível paginar e definir a página paginar os campos (ex: .page.1, .page.2.), o tipo do retorno do parâmetro (string, boolean, etc) e sua ordem (0, 1, 2).


    Image Added

    Figura 5.5 - Adicionando parâmetros


    1. Parâmetro que exibirá um campo de entrada de texto (configurado como string);
    2. Parâmetro que exibirá uma caixa de seleção com os valores: "Material", "Celurean" e "Cosmo" (configurado como list);
    3. Parâmetro que exibirá um checkbox (configurado como Boolean).


    Para cada parâmetro são necessárias 2 linhas, na primeira é definido o título do campo, enquanto que na segunda linha será informado um valor padrão.Por exemplo: 

    parameter.page.1<paginação>.string<tipo do retorno>.0<ordem>.license=License<nome do parâmetro>=<nome do campo>

    parameter.page.1<paginação>.string<tipo do retorno>.0<ordem>.license<nome do parâmetro>.value=<type your license>

    Image Removed

    Figura 2.4.2 - Adicionando parâmetros

    Arquivos dinâmicos (.ftl)

    <valor>


    • <paginação>: caso a janela possua várias páginas, é possível definir em qual delas será exibido o campo do parâmetro. No caso de plugins, o padrão é "1".
    • <tipo do retorno>: tipo do retorno do campo do parâmetro (ex.: string, boolean, list). O tipo definirá o tipo do campo: Entrada de texto, caixa de seleção, checkbox e outros.
    • <ordem>: ordem do campo a ser exibido na janela, deve ter o mesmo valor nas 2 linhas.
    • <nome do parâmetro>.
    • <nome do campo>: nome exibido no título do campo.
    • <valor>: valor padrão do campo. No caso lista, os valores devem ser separados pelo caractere "|".


    Durante a instalação do plugin que possua o arquivo template.properties exibido na figura 5.5, a janela de configuração do plugin será exibido como na figura 5.6.


    Image Added

    Figura 5.6 - Campos exibidos a partir da configuração do arquivo template.properties

    Arquivos dinâmicos *.ftl

    É possível criar arquivos dinâmicos através da estrutura do FreeMarker para os mais variados fins. Para isso, deve-se adicionar a extensão ".ftl" Caso os parâmetros sejam utilizados em arquivos, é preciso que eles sejam dinâmicos e, para isso, deve-se transformá-los em arquivos dinâmicos adicionando a extensão .ftl ao final da extensão original do arquivo - ou seja, se o arquivo que vai utilizar o parâmetro é um ".txt então deve adicionara extensão " então é necessário criar o arquivo no projeto plugin com a extensão ".ftl" após o ".txt ficando ", ficando então como "meu_arquivo.txt.ftl " (Figura 2.4.3).6). Após a instalação do plugin, o arquivo criado ficará sem a extensão ".ftl" e as variáveis contidas no arquivo serão substituídas por seus valores.

    Na parte de cima da figura 6 foi criado um arquivo dinâmico que recebe os valores passados por parâmetro durante a instalação do plugin, já na parte debaixo, podemos ver o arquivo gerado a partir do arquivo dinâmico.


    Image Added

    Figura 6 - Arquivo dinâmico e o arquivo gerado a partir do arquivo dinâmico


    Informações

    Para adicionar o parâmetro ao arquivo, ele deve estar no formato: ${nome_do_parâmetro}

    Image Removed

    Figura 2.4.3 - Arquivo .txt dinâmico (.ftl)

    Quando o plugin for instalado ao projeto, o arquivo não irá mostrar a extensão .ftl.

    Arquivos de internacionalização

    Por padrão, são criados dois arquivos de internacionalização para tanto os parâmetros inseridos no template.properties quanto para os parâmetros existentes nos blocos de programação, um em português (template_pt.properties) e outro em inglês (template_en.properties) (Figura 2.4.47), mas podem ser adicionados outros, desde que siga a nomenclatura:   template_sigla<sigla_do_idiomaidioma>.properties ou template_sigla<sigla_do_idiomaidioma>_sigla<sigla_do_paíspaís>.properties (especificando o país do idioma) - ou seja, caso seja adicionado um arquivo para internacionalização do idioma francês, ele poderia ser template_fr.properties ou template_fr_FR.properties (nesse caso, especificando que o francês é o da França).

    Dica

    Acesse o tópico "Arquivos de internacionalização" da documentação Internacionalização para saber mais.


    Image RemovedImage Added

    Figura 2.4.4 7 - Arquivo de internacionalização para o idioma português

    Nessa Nesta página

    Índice
    maxLevel3


    Conteúdo complementar