Original iOS Interface

Wouldn’t be cool if we selected some native mobile UI and try to recreate them using only HTML5, CSS3 and JavaScript? So, today is Facebook’s extraordinary IPO and I took their clean & classy login screen and recreated it for the web! Here it is the final result, some code and also comments.

Disclaimer: I created this app with the iPhone Facebook App in mind. I only tested the app on iPhone. I already noticed that the radial gradient background looks pixelated on Chrome, and I also suspect that due to other gradients, alpha colors and etc this app will make some Android and BlackBerry devices scream. Please don’t blame me :)

This view above is an iframe, if you open this blog post with Chrome or Safari you’ll be able to see it running! You can also point your mobile device to the following URL:

• Live Example: http://brunotavares.github.com/SenchaExamples/touch/native-to-web-facebook-login/
• Source code: http://github.com/brunotavares/SenchaExamples/

View

The view it’s pretty simple. We have the logo, 2 fields and 3 buttons. The only thing that might look different is the component with CSS class ‘shadow’. Since I wasn’t able to create a box-shadow for the fields without creating conflicts with their borders, I use this component as a layer on top of the fields with the inner shadow.

Theming

About the theming, there’s a lot of CSS3 stuff inside. I’m using Sass with Compass framework, so it alleviates some of the hurdles of plain CSS. Logo is just a component with fixed size and a background image. I’m also providing the retina version of it using the medias queries.

As I wrote previously, the shadow component is a hack solution for making the inner box-shadow, without creating conflicts with the fields’ borders. The email field has a gray border on the bottom, and the password a white border on the top. It creates kind of an edge between fields. Something different about the fields is that you can style the text placeholder using ::-webkit-input-placeholder.

The buttons received new gradients, and also additional box-shadows. They also provide the same pressing state as the original interface.

Wrapping up

And that’s pretty much it. This is a great exercise, to see what we can accomplish using only web. Specially with Sencha Touch, since we hear a lot of questions asking how easy/hard it is to customize Touch components.

I wanted to use only CSS3, but for production it would be better to use a solid image for the radial background for non-iOS devices, and other sutil improvements. From my experience it performs way better.

The best way for developers to learn new technology is definitely coding. For learning the new changes introduced with Touch 2, I created this little app that I called Touchr. It features some common components and basic filtering interaction, but also a customized proxy with YQL integration to consume Flickr. Check the list:

• MVC architecture
• Customized JSONP proxy that consumes YQL queries
• Use of sencha.io service to resize images, optimizing for mobile screens.
• Use of controller listeners to filter data stores
• Use of TabPanel, DataView, Buttons, Toolbar, TextField
• Use of custom theme to define new color, new icons and css optimizations

In this post I’ll share some details so you can also exercise some Touch skills as well!

Grab it!

The code is available on github.com/brunotavares/Touchr. I’m always trying to improve it and keep it up to date. The last major one was for Touch 2.1, using the new SDK with the microloader.
*Touch compatibility webkit only

Starting the project

$ sencha app create TR ~/Code/Touchr

Really simple task with the new Touch SDK. This will create all project scaffold, already activating the dynamic loading and the microloader. Check “Quick Touch 2 scaffolding example” if you have any questions.

Views

The root component for this app will be a TabPanel, and from there we’ll create 3 different lists: Feature Photos, Search Photos, and Photos from User. I decided to separate those in different views, and reference them on the tabpanel using xtype.

All the 3 lists will look similar. I picked the User list to expand the code. Please take a look on other 2 lists views from the repository.

Notice that it’s a list, but it extends Ext.dataview.DataView, and not Ext.dataview.List. Since I don’t need features like row selection, grouping, and index bar, the dataview is a lighter and better option. The same line of thought is valid when choosing simple Containers other than full Panels. Always analyse carefully when picking up components.

Also notice that for the itemTpl config I’m using the src.sencha.io service. It’s a great utility that delivers images according to the device screen size. It makes your app faster, since you don’t need to serve 1000×600 pictures for a 480×320 device.

Models and DataStores

The list above will only display data if it’s tied to a datastore. In this case is the UserPhotos store. And this store is tied to the Photo model, which defines its fields.

Taking a close look at this store, it’s clear that it’s linked to TR.model.Photo. It’s also using remoteFilter, which allows the custom Flickr proxy to pass parameters to Yahoo YQL API (more to come). The proxy is the one responsible for fetching data, and it has a JSON reader attached for parsing.

This store features a not so conventional rootProperty. It’s a nested one, since the YQL API response is formatted in this way.

The Photo model is pretty straightforward. The only different thing here is the photo_url field, which is not an information delivered by the server-side. It’s a custom local property that I defined, so I could have a better model design. Since mobile apps often deal with third part APIs, and those are not always properly designed for our app, we have the chance to normalize it.

