## 🥷 FWWebEx deixou de ser brinquedo de criança.
Faz algum tempo que não publico nada sobre **FWWebEx**.
> Talvez alguém pudesse interpretar o silêncio como falta de evolução.
Aconteceu exatamente o contrário.
O projeto cresceu a ponto de eu precisar mudar a maneira como penso sobre ele.
> No começo, FWWebEx nasceu de uma ideia relativamente simples:
>> **E se pudéssemos ultrapassar algumas limitações da interface tradicional do Protheus usando HTML, CSS e JavaScript — sem abandonar o ecossistema Protheus?**
* Era laboratório.
* Era experimentação.
* Era aquele tipo de projeto em que você pensa:
> *“Será que dá para fazer?”*
Hoje a pergunta mudou.
> **“Como garantir que isso continue funcionando quando ficar grande?”**
Essa mudança parece pequena.
Em engenharia de software, ela muda tudo.
---
### 🔥 O FWWebEx Labels foi o ponto de virada
Tudo começou com uma necessidade extremamente comum no Protheus:
**imprimir rótulos.**
Quem já precisou fazer isso com `FWMsPrinter` provavelmente começou a rir antes mesmo de terminar a frase. 😂
O que inicialmente seria apenas mais uma feature do FWWebEx começou a exigir:
**Designer visual → Layout Engine → Contrato → Renderer → PDF → Preview → Testes**
> E cada camada trouxe novos problemas.
* Posicionamento.
* Containers.
* Margens.
* Rotação.
* Fontes.
* Overflow.
* Barcode.
* Background.
* Zoom.
* Smart Snap.
* Undo.
* Isolamento entre componentes.
* Performance.
> Até que surgiu a pergunta inevitável:
>> **O que estou vendo no Designer é realmente aquilo que será impresso?**
Responder *“parece que sim”* deixou de ser aceitável.
---
## 🧪 “Parece igual” não é um teste.
Hoje o FWWebEx Labels possui uma suíte que verifica muito mais do que funções isoladas.
* O contrato do layout é testado.
* O Layout Engine é testado.
* O Designer é testado.
* O Renderer é testado.
* Barcodes são testados.
* Transformações geométricas são testadas.
* Containers e margens são testados.
* Smart Snap é testado.
* Undo é testado.
* Múltiplas instâncias são testadas.
> Até o custo de serialização durante o **drag com um background Data URI de 2 MiB** entrou na brincadeira.
E então chegamos à insanidade que considero particularmente divertida:
### PDF REAL × CANVAS
* O teste gera um PDF real.
* Rasteriza esse PDF.
* Renderiza independentemente o mesmo layout em Canvas.
* E compara os resultados.
Em:
**0° → 90° → 180° → 270°**
Com geometria assimétrica e barcode vetorial para ajudar a denunciar qualquer erro de transformação.
> Porque se existe uma coisa pior que um bug...
>> é um bug de **2 mm em um rótulo que só aparece quando alguém imprime 5.000 unidades.** 😂
---
### 🧠 E foi aí que percebi uma coisa.
FWWebEx mudou.
> Não estou mais tentando descobrir se é possível colocar uma interface Web dentro do Protheus.
>> Essa pergunta já foi respondida faz tempo.
Agora estamos falando sobre:
**arquitetura, contratos, componentes reutilizáveis, isolamento, performance, determinismo, testes de regressão e paridade visual.**
> Isso muda a natureza do projeto.
* O experimento virou framework.
* A gambiarra virou arquitetura.
* E aquela brincadeira de misturar **TLPP + HTML + CSS + JavaScript** dentro do Protheus...
> cresceu.
>> Muito.
---
## 🥷 FWWebEx deixou de ser brinquedo de criança.
E talvez o mais divertido seja que ainda estamos apenas descobrindo até onde essa ideia pode chegar.
> O código continua aberto.
Quem quiser entender o nível da “brincadeira”, nem precisa começar pelo código do framework.
**Comece pelos testes.**
👉 [FWWebEx Labels — Tests](https://github.com/DNATechByNaldoDJ/fw.webex/tree/main/src/fw.webex/contrib/fw.webex.labels/tests?utm_source=chatgpt.com)
Depois me diga se ainda dá para chamar isso de WebEx dentro de uma janelinha do Protheus. 😈
---
#DNATech, #TOTVS, #Protheus, #AdvPL, #TLPP, #FWWebEx, #OpenSource, #SoftwareEngineering, #SoftwareArchitecture, #AutomatedTesting, #JavaScript, #HTML, #CSS, #PDF, #JsPDF, #PDFJS, #Playwright, #Barcode, #DevTools
Comentários
Postar um comentário