# Desenvolvimento do Dynamo Independentemente do nível de experiência, a plataforma do Dynamo foi projetada para que todos os usuários sejam colaboradores. Há diversas opções de desenvolvimento voltadas para diferentes capacidades e níveis de habilidades, cada uma com seus pontos fortes e fracos, dependendo do objetivo. Abaixo, descreveremos as diferentes opções e como escolher uma em detrimento de outra. > Três ambientes de desenvolvimento: Visual Studio, Editor do Python e DesignScript com Blocos de código ### Quais são as minhas opções? As opções de desenvolvimento do Dynamo são divididas principalmente em duas categorias: *para* o Dynamo versus *no* Dynamo. As duas categorias podem ser consideradas semelhantes; “no” Dynamo implica o conteúdo criado usando o IDE do Dynamo para ser usado no Dynamo e “para” o Dynamo implica o uso de ferramentas externas para criar conteúdo a ser importado para o Dynamo para ser usado. Embora este guia se concentre no desenvolvimento *para* o Dynamo, os recursos para todos os processos são descritos abaixo. ### Para o Dynamo Estes nós permitem o maior grau de personalização. Muitos pacotes são criados com esse método e é necessário para contribuir para a origem do Dynamo. O processo de compilação deles será abordado neste guia. * Nós Sem toque * Nós derivados do NodeModel * Extensões > O Manual tem um guia sobre como [Importar bibliotecas Sem toque](https://primer2.dynamobim.org/6_custom_nodes_and_packages/6-2_packages/5-zero-touch). Para a discussão abaixo, o Visual Studio é usado como o ambiente de desenvolvimento para os nós Sem toque e NodeModel. > A interface do Visual Studio com um projeto que desenvolveremos ### No Dynamo Embora esses processos existam no espaço de trabalho de programação visual e sejam relativamente diretos, todos eles são opções viáveis para personalizar o Dynamo. O Manual cobre esses tópicos extensivamente e fornece dicas de scripts e as práticas recomendadas no capítulo [Estratégias de script](https://primer2.dynamobim.org/pt-br/9_best_practices/2-scripting-strategies). * Os Blocos de código expõem o DesignScript no ambiente de programação visual, permitindo fluxos de trabalho flexíveis de scripts de texto e nós. Uma função em um bloco de código pode ser chamada por qualquer item no espaço de trabalho. > Faça o download de um exemplo de bloco de código (clique com o botão direito do mouse e salve como) ou veja um percurso virtual detalhado no [Manual](https://primer.dynamobim.org/07_Code-Block/7-1_what-is-a-code-block.html). * Os nós personalizados são contêineres para coleções de nós ou até mesmo gráficos inteiros. Eles são uma forma eficaz de coletar rotinas usadas com frequência e compartilhá-las com a comunidade. > Faça o download de um exemplo de nó personalizado (clique com o botão direito do mouse e salve como) ou veja um percurso virtual detalhado no [Manual](https://primer.dynamobim.org/10_Custom-Nodes/10-1_Introduction.html). * Os nós Python são uma interface de scripts no espaço de trabalho de programação visual, semelhante aos blocos de código. As bibliotecas Autodesk.DesignScript usam uma notação de ponto similar ao DesignScript. > Faça o download de um exemplo de nó Python (clique com o botão direito do mouse e salve como) ou veja um percurso virtual detalhado no [Manual](https://primer.dynamobim.org/10_Custom-Nodes/10-4_Python.html) O desenvolvimento no espaço de trabalho do Dynamo é uma ferramenta poderosa para obter feedback imediato. > Desenvolvimento no espaço de trabalho do Dynamo com o nó Python ### Quais são as vantagens/desvantagens de cada um? As opções de desenvolvimento do Dynamo foram projetadas para lidar com a complexidade de uma necessidade de personalização. Se o objetivo é escrever um script recursivo no Python ou compilar uma interface de usuário de nó totalmente personalizada, há opções para implementar código que envolvem apenas o que é necessário para começar a trabalhar. **Blocos de código, nó Python e nós personalizados no Dynamo** Essas são opções simples para escrever código no ambiente de programação visual do Dynamo. O espaço de trabalho de programação visual do Dynamo fornece acesso ao Python, ao DesignScript e à capacidade de conter vários nós dentro de um nó personalizado. Com esses métodos, podemos: * Começar a escrever Python ou DesignScript com pouca ou nenhuma configuração. * Importar bibliotecas Python para o Dynamo. * Compartilhar blocos de código, nós Python e nós personalizados com a comunidade do Dynamo como parte de um pacote. **Nós Sem toque** O nó Sem toque é um método simples de apontar e clicar para importar bibliotecas C#. O Dynamo lê os métodos públicos de um `.dll` e os converte em nós do Dynamo. É possível usar o nó Sem toque para desenvolver seus próprios nós e pacotes personalizados. Com esse método, podemos: * Importar uma biblioteca que não foi necessariamente desenvolvida para o Dynamo e criar automaticamente um conjunto de novos nós, como o [exemplo A-Forge](https://primer2.dynamobim.org/pt-br/6_custom_nodes_and_packages/6-2_packages/5-zero-touch#case-study-importing-aforge) no Manual * Escrever métodos C# e usar facilmente os métodos como nós no Dynamo * Compartilhar uma biblioteca C# como nós com a comunidade do Dynamo em um pacote **Nós derivados do NodeModel** Esses nós são um passo mais profundo na estrutura do Dynamo. Eles são baseados na classe `NodeModel` e escritos em C#. Embora esse método forneça a maior flexibilidade e potência, a maioria dos aspectos do nó precisa ser explicitamente definida e as funções precisam residir em uma montagem separada. Com esse método, podemos: * Criar uma interface de usuário de nó totalmente personalizável com controles deslizantes, imagens, cores etc. (por exemplo, nó ColorRange) * Acessar e afetar o que está acontecendo na tela do Dynamo * Personalizar a amarra * Carregar no Dynamo como um pacote ### Entender o controle de versão do Dynamo e as alterações da API (1.x → 2.x) Como o Dynamo está sendo atualizado regularmente, as alterações podem ser feitas em parte da API que um pacote usa. O rastreamento dessas alterações é importante para garantir que os pacotes existentes continuem a funcionar corretamente. As alterações da API são rastreadas no [Wiki do Dynamo no GitHub](https://github.com/DynamoDS/Dynamo/wiki/API-Changes). Isso abrange as alterações no DynamoCore, nas bibliotecas e nos espaços de trabalho. Um exemplo de uma mudança significativa futura é a transição do formato de arquivo XML para o formato JSON na versão 2.0. Os nós derivados do NodeModel agora precisarão de um [construtor JSON](https://github.com/DynamoDS/Dynamo/wiki/Write-a-Json-Constructor-for-a-NodeModel-Node); caso contrário, eles não serão abertos no Dynamo 2.0. A documentação da API do Dynamo atualmente cobre a funcionalidade principal: ### Permissão para distribuir binários em um pacote Esteja ciente de que os .dll estão incluídos em um pacote que está sendo carregado no gerenciador de pacotes. Se o autor do pacote não tiver criado o .dll, ele deverá ter os direitos para compartilhá-lo. Se um pacote incluir binários, os usuários deverão ser informados, ao fazer o download, de que o pacote contém binários. ### Considerações sobre o desempenho da interface do usuário do Dynamo No momento em que este artigo foi escrito, o Dynamo usava principalmente o WPF (Windows Presentation Foundation) para renderizar sua interface do usuário. O WPF é um sistema baseado em xaml/binding complexo e poderoso. Como o Dynamo tem uma interface do usuário complexa, é fácil criar travamentos da interface do usuário, vazamentos de memória ou agrupar a execução do gráfico e as atualizações da interface do usuário de maneiras que degradam o desempenho. Consulte a [Página Wiki de Considerações de desempenho do Dynamo](https://github.com/DynamoDS/Dynamo/wiki/Dynamo-UI-Performance), que ajudará você a evitar algumas armadilhas comuns ao fazer alterações no código do Dynamo.