Controllers

At this point we already have views displaying data, so now we’re adding some interaction. Let’s take a look on the search tab, which has a searchfield on the top that will filter our list. We need to create a controller that will look into the component tree for our searchfield, associate a listener to it, and then filter the list’s store.

The way controllers associate listeners to components is by the control config. This object receives key:values pairs, where the key is a string representing a ComponentQuery String, and the value is another object, containing the name of the event as key, and the value as a function string reference.

To filter the list I don’t actually go trough its methods trying to find a way to accomplish the task. All the data is defined on the datastores and models. They serve as a data layer, and every data operations as adding, removing, updating or filtering itens is done by the datastore.

Other parts…

I’m still missing the custom Flickr Proxy, designed to consume YQL Service via JSONP, and the theming structure. I’ll let those to a separate article.

On this post we saw how to start the project, and go trough the MVC pattern, defining views, then the data layer with models and stores, and last adding interaction via controllers.

I’m looking forward to do more tutorials like these. If you like it, don’t forget to share and support our growth!

When Ext Designer came, everyone was exciting not only to finally put hands on this great product, but also to see an Ext JS application running natively on the desktop. As all the other curious developers, I did some research and come with the post Ext ION: rumors of a new product. This was back in April 2010, when I wasn’t even a Sencha employee.

For my surprise, my predictions were confirmed last week! Sencha announced the private beta sign-up for ION. On the short description, the product is labeled as a way to wrap Ext JS Web applications in a native desktop shell.

Sencha “ION” is a project that enables packaging of Ext JS applications in to a native desktop shell (think “PhoneGap for the Desktop” :-). We are currently interested in beta testers who are looking to deploy their web apps as desktop applications. You may be interested in doing this if you are looking to distribute your app through a System Management Service, or if you have IE6/7/8 on your corporate environment but want to take advantage of HTML5 features in your app, or many other scenarios. Sencha “ION” technology will appear in various Sencha products over the course of the next year, and this is an early opportunity to test it out and provide us with feedback on how we can make it work best for you.

In my opinion the biggest impact is in organizations that are locked in old browsers. That way developers can use ION to make use of the best HTML5 features, without carrying about old browsers.

If you have a cool project and is willing to test it, sign up for the beta! For all the others, let’s wait some more to see what is coming!

The new Sencha Touch 2 framework ships with a terminal SDK that makes it easier than ever to create, pack and deploy your application. Let’s take a look on how we start a brand new project with Touch 2.

First of all, make sure you check the official guide Using Sencha Command. It will help you have everything setup.

Scaffolding a new project requires a simple command.

sencha app create <namespace> <path_to_project>

The trick here is that you need to be at the sencha framework folder to execute this line. If you execute sencha app create from any other folder, it won’t work.

$ cd sencha-touch-2.0.0-gpl
$ ./command/sencha app create Blog ~/Code/BlogProject
[INFO] Created file /Users/brunotavares/Code/BlogProject/.senchasdk
[INFO] Created file /Users/brunotavares/Code/BlogProject/index.html
[INFO] Created file /Users/brunotavares/Code/BlogProject/app.js
[INFO] Created file /Users/brunotavares/Code/BlogProject/packager.json
[INFO] Created file /Users/brunotavares/Code/BlogProject/app.json
[INFO] Created file /Users/brunotavares/Code/BlogProject/app/view/Main.js
[INFO] Copied dir: /Users/brunotavares/Code/BlogProject/sdk/src
[INFO] Copied dir: /Users/brunotavares/Code/BlogProject/sdk/resources
[INFO] Copied dir: /Users/brunotavares/Code/BlogProject/resources/icons
[INFO] Copied dir: /Users/brunotavares/Code/BlogProject/resources/loading
[INFO] Copied dir: /Users/brunotavares/Code/BlogProject/sdk/command
[INFO] Copied file: /Users/brunotavares/Code/BlogProject/sdk/microloader/development.js
[INFO] Copied file: /Users/brunotavares/Code/BlogProject/sdk/microloader/testing.js
[INFO] Copied file: /Users/brunotavares/Code/BlogProject/sdk/microloader/production.js
[INFO] Copied file: /Users/brunotavares/Code/BlogProject/sdk/version.txt
[INFO] Copied file: /Users/brunotavares/Code/BlogProject/sdk/sencha-touch.js
[INFO] Copied file: /Users/brunotavares/Code/BlogProject/sdk/sencha-touch-all.js
[INFO] Created file /Users/brunotavares/Code/BlogProject/resources/sass/app.scss
[INFO] Created file /Users/brunotavares/Code/BlogProject/resources/sass/config.rb
[INFO] Copied file: /Users/brunotavares/Code/BlogProject/resources/css/app.css

