O projeto do tipo Plugin permite desenvolver, de forma high-code, plugins Cronapp para componentes visuais e blocos de programação cliente ou servidor.
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. |
Ao clicar no botão Novo Projeto (seta da Figura 1), será aberta a janela de criação de projeto.
Figura 1 - Criar plugin na IDE Cronapp
Para criar um plugin, siga os passos abaixo:
Nome do projeto: informe um nome para seu projeto plugin.
Origem do novo projeto:
O projeto está sob controle de versão?: se seu projeto plugin já foi iniciado e está 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.
Ao final, clique em Finalizar.
Após selecionar essa opção na tela inicial, será aberta a janela de modelos (Figura 1.1) existentes na IDE para projetos do tipo plugin.
Figura 1.1 - Modelos da IDE para criar plugins
Selecione uma das opções e clique em Finalizar.
Os tópicos abaixo apresentam os 3 modelos de projetos plugins.
Ao selecionar o modelo componente visual (Figura 1.1), será direcionado para a janela de informe dos campos ID do componente, Nome do componente e 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).
Figura 2 - 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). Se o plugin vai ser somente web - basta somente excluir a pasta mobile (mobileapp/
) e vice-versa.
Figura 2.1 - Estrutura do plugin do tipo componente visual
Por padrão, ambas as pastas apresentam os seguintes arquivos:
*.template.html
O *.template.html
, seja ele web ou mobile, deve conter toda estrutura HTML do componente a ser criado (Figura 2.2). 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 templates/
).
Figura 2.2 - Arquivo *.template.html
*.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.3). 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/
).
Para mais detalhes sobre a estrutura desse arquivo, acesse a documentação Entendendo o Components json. |
Figura 2.3 - Arquivo *.components.json
*.js
O arquivo JavaScript, seja ele web ou mobile, deve conter toda a parte lógica para o componente a ser criado (Figura 2.4). 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/
).
Figura 2.4 - Arquivo JavaScript do componente
Ao selecionar o modelo plugin cliente para bloco de programação (Figura 1.1), será direcionado para a janela de informe dos campos (Figura 3).
Figura 3 - Campos para criar bloco cliente
Ao finalizar, a estrutura do projeto será mostrada na árvore de arquivos e contém as pastas web e mobile com seus respectivos arquivos JavaScript como também contém os arquivos properties
(Figura 3.1). Se o plugin vai ser somente para web - basta somente remover a pasta mobile (mobileapp/
) e vice versa.
Figura 3.1 - Estrutura do plugin do tipo bloco cliente
*.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 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.
Veja mais detalhes sobre as anotações na documentação Criando blocos cliente customizados (mobile e web). |
Figura 3.2 - Arquivo JavaScript
Ao selecionar o modelo plugin servidor para bloco de programação (Figura 1.1), será direcionado para a janela de informe dos campos (Figura 4).
Figura 4 - 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 4.1).
Figura 4.1 - Estrutura do plugin do tipo bloco servidor
*.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 base da classe vem com alguns parâmetros (anotações) tidos como padrão e eles devem estar incluídos pois garantem a funcionalidade, principalmente a anotação @CronapiMetaData que deve aparecer acima da classe e também acima de cada método (Figura 4.2) existente na classe.
Acessa a documentação sobre Criando blocos servidor customizados para saber mais. |
Figura 4.2 - Arquivo Java
pom.xml
É o arquivo XML que contém todas as dependências necessárias para que o Maven interaja corretamente com o projeto (Figura 4.3).
Para saber mais sobre o Maven, acesse sua documentação oficial. |
Figura 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.
maven.dependencies.resolve=true |
template.properties
Todos os modelos apresentarão o arquivo template.properties
, 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.
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
).
Caso seja controller, a sintaxe mudaria de src para name, exemplo: |
html.<tipo>.<ordem>.src=<arquivo importado>
html.<tipo>.<ordem>.resource=<arquivo alterado>
Figura 5.1 - Detalhamento da sintaxe
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).
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).
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).
Figura 5.4 - Chamada adicionada pelo arquivo template.properties
Caso a pasta web ou a pasta mobile tenha sido removida do plugin, deve-se retirar todas as informações existentes no |
Também é no arquivo properties
que podem ser adicionados parâmetros (destaque da Figura 5.5) que serão exibidos no momento da instalação do plugin. Por exemplo, um parâmetro que pede a licença. Além de adicionar o parâmetro, é possível paginar os campos (ex: .page.1, .page.2.), o tipo do retorno do parâmetro (string, boolean, etc) e sua ordem (0, 1, 2).
Figura 5.5 - Adicionando parâmetros
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.
parameter.page.<paginação>.<tipo do retorno>.<ordem>.<nome do parâmetro>=<nome do campo>
parameter.page.<paginação>.<tipo do retorno>.<ordem>.<nome do parâmetro>.value=<valor>
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.
Figura 5.6 - Campos exibidos a partir da configuração do arquivo template.properties
*.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
" ao final da extensão original do arquivo - ou seja, se o arquivo é um ".txt
" então é necessário criar o arquivo no projeto plugin com a extensão ".ftl
" após o ".txt
", ficando então como "meu_arquivo.txt.ftl
" (Figura 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.
Figura 6 - Arquivo dinâmico e o arquivo gerado a partir do arquivo dinâmico
Para adicionar o parâmetro ao arquivo, ele deve estar no formato: ${nome_do_parâmetro} |
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 7), mas podem ser adicionados outros, desde que siga a nomenclatura: template_<sigla_do_idioma>.properties
ou template_<sigla_do_idioma>_<sigla_do_paí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).
Acesse o tópico "Arquivos de internacionalização" da documentação Internacionalização para saber mais. |
Figura 7 - Arquivo de internacionalização para o idioma português