Workshop ExtJS4
2 gostaram1,008 visualizações
O documento resume um workshop sobre ExtJS 4 e PHP ministrado pela School of Net. A agenda inclui tópicos como debugando código JavaScript, voltando aos fundamentos da linguagem como tipos, operadores e escopo, e conceitos importantes como namespaces e prototype.
Workshop ExtJS4
- 1. Workshop de ExtJS 4 + PHP pela School of Net Javascript Zaedy Sayão
- 2. Agenda Debugando Voltando ao básico de JS
- 3. Problemas comuns • Inclui todos os arquivos? • Inclui na ordem correta? • Inclui os arquivos corretos? • Todos os arquivos estão sendo carregados e excutados? • Erros básicos de escrita • If (num = 10) • Case SensiBve • Null !== undefined • 0 é falso
- 4. Debugando Firebug Developer Tools • Javascript “on the fly” • Auto complete • Line ediBng • Breakpoints • Inspect Elements • Table • Navegação
- 5. Debugando IlluminaBons for Developers JSLint
- 6. Back to basics! • Tipos • Operadores • Variables x References • Objects
- 7. Tipos básicos • String • Integer • Float • Object • Array • Boolean • Date • FuncBon
- 8. Operadores aritméLcos • + • -‐ • * • / • % • ++ • -‐-‐
- 9. Operadores lógicos e relacionais • ! • <= • && • > • || • >= • == • != • === • !== • <
- 10. References “A referência para uma “variável” é um ponteiro para uma área de memória onde um valor ou objeto está guardado.” Exemplo: • Criar uma func=on, referenciá-‐la e passá-‐la
- 11. References PARE de usar a palavra “variável”!!!! • Use o termo referência • Lembre-‐se que na verdade é um ponteiro • Usaremos referência daqui em diante
- 12. Referências Globais • Se não usarmos a palavra “var”, são tratadas como globais • SÃO PERIGOSAS === EVIL === DEMO!!! • NÃO USEM!!!! • Únicas que são permiBdas são Namespaces • Sempre usem “var”
- 13. Convenções (JS) === OBRIGAÇÃO • References devem começar com letra minúscula • Exceto quando aponta para uma Classe (construtor ou singleton)
- 14. Por que se usa “variável”? • Javascript tem Bpagem dinâmica
- 15. References Memória 3 var a var b 3 3
- 16. References Memória Memória 9 3 var a var b 9 3 • Não há encadeamento de valor
- 17. References
- 20. Passando objetos como referências
- 21. Passando objetos como referências • String, boolean, integer, null === override, sobrescreve-‐se o valor • Objetos SÃO DIFERENTES!
- 22. FuncLons • São class objects • Possuem propriedades e métodos • Extend de Object • Herdam de FuncBon.prototype • call e apply são herdados
- 23. “this” • É uma referência “mágica” • Extremamente importante que se entenda o que é e como usar • Define o escopo de execução
- 24. Escopo 1. Quando uma função é executada via uma referência “var”, o contexto padrão de execução (‘this’) é “window” 2. Quando uma função é executada via um “key” de um objeto, o contexto de execução (‘this’) é o objeto ao qual o “key” pertence
- 25. Execução padrão para funções com “var”
- 26. Execução padrão para objetos – func/on based
- 27. Qual o escopo de execução de getNome()?
- 28. Qual o escopo de execução de getNome()?
- 29. Forçando escopo de execução • call e apply podem ser usados para forçar o escopo de execução • Logo, você tem TOTAL controle sob o escopo de execução de qualquer função em Javascript
- 30. call
- 31. O Problema do “call” • Você tem que definir todos os argumentos • Ruim para refactoring
- 32. apply
- 33. HoisLng Javascript muda todas as variáveis declaradas para o topo do escopo da função
- 34. Objects • Classe base de tudo que está dentro do Javascript • Basicamente, tudo extends de Object • String, Array, FuncBons, etc
- 35. Construtores • Inicializa os objetos • São nada mais do que funções que são executadas no escopo de um novo Object • Apenas isso, nada mais
- 36. Prototype
- 37. Namespace • Container que provê um agrupamento lógico Exemplo: diretório Cada nome dentro de um diretório idenBfica unicamente um arquivo, mas o mesmo nome pode ser usado em diretórios diferentes
- 38. Namespace Exemplo: • Ext.grid.Panel • Ext.form.Panel • MinhaApp.usuario.Panel
- 39. Namespace Por que usar?
- 40. Namespace GLOBAL === EVIL
- 41. Namespace O root de todos os namespaces é o “window” object do browser Root do Ext: window.Ext ou simplesmente Ext
- 42. Package Namespace Package Class Ext grid Panel Namespace Package Sub-‐package Class Ext form field Text
- 43. ExtJS História • Extensão – YUI (Yahoo! User Interface) • yui-‐ext • YUI era base • Jack Slocum • Virou Ext na sua versão 1.0 • Na versão 1.1.1 passou a ser suportado por diversos browsers • IE 6, Firefox 1.5, Safari 2, Opera 9 e outros
- 44. ExtJS Licença • Open Source – GPL v3 • Comercial • $329 • $299 – suporte • Há pacotes de licença
- 45. ExtJS Vantagens • Cross-‐browser • OO based – alta reuBlização de código e alta produBvidade • Tecnologia não proprietária – não depende de plugins • Sencha Plataform – reusabilidade para uso do Sencha Touch
- 46. ExtJS Vantagens • Deploy fácil • Muito bem organizado • Fácil de manter • Extensível • Fácil de aprender (espero que concordem ao final do Workshop )
- 47. Sencha Produtos • ExtJS 4 • Sencha Touch • Sencha.io • Sencha Animator • Ext GWT • Ext Designer
- 48. ExtJS Baixando e Instalando
- 49. ExtJS API • Navegação • Search • Vídeos • Guides • USE!!!!!
- 50. ExtJS Examples • Alto número de exemplos • Mostram o uso geral dos componentes • Código acessível • Devem ser SEMPRE usados!!
- 51. ExtJS Regras sobre o que NÃO fazer 1. Nunca altere os arquivos do framework 2. NUNCA 3. NEVER 4. JAMAIS 5. EM NENHUMA HIPÓTESE 6. Mas... EU DISSE NUNCA!
- 52. ExtJS Regras sobre o que NÃO fazer 1. Não mude de uma versão para outra sem testar 2. Não use mais a palavra “new” – Ext.create 3. Não programe sem ferramenta de debug 4. Não programe fora das convenções 5. Não misture código PHP (ou outra linguagem) com seu código JS 1. Mantenha seu código limpo e independente de plataforma
- 53. ExtJS Regras sobre o que fazer 1. Abuse e use do OO 2. Use classes abstratas 3. Documente seu código 1. Existem ferramentas que geram documentação para JS 4. Abuse e use de: 1. Extends 2. Override
- 54. ExtJS Regras sobre o que fazer 1. Use as convenções 1. Use nomes condizentes 2. Use sempre arquivo de debug em desenvolvimento 3. Use Loader em desenvolvimento 1. Jamais use em produção! 4. Tenha sempre a API a mão 5. Google é sempre seu pastor! 6. Lembre-‐se, no final, é tudo JS!
- 55. ExtJS Arquivos do framework Arquivo bootstrap.js x app.js • ext-‐debug.js – Core, apenas para desenvolvimento • Usar com Loader • ext.js – igual o ext-‐debug, porém minified • ext-‐all-‐debug.js – Todo o framework • ext-‐all.js – ext-‐all-‐debug.js minified
- 56. ExtJS Arquivos do framework Locale /locale/ext-‐lang-‐*.js * = pt_BR * = es ...
- 57. ExtJS Estrutura de pastas Do framework
- 58. ExtJS Estrutura de pastas Da nossa aplicação
- 59. Convenções === OBRIGAÇÃO Classes • Deve conter apenas números e letras • Números não são indicados • Aceitos quando se referem a termos técnicos • Não use underscore, hífen e outros Bpos de caracteres que não sejam alfa-‐numéricos • MinhaApp.admin_area.Login -‐ NÃO FAÇA • MinhaApp.admin.Login • MinhaApp.uBl.Base64
- 60. Convenções === OBRIGAÇÃO Classes • Devem ser agrupadas em PACKAGES, com seus respecBvos NAMESPACES, usando notação por “.” • Devem ter ao menos 2 níveis, um do Namespace e outro do nome da classe • MinhaClasse • MinhaApp.MinhaClasse • MinhaApp.data.MeuProxy
- 61. Convenções === OBRIGAÇÃO Classes • O Namespace e o nome da classe devem ser usados em CamelCased. Todo o resto deve estar em minúsculo • MinhaApp.Admin.MinhaClasse • MinhaApp.admin.MinhaClasse
- 62. Convenções === OBRIGAÇÃO Classes • Classes que não são do framework nem fornecidas pela Sencha não podem usar o namespace Ext – NUNCA • Acrônimos devem ser CamelCased • MinhaApp.server.HTTP • MinhaApp.server.H‡p
- 63. Convenções === OBRIGAÇÃO Arquivos • Os nomes dos arquivos devem ser mapeados diretamente para o caminho onde estão. • Só deve haver uma classe por arquivo • Ext.uBl.Observable – caminhoApp/src/Ext/ uBl/Observable.js • MinhaApp.server.H‡p – caminhoApp/src/ MinhaApp/server/H‡p.js
- 64. Convenções === OBRIGAÇÃO Métodos e variáveis • Deve conter apenas números e letras • Números não são indicados • Aceitos quando se referem a termos técnicos • Não use underscore, hífen e outros Bpos de caracteres que não sejam alfa-‐numéricos • Devem sempre ser camelCased. Essa regra também se aplica a acrônimos
- 65. Convenções === OBRIGAÇÃO Métodos e variáveis Métodos: base64Encode() getHtml() x getHTML() Variáveis: var base64Encoder var xmlReader
- 66. Convenções === OBRIGAÇÃO Propriedades Mesmas regras de métodos e variáveis, exceto no caso staBc StaBc properBes devem ser sempre upper-‐ cased (maiúscula) Ext.MessageBox.YES = “SIM” MinhaApp.math.MinhaClasse.PI = 3.14
- 68. Gefers e Sefers
- 69. Extends
- 70. Mixins Herança MúlBpla Bastante usados no framework Observable State Draggable .....
- 71. Ext.Loader • Provê carregamento de classes sob demanda • Síncrono e assíncrono • Baseado em controle de dependência • Pode ser usado para praBcamente toda a aplicação • Muito fácil de usar • Menos HTML que se escreve • Alguns “tricks”
- 72. Ext.Loader Síncrono • Carrega usando XHR • Várias desvantagens (mais do que o assíncrono) • Limitado ao mesmo domínio de origem • Requer um web server • Horrível para debugar!
- 73. Ext.Loader Assíncrono • Solução: use Ext.require() • Antes do Ext.onReady() • Usará carregamento assíncrono • Adiciona script tags no HEAD • Muito melhor para debugar • Cross-‐domain • Não precisa de web server • Problema: deve-‐se especificar todas as dependências antes da classe ser instanciada
- 74. Ext.Loader Problemas gerais • Muito custoso • Gera várias requisições ao servidor • Problemas com cache • Lento • Não carrega os arquivos minified • Carrega classes desnecessárias • Ext.require(‘Ext.Component’) carrega items de Sprite do pacote draw
- 75. Ext.Loader Problemas gerais • Muito custoso • Gera várias requisições ao servidor • Problemas com cache • Lento • Não carrega os arquivos minified • Carrega classes desnecessárias • Ext.require(‘Ext.Component’) carrega items de Sprite do pacote draw
- 76. Extensions • Ext foi desenvolvido para ser extendido • Tire proveito disso • Cuidado para não extender o component/ class errado • Pode causar problema de performance
- 77. Extensions Extendendo Panel • Preciso de Docked? • Title Bar? • Sim? Então extenda Panel • Caso contrário, pense em extender Container ou Component • Preciso de algo que gerencie outros componentes usando layout? • Sim? Então extenda Ext.container.Container • Caso contrário, extenda Ext.Component
- 78. Ciclo de vida dos Components • Ext.component.AbstractComponent • Muito importante saber! • É o que diferencia o ExtJS de outros frameworks • Provê confiabilidade e previsibilidade ao framework
- 79. Ciclo de vida dos Components 45% InicializaLon Render DestrucLon
- 80. Inicializa/on • Bootstrap • Cria o id • Registra o componente no ComponentMgr
- 81. Render • Renderiza o componente na tela • Adiciona eventos • Usa os layouts para organizar os componentes
- 82. Destruc/on • ReBra o Component da tela • ReBrar os eventos -‐ listeners
- 83. Ciclo de vida dos Components Passo a Passo -‐ InicializaBon • Configuração do objeto é aplicada e guardada • Eventos básicos são adicionados • BeforeacBvate, beforeshow, show, render, etc • ID é atribuído ou gerado automaBcamente • Plugins são construídos • initComponent é executado • listeners customizados são aplicados • eventos são inicializados
- 84. Ciclo de vida dos Components Passo a Passo -‐ InicializaBon • Component é registrado no ComponentManager • Construtores dos mixins de Base são executados • Construtor de Observable é chamado • Construtor de State é chamado • Plugins são inicializados • ComponentLoader é inicialiado (não é Ext.Loader!) • Se configurado, o Component é renderizado (renderTo, applyTo) • Se configurado, Component é mostrado
- 85. Ciclo de vida dos Components Passo a Passo -‐ Render • Evento beforerender é chamado • Component element é guardado na referência ‘el’ • Se for um floaBng Component, floaBng é habilitado e registrado no WindowsManager • O container do Component é inicializado
- 86. Ciclo de vida dos Components Passo a Passo -‐ Render • onReder é executado • Elementos do Component são injetados no DOM • Base CSS e styles são aplicados • “ui” é aplicado • “frame” é inicializado • renderTpl é inicializado • renderData é inicializado
- 87. Ciclo de vida dos Components Passo a Passo -‐ Render • onReder é executado • renderTpl é aplicado usando renderData • Render selectors são aplicados • “ui” styles são aplicados • Visibilidade do elemento é setada a parBr do atributo hideMode • Se overCls esBver setado, eventos de mouseover/ out são capturados • Evento de render é disparado • Conteúdo do Component é inicialiado (html, contentEl, tpl/data)
- 88. Ciclo de vida dos Components Passo a Passo -‐ Render • a‰erRender é executado • Container Layout é inicializado (AbstractConteiner) • ComponentLayout é inicializado (AbstractComponent) • Tamanho do Component é setado • Se for um floaBng Component, é movido para coordenada XY • a‰erRender é disparado e passado para o elemento do Component • Component é escondido, se configurado • Component é desabilitado, se configurado
- 89. Ciclo de vida dos Components Passo a Passo -‐ DestrucBon • beforedestroy é disparado • Se floaBng esBver setado, o componente é desregistrado do floaBng manager • Component é removido do seu container pai • Elemento é removido do DOM • Listeners são removidos
- 90. Ciclo de vida dos Components Passo a Passo -‐ DestrucBon • onDestroy é chamado • Plugins são destruidos • O Component é desregistrado do ComponentManager • destroy é disparado • Mixin de State é destruído • Listeners do Component são removidos
- 91. Layouts Dois Bpos • Container Layout • Responsável por organizar e gerenciar o tamanho dos itens filhos • Component Layout • Responsável por organizar o conteúdo HTML do componente
- 92. Layouts Auto Layout • Layout default • Burro! • Usa HTML para dar tamanho aos itens • Não renderiza os filhoes de acordo com o pai • Você DEVE usar outro layout caso queira uma mudança dinâmica de tamanho dos filhos
- 93. Layouts Column Layout • Extends Auto Layout • Gerencia o width dos itens filhos • Não redimensiona os filhos verBcalmente
- 94. Layouts Fit Layout • Extends Container Layout • Redimensiona o filho para todo o Container • Não permite scrolling
- 95. Layouts Anchor Layout • Extends Container Layout • Redimensiona dinamicamente os filhos tanto na altura como na largura, basiado em suas regras • Permite scrolling
- 96. Layouts Absolute Layout • Extends Anchor Layout • Posiciona dinamicamente os filhos nas coordenados X e Y • NÃO redimensiona dinamicamente os filhos • Permite scrolling
- 97. Layouts Border Layout • Extends Container Layout • Redimensiona automaBcamente os filhos • Organiza os filhos em regiões • North, south, east, west, center • As regiões podem ser redimensionadas ou collapsible • Região center é obrigatória
- 98. Layouts Box Layout • Extends Container Layout • Classe base para HBox e VBox • HBox organiza os filhos horizontalmente • Linha, lado a lado • VBox organiza os filhos verBcalmente • Pilha • Configs usuais do layout: align, pack • Configs usuais dos filhos: height, width, flex
- 99. Layouts Box Layout – align config • HBox • Top, middle, stretch, stretchmax • VBox • Le‰, center, strecth, stretchmax
- 100. Layouts Box Layout – pack config • start, middle, end
- 101. Layouts Accordion Layout • Extends VBoxLayout • Empilha os itens verBcalmente • Permite que 1 item seja expandido por vez e apenas 1 • Filhos devem ser Panels ou herdarem de Panel
- 102. Problemas comuns • this.el is undefined • store.load() -‐> store.getCount() • Quando meu código será executado? Ajax -‐> callback • Scope -‐> this (especificar escopo) • Loading data • Url está correta? • O request foi completado com sucesso? • A informação é válida? Verifique o JSON ou XML • O modelo está condizente com o componente? • AJAX – ASSÍNCRONO • Execução não pára • Use callbacks • Layout • OvernesBng • TabPanel -‐> Panel -‐> Grid