And now you can open your local server (e.g. http://localhost/code/BlogProject/) and see a ready-to-code application.

It’s fairly simple to start a Touch application with this kind of tool. It’s just download the framework, open the terminal, and execute one app create command.

The resulting app will have an ideal structure. It will make use of the new microloader, that under production keeps files on localstorage for better performance. It will have the MVC structure in place, that provides a solid and maintainable foundation. It will also create the packager.json file, that will help us pack this app for native iOS or Android distribution.

With this in place, we can now go ahead and develop some cool apps in the next posts!

ExtDesenv has been a cool resource for Sencha stuff for a while, but in the last months things are going pretty slow. I definitely don’t wanna kill this project, since I really enjoy blogging and sharing things, so I decided to make things more productive over here!

Starting now, we have a new simplified theme, with less customizations and more focus on content. I added a github integration, so sharing code and updating legacy code would be easier for me, and more readable for you. I’m also shifting the main language from Portuguese to English, solely to reach a higher audience. I’ll see in the future if I’ll do something with translations or not.

So, exciting things are happening here! Specially now that I’m working at Sencha, there’s a lot of questions and information that I can reach right from the source. Stay tuned!

Hello Sencha Touch!

Just a small test for me if everything is working fine.
*Touch compatibility webkit only

O meu canto :)

Como é de se imaginar, trabalhar ao lado dos “caras oficiais Ext JS” é um tanto importante para mim. Estou extremamente empenhado em participar de todos os projetos, e inclusive pude responder alguns tickets de amigos brasileiros no sistema de suporte!

Dada estas circunstâncias não sei quando voltarei a escrever. Acho mais importante agora estar bem envolvido aqui, e em projetos open-source no GitHub. Mas não se sintam desamparados, têm uma galera muito boa na nossa comunidade brasileira! www.extjs.com.br/forum, o nosso fórum brasileiro de Ext segue à todo vapor, e eu ainda participo quando posso.

Destaque ainda para a Loiane Groner, que está fazendo um trabalho minucioso no seu Curso Grátis de Ext JS 4. Se escrever artigos em blog com imagens, exemplos e afins é difícil, imagina fazer vídeo-aulas em um curso completo! Uma iniciativa surpreendente que merece muito reconhecimento.

E ainda, tenho percebido que os cursos Ext JS e Sencha Touch pagos estão aparecendo “aqui e ali”. A comunidade têm amadurecido bastante, muito bom ver (e participar) de tudo isto!

Ainda estou por aqui! Ainda desenvolvo com Ext (mais do que nunca), e ainda participo da comunidade. Precisando, só dar um toque ;] Abs!

Bruno Tavares, Solutions Engineer
Sencha, Inc.

Model

1. Criar model no arquivo app/model/Post.js

[javascript]Ext.define(‘EB.model.Post’, {
extend: ‘Ext.data.Model’,
fields: [
{name: 'id', type: 'int' },
{name: 'title', type: 'string' },
{name: 'content', type: 'string' }
],
proxy: {
type: ‘ajax’,
url: ‘data/posts.json’,
reader: {
type: ‘json’,
root: ‘posts’,
idProperty: ‘id’
}
}
});[/javascript]

2. Criar store no arquivo app/store/Posts.js

[javascript]Ext.define(‘EB.store.Posts’, {
extend : ‘Ext.data.Store’,
model : ‘EB.model.Post’
});[/javascript]

3. Criar dados fictícios no arquivo data/posts.json

[javascript]{
"posts": [
{"id":1, "title": "Post 1", "content": "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nullam id nisl tellus, nec pretium tortor. Duis luctus posuere felis vitae viverra. Vivamus nisl purus, pulvinar eget rhoncus et, mattis nec leo. Donec sagittis ultrices molestie. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas."},
{"id":2, "title": "Post 2", "content": "In hac habitasse platea dictumst. Nam commodo, augue id consequat ultricies, lacus augue pharetra odio, in aliquet neque magna vitae ipsum. Praesent porta dictum nibh, quis aliquam tortor volutpat nec. Nulla egestas nibh ac neque congue eu commodo dui elementum. Sed interdum massa sit amet odio aliquet at blandit mauris condimentum."},
{"id":3, "title": "Post 3", "content": "Vestibulum commodo pellentesque sagittis. Nullam sed venenatis mi. Etiam convallis turpis at velit faucibus lobortis. Sed pretium viverra dui vitae adipiscing. Quisque mattis mollis lectus. Nullam a convallis sapien. Donec vitae eleifend ipsum. Nam tortor ipsum, ultrices eget feugiat nec, sodales et magna."}
]
}[/javascript]

Fazendo desta forma a nossa camada de dados está pronta. Temos um model, aonde descrevemos os campos que o compõem, e o proxy que fará a conexão com o servidor. Definimos também o reader, que é o responsável por traduzir os dados que vêm do servidor para que o Ext possa criar as instâncias do model.

View

Agora vamos criar a listagem de posts, no arquivo app/view/post/List.js

[javascript]Ext.define(‘EB.view.post.List’,{
extend : ‘Ext.view.View’,
alias : ‘widget.postlist’,

//inits
initComponent: function()
{
Ext.apply(this,{
title : ‘Posts’,
store : ‘Posts’,
itemSelector: ‘div.post-wrap’,
tpl : new Ext.XTemplate(
‘<tpl for=".">’,
‘<div style="margin-bottom: 10px;" class="post-wrap">’,
‘<h2>{title}</h2>’,
‘<p>{content}</p>’,
‘</div>’,
‘</tpl>’
)
});

this.callParent(arguments);
this.store.load();
}
});[/javascript]

EB.view.post.List é uma view bem simples. Ela extende de Ext.view.View, definindo o store e também o template utilizado para essa listagem. Vamos deixar os links de edição e exlusão de fora por enquanto.

Controller

Este é a parte responsável por juntar models, stores, views, e adicionar os eventos e interações. Por enquanto não vamos definir os eventos, vamos só criar o arquivo app/controller/Posts.js e juntar todas as partes

[javascript]Ext.define(‘EB.controller.Posts’, {
extend : ‘Ext.app.Controller’,
views : ['post.List'],
models : ['Post'],
stores : ['Posts']
});[/javascript]

Unindo as partes

Vamos adicionar o controller Posts à nossa definição de application em app.js

[javascript]Ext.application({
name: ‘EB’, //app namespace (from ExtBlog)
controllers: ['Posts'], //here goes the controllers
autoCreateViewport: true //automatically creates Viewport
});[/javascript]

O app.js é nosso arquivo de entrada. Ele irá disparar o carregamento de controller definido em app/controller/Posts.js. Como dentro do nosso controller nós indicamos suas views, models e stores envolvidas, estes também serão carregados. No final temos tudo carregado e pronto para o uso!

Basta agora adicionar nossa listagem de posts ao Viewport, usando diretamente o alias postlist

[javascript]//…
xtype: ‘tabpanel’,
region: ‘center’,
items: [{
xtype: 'postlist'
},{
title: 'Post 1',
html: '...post 1...'
}]
//…[/javascript]

Como resultado já podemos ver nossa listagem de arquivos sendo carregada. A estrutura MVC do Ext 4 permite que cada diferente parte de uma interface seja definida no seu devido lugar.

Apesar de termos já uma listagem, ainda falta interação para abrir o post e também as regras SASS para deixar a interface do jeito que queremos. Tudo isso será feito no próximo post!

Para ficar bem elucidado, vou criar uma aplicação simples de Blog. O sistema final deve ser parecido com o rascunho abaixo. Ele é composto de um painel para ler posts, e um menu lateral com recursos adicionais. Ao clicar em um post ele ganhará destaque, e links para edição e remoção serão mostrados. Ao clicar duas vezes uma nova aba será aberta. Na lateral poderemos filtrar por categoria ou data, e ainda teremos a opção de criar um novo post, o que abrirá uma nova janela. Apesar de ser um sistema básico, consigo através dele abordar os componentes mais usados.

Set Up

1. Criar a estrutura de diretórios conforme especificado na documentação oficial

Estrutura Diretórios

O diretório principal recebe o nome que você desejar (algo relacionado a sua aplicação obviamente). No meu caso vou chamar de extblog, por esse projeto se tratar de um blog escrito em Ext. O diretório extblog/app, e seus subdiretórios controller, model, store e view são padrões do Ext. Temos ainda o diretório extblog/ext-4.0, com os fontes do Ext (não todos! Eu por enquanto estou copiando só o ext.js, ext-dev.js, e os subdiretórios src e resources). E por fim o diretório extblog/resources aonde colocamos arquivos estáticos como imagens e SASS

2. Criar os arquivos de entrada index.html e app.js

O nosso arquivo index.html não tem muito segredo. Ele vai ser o mais simples possível, contendo somente a inclusão do arquivo CSS do Ext, o próprio JS do Ext, e um arquivo chamado app.js.

[html]<html>
<head>
<title>ExtBlog</title>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<link rel="stylesheet" type="text/css" href="ext-4.0/resources/css/ext-all.css">
<script type="text/javascript" src="ext-4.0/ext-dev.js"></script>
<script type="text/javascript" src="app.js"></script>
</head>
<body></body>
</html>[/html]

app.js é uma novidade da versão 4. Ele é o arquivo de entrada padrão, contendo dados a respeito da inicialização da sua aplicação. Nele você informa o namespace da sua aplicação, e também quais os controllers existentes. Por enquanto só vou ter o namespace.

[javascript]Ext.Loader.setPath(‘Ext’, ‘ext-4.0/src’);
Ext.Loader.setConfig({enabled: true});

Ext.application({
name: ‘EB’, //app namespace (from ExtBlog)
controllers: [] //here goes the controllers
});[/javascript]

Fazendo essa definição inicial já é possível acessar o aplicativo e verificar pelo firebug que tudo está sendo carregado corretamente.

Como estamos utilizando a versão de desenvolvimento do Ext (ext-dev.js), é importante dizer aonde os arquivos se encontram, e também ativar o carregamento dinâmico. Isso ocorre nas 2 primeiras linhas, usando Ext.Loader

O sistema de carregamento dinâmico permite que somente as classes que realmente estão sendo utilizadas pela nossa aplicação sejam usadas. Quando chegarmos no processo de deploy, iremos utilizar a ferramenta Sencha SDK para concatenar e compactar todos arquivos em um único. Por causa desse carregamento dinâmico é temos alguns outros arquivos JS que não incluímos no HTML sendo carregados.

Viewport

Agora que temos o nosso projeto rodando, podemos começar a desenvolver a interface, criando o Viewport. Ext.Application possui uma configuração autoCreateViewport. Quando true, o Ext procura o arquivo Viewport.js e já o instancia. Então o que faremos é adicionar essa configuração em app.js e criar o arquivo app/view/Viewport.js.

[javascript]Ext.define(‘EB.view.Viewport’, {
extend: ‘Ext.container.Viewport’,

layout: ‘border’,
padding: 5,

items: [{
xtype: 'container',
html: 'ExtBlog by Bruno Tavares',
region: 'north',
height:40
},{
xtype: 'tabpanel',
region: 'center',
items: [{
title: 'Posts',
html: '...here goes the posts...'
},{
title: 'Post 1',
html: '...post 1...'
}]
},{
xtype: ‘panel’,
region: ‘east’,
html: ‘…here goes additional resources…’,
split: true,
width: 400
}]
});[/javascript]

Nessa primeira classe já é possível visualizar a nova sintaxe do Ext 4; a classe é definida por Ext.define.

Se você seguiu tudo certinho até aqui, ao tentar visualizar o viewport no navegador, pode perceber algumas mensagens de aviso como estas:

Aviso: você esqueceu uma dependência...

Por causa do carregamento dinâmico, devemos informar quais as classes que nossas interfaces fazem uso. Não se preocupe se você esquecer alguma dependência enquanto desenvolve, ou não souber delas. O Ext vai carregar ela de forma síncrona e emitir este aviso no console de depuração. Para isso seu navegador deve possuir este recurso (sugiro firefox + firebug), e você deve estar utilizando a versão -dev.js do Ext.

Para resolver com isto, basta ir adicionando os requisitos em app.js

[javascript]Ext.Loader.setPath(‘Ext’, ‘ext-4.0/src’);
Ext.Loader.setConfig({enabled: true});

Ext.require(
‘Ext.layout.container.Border’,
‘Ext.tab.Panel’
);

Ext.application({
name: ‘EB’, //app namespace (from ExtBlog)
models: [], //here goes the models
controllers: [], //here goes the controllers
autoCreateViewport: true //automatically creates Viewport
});[/javascript]

No próximo post

No próximo post (Construindo um aplicativo com Ext 4 – Parte 2) vamos criar nossos models, view e controllers. Ficamos por aqui com o setup básico de um projeto em Ext 4, já conseguindo visualizar a estrutura básica do sistema. Segue também link para download dos fontes e exemplo online. Até em breve!

Código Completo

Demo Online

JavaScript é uma linguagem orientada em prototipagem, sem classes. Assim, por natureza, uma das características mais marcantes da linguagem é a flexibilidade. É possível obter um mesmo resultado por diferentes maneiras, em diferentes estilos de codificação e técnicas. Essa característica, entretanto, vêm com o preço da imprevisibilidade. Sem uma estrutura unificada, código Javascript pode ser muito difícil de entender, manter e reutilizar.

Programação baseada em classes, em outro extremo, continua como o modelo mais popular de POO. Linguagens baseadas em classes geralmente requerem forte tipagem, provêm encapsulamento, e possuem padrões e convenções de código. Por geralmente fazer desenvolvedores aderirem a um grande número de princípios, o código escrito tende a ser mais previsível, extensível, e escalável ao longo do tempo. Entretanto, elas não possuem a mesma capacidade dinâmica encontrada em linguagens como Javascript.

Cada abordagem possui seus prós e contras, mas será que podemos ter os prós de ambas ao mesmo tempo, enquanto conciliamos os contras? A resposta é sim, e nós implementamos a solução no Ext JS 4.

- Ext JS Documentation, Class System

Convenção de Código

Para manter um padrão de codificação foram publicadas as convenções de código que devem ser adotadas pelos programadores Ext. Isto não torna o código mais rápido, mas com certeza o torna melhor, mais fácil de dar manutenção e de entender. Vou tentar citar as principais, uma lista completa e detalhada encontra-se no guia Class System.

Classes

Devem conter somente caracteres alfanuméricos, sendo que números devem ser evitados, a menos que pertençam a termo técnico.

Btti.util.Base64 é aceitável

As classes devem ser organizadas em pacotes, mantendo somente 1 nome para o pacote de mais alto nível. Só o pacote de mais alto nível e o nome da classe devem ser CamelCase, o restante é minúsculo

Btti.data.SQLProxy

Btti.Viewport

Acrônimos também devem seguir o padrão CamelCase

Ext.data.JsonProxy ao invés de Ext.data.JSONProxy

MyCompany.util.HtmlParser ao invés de MyCompary.parser.HTMLParser

Arquivos Fonte

O nome das classes mapeiam diretamente para o caminho aonde os arquivos são armazenados, como resultado deve existir somente 1 classe por arquivo. Exemplo:

Ext.util.Observable é armazenado em path/to/src/Ext/util/Observable.js

Btti.pedidos.Listagem é armazenado em path/to/src/Btti/pedidos/Listagem.js

aonde path/to/src é o diretório de classes da sua aplicação. Todas as classes devem estar em um único diretório e devem ser apropriadamente divididas em namespace, para melhor desenvolvimento, manutenção, e facilidades em implantações.

Métodos e Variáveis

Funcionam de forma análoga a classes, porém no padrão camelCase.

encodeUsingMd5()

getHtml() ao invés de getHTML()

var isGoodName

var base64Encoder

var xmlReader

Propriedades

Seguem o mesmo padrão de métodos e variávels, exceto quando é uma propriedade estática de uma classe, que são constantes. Estas são escritas todas em maiúsculo:

Ext.MessageBox.YES = "Yes"

Btti.Viewport.THEME = 'btti-verde'

Estrutura das Classes

A maneira antiga de declarar classes gerava códigos similares a este:

[javascript]Ext.ns(‘Btti.grid’);

Btti.grid.ListagemBase = Ext.extend(Ext.grid.GridPanel,{

/** @readonly **/
totalRegistros: 20,

/** @cfg {Boolean} usaPaginacao Indica se o grid usa ou não paginação */
usaPaginacao: true,

initComponent: function()
{
if(this.usaPaginacao)
{
this.bbar = new Ext.PagingToolbar({
store: this.store,
pageSize: this.totalRegistros
});
}

Btti.grid.ListagemBase.superclass.initComponent.call(this);
}
});
Ext.reg(‘btti.listagembase’, Btti.grid.ListagemBase);[/javascript]

Este código define uma classe Btti.grid.ListagemBase que serve como facilitador na criação de grids com paginação. Basta definir usaPaginacao true ou false, para criar o toolbar. Em complemento existe uma propriedade totalRegistros que é um valor padrão somente-leitura que nenhum desenvolvedor deveria sobreescrever. Apesar de funcionar bem, existem alguns inconvenientes com este modelo

Primeiro, Btti.grid deve existir antes de associarmos ListagemBase a ele. Isso requer que usemos Ext.namespace() (ou o atalho Ext.ns()) para criar o namespace. Ainda, Ext.grid.GridPanel deve existir/estar carregado antes mesmo de iniciar este código. Mas Ext.grid.GridPanel pode ter dependências, e estas dependências possuírem outras dependências, o que nos força a carregar todo o framework em ext-all.js ao invés de somente os códigos que necessitamos. E ainda, não existe uma separação clara entre propriedades da classe que não devem ser manipuladas (como totalRegistros), e configurações do usuário (como usaPaginacao).

No Ext 4 tudo isso é resolvido, e resume-se nisto:

[javascript]Ext.define(‘Btti.grid.ListagemBase’,{

extend: ‘Ext.grid.Panel’,
alias: ['btti.listagembase'],

/** @readonly **/
totalRegistros: 20,

config:{

/** @cfg {Boolean} usaPaginacao Indica se o grid usa ou não paginação */
usaPaginacao: true

},

initComponent: function()
{
if(this.config.usaPaginacao)
{
this.dockedItems = this.dockedItems||[];
this.dockedItems.push({
xtype: ‘pagingtoolbar’,
dock: ‘bottom’,
itemId: ‘paginacao’,
store: this.store
});
}

this.callParent();
},

applyUsaPaginacao: function(usaPaginacao)
{
if(usaPaginacao === true)
{
this.addDocked({
xtype: ‘pagingtoolbar’,
dock: ‘bottom’,
itemId: ‘paginacao’,
store: this.store,
pageSize: this.totalRegistros
});
}
else
{
this.removeDocked(this.getDockedComponent(‘paginacao’));
}
}

});[/javascript]

O nome da classe, e também de quem ela extende, são strings. Isso evita erros caso o namespace ainda não tenha sido inicializado, ou a classe extendida não tenha sido carregada. O Ext trata de iniciar e carregar tudo, desde que a estrutura proposta nas convenções seja seguida.

Propriedades configuráveis pelo usuário (config options) agora estão reservadas em config. Além de ficar melhor estruturado, o Ext ainda cria automaticamente métodos setUsaPaginacao e getUsaPaginacao. E se algum código precisar ser executado ao alterar o valor da configuração, como no meu exemplo que é adicionar e remover o toolbar de paginação conforme a propriedade muda, pode ser implementado um método apply, como em applyUsaPaginacao

Outros detalhes que possam chamar a atenção:

• Redundâncias foram eliminadas, como Ext.grid.GridPanel para Ext.grid.Panel, Ext.PagingToolbar para Ext.toolbar.Paging, Ext.tree.TreePanel para Ext.tree.Panel, etc…

• Toolbars em componentes são considerados dockedItems. Eles podem ser ancorados em qualquer posição (topo, base, esquerda e direita), e podem existir vários, um adjacente ao outro.

• Invocar o método da classe pai agora é um simples this.callParent(); ao invés de Btti.grid.ListagemBase.superclass.initComponent.call(this);.

Conclusão

Achei essas alterações as melhores da nova versão. Ficou bom demais escrever classes agora, pois tudo fica muito bem estruturado e fácil de manipular. Sem contar na conveniência de ter muito código automatizado pelo Ext.

Também achei ótimo publicar as convenções de desenvolvimento. Tenho certeza que muitos desenvolvedores possuem opiniões diferentes, e talvez contrariem as convenções. Caso vá por este caminho, tenha em mente que muitas facilidades e automatizações possam não estar disponíveis para o seu código, e suas próprias convenções.

Muitas das informações aqui publicadas foram extraídas do guia oficial Class System, publicado na documentação do Ext JS 4.0. Se vocês quiserem mais detalhes, este é o lugar para procurar.

Forte abraço, até a próxima.

Reaprendendo o Ext

Quem programava Ext 1.0 sofreu com a nova versão 2.0. Era uma versão muito melhor, muito mais rápida, porém extremamente diferente. Traçar o mesmo paralelo entre a versão Ext 3.0 para a 4.0 pode ser um pouco exagerado, mas certos pontos realmente são válidos. A impressão é que você está reaprendendo o framework, porque não foram algumas melhorias pequenas como da versão 3.0 para 3.1, foram coisas essenciais, o código foi praticamente reescrito desde seu núcleo. É preciso voltar aos estudos, assistir apresentações, ler artigos, investir tempo na nova documentação, até adaptar-se a nova versão.

Para começar o sistema de classes mudou. A forma de escrever suas classes não é mais o mesmo. Só neste ponto eu creio que terei de alterar todos os fontes JS das minhas aplicações. Não que tudo vá parar de funcionar, porque a equipe irá lançar um arquivo de migração (Compat.js). Mas para ser 100% complacente com a nova versão, as definições de classes devem mudar.

[javascript]/*
*Como eram definidas as classes
*/
Ext.namespace(‘App.cliente’);
App.cliente.Cadastro = Ext.extend(Ext.form.FormPanel, {

restUrl: ‘/clientes’,
clienteID: 0,

initComponent: function()
{
//…
App.cliente.Cadastro.superclass.initComponent.call(this);
}
});
Ext.reg(‘clientecadastro’,App.cliente.Cadastro);

/*
* A nova definição
*/
Ext.define(‘App.cliente.Cadastro’, {

restUrl: ‘/clientes’,

config: {
clienteID: 0
},

initComponent: function()
{
//…
this.callParent();
}
});[/javascript]

Arquitetura de Aplicação

Outra coisa, pela primeira vez na história da companhia uma arquitetura de aplicação foi publicada. Até então cada ninja Ext resolvia sua aplicação de uma forma. Algums orientados a objetos, outros nem tanto, alguns colocando todos scripts em um diretório, outros dividindo por namespace, etc…

Estrutura dos arquivos

Se adequar a nova estrutura é crucial para poder fazer uso do SDK que está sendo desenvolvido. Este SDK foi comentado na Sencha Conf, e assume que seus fontes e sua aplicação está toda organizada seguindo os padrões Sencha de desenvolvimento. Caso contrário, nada de automatização e algumas surpresinhas que eles estão reservando.

Desempenho

Toda a reescrita do código foi pensada para ter mais robusteza e desempenho. De início posso dizer que com certeza ficou mais rápido. E as explicações são bem óbvias. Primeiro porque houve uma gigante diminuição de elementos DOM para cada componente. O Grid não usa mais um monte de <div> e sim uma <table>, os botões não usam mais uma complicada estrutura porque agora é usado CSS3 para fazer os degradês e cantos arredondas. Também por conta do CSS3 muitos sprites foram eliminados.

Além disso o framework agora conta com carregamento dinâmico. Foi até uma agradável surpresa que minha função Ext.require tenha ido junto. Agora o Ext conta com essa função em seu núcleo, mas com o toque dos programadores Sencha que deram uma bela melhorada nela. O arquivo JS só é carregado quando a classe é requisitada. Mas claro, para isso sua aplicação deve seguir a arquitetura Sencha.

Fiquei com um pouco de dúvida devido ao tamanho dessa versão: 1.1mb. E não é a versão debug, porque esta tem 2.4mb. Ainda estou a procura de melhores esclarecimentos. Não sei se é possível carregar o próprio Ext sob demanda, ou incluir o arquivo de 1mb será a única abordagem.

Gráficos

Nesse ponto eu fiquei muito surpreso. O pessoal caprichou e criou uma biblioteca decente de gráficos sem usar flash, nem requerir nenhum plugin adicional. São dezenas de gráficos e opções para todos os gostos. Como tudo é Javascript, tudo pode ser alterado e personalizado sem problemas. Legendas, cores, animações, tooltips, tudo pode ser customizado, extendido ou melhorado. Os gráficos são rápidos e desempenham bem nos browsers modernos. Segundo a equipe até o IE6 suporta os gráficos…

Ext.data

Outro ponto que estou muito ansioso para explorar. O DataStore deixa de ser o chefão e passa a ser somente um complemento. Agora é possível fazer uma modelagem muito mais profissional usando a classe Ext.Model.

[javascript]//definir um model
Ext.define(‘User’, {
extend: ‘Ext.data.Model’,
fields: ['id', 'name', 'age'],
proxy: {
type: ‘rest’,
url : ‘/users’,
reader: {
type: ‘json’,
root: ‘users’
}
}
});

//pegar referência do model
var User = Ext.getModel(‘User’);

//criar um usuário
var ed = Ext.create(‘User’, {
name: ‘Ed Spencer’,
age : 25
});

//salvar diretamente sem intervenção de stores
ed.save({
success: function(ed) {
console.log("Saved Ed! His ID is "+ ed.getId());
}
});

//ou carregar
User.load(123, {
success: function(user) {
console.log("Loaded user 123: " + user.get(‘name’));
}
});[/javascript]

Temas

O pacote de temas foi alterado radicalmente, e posso dizer que ficou anos-luz a frente da versão anterior. Isso porque todas as imagens sprite para criar cantos arredondados e degradês foram removidas! Tudo agora é feito por CSS, e para o IE6 parece que existe uma solução que cria as imagens sprites sob demanda (confesso não me interessar muito, não dou suporte pra IE6).

Para começar, está sendo utilizado SASS e Compass. SASS é uma ferramenta para deixar o CSS mais legal, permitindo variáveis, funções, enfim, uma nova forma de escrever CSS. Compass é uma biblioteca com funções padrões SASS, para criar degradês, cantos arredondados, e demais efeitos. Essas alterações realmente me agradaram, porque criar temas no Ext era MUITO chato. Para alterar a cor de um simples botão era preciso mudar o sprite inteiro do botão, nos estados normal, pressionado, com o mouse em cima, etc etc etc… chato, chato, chato. Agora é só usar um mixin (uma função CSS) para criar botões das mais diferentes cores.

Conclusões

Como comentei, esse post foi somente para me colocar de volta à escrita e publicar minhas considerações sobre o Ext 4. Eu espero trazer em breve mais conteúdo educacional a medida que eu vou me aprofundando e descobrindo as mudanças do Ext 4.0.

Por agora vou iniciar a mudança de um sistema iniciando pelos temas. Melhor lugar para começar é com a apresentação do Sencha Conf Theming ExtJS 4.0. Vou tentar me localizar com essa nova estrutura de diretórios e publico pra vocês as novidades.

Um forte abraço!