Os 7 erros mais comuns ao utilizar o Adianti Framework

Fechado

Pablo Dall'Oglio 05/08/2013 (há 11 anos)

Neste artigo procuro elencar alguns dos principais erros cometidos por quem está iniciando com o Adianti Framework.

1) Esquecer de executar o construtor da classe-pai
Este erro ocorre quando você criou uma nova classe controladora de páginas, e em seu método construtor esqueceu de chamar o construtor da classe-pai (parent::__construct()).

Como consequência deste esquecimento, você verá na web os símbolos (<>) antes da apresentação da página. Já no Gtk, a aplicação terminará com o erro (Internal object missing in FormCustomView wrapper). Sempre lembre de executar o construtor da classe-pai, como no exemplo a seguir.

<?php
class FormCustomView extends TPage
{
function __construct()
{
parent::__construct(); // importante !
}
}
?>

2) Esquecer do setFields()

Muitos erros de utilização de formulários no Adianti Framework recaem sobre o método setFields(). Os desenvolvedores constróem o formulário, colocam os campos dentro dele (por tabela ou painel), bem como os botões de ação. Em seguida clicam no botão de ação e os dados não são enviados.

O método setFields() serve justamente para dizer para a classe TForm quais elementos ela deve gerenciar. Se você esquecer de executar este método, ela não irá gerenciar nenhum elemento, e a postagem não ocorrerá. Até mesmo os botões de ação devem ser passados para o setFields(), pois o botão também é um elemento que faz parte da lógica de execução do formulário.

<?php
$this->form = new TForm;
// add a row for one field
$row=$table->addRow();
$row->addCell(new TLabel('Field 1:'));
$cell = $row->addCell( $field1 );
// creates the action button
$button1=new TButton('action1');
$button1->setAction(new TAction(array($this, 'onSave')), 'Save');
$button1->setImage('ico_save.png');
// define wich are the form fields
$this->form->setFields(array($field1, $field2, ..., $button1));
?>

3) Esquecer de executar o createModel ou executar no momento errado

Outro erro muito comum é esquecer de executar o método createModel() após adicionar as colunas e ações de uma datagrid. Este método cria a datagrid em memória e é necessário ser executado antes de adicionarmos itens na datagrid e antes de a mesma ser exibida em tela. Caso você se esquecer de executar este método, a datagrid não será exibida. A datagrid não funcionará também se você executar este método antes de adicionar as colunas e ações na datagrid. A partir da versão 1.0.2, exceções são lançadas caso você execute o createModel() na ordem errada ou esqueça de executá-lo. A seguir, a correta ordem de execução:

<?php
$this->datagrid = new TDataGrid;
// add the columns to the datagrid
$this->datagrid->addColumn($code);
$this->datagrid->addColumn($name);
// creates two datagrid actions
$action1 = new TDataGridAction(array($this, 'onView'));
$action1->setLabel('View');
$action1->setImage('ico_find.png');
$action1->setField('name');
// add the actions to the datagrid
$this->datagrid->addAction($action1);
$this->datagrid->addAction($action2);
// creates the datagrid model
$this->datagrid->createModel();
?>

4) Adicionar dois campos com o mesmo nome do formulário

Jamais crie dois campos com o mesmo name em um formulário. O parâmetro recebido no método construtor dos campos repesenta seu nome, e identifica unicamente o objeto que está sendo manipulado pela classe TForm. Caso você crie dois campos com o mesmo name, apenas um deles será postado. Muitas pessoas acreditam que é o nome da variável que distingue um campo de outro, mas é seu nome (parâmetro do construtor). A partir da versão 1.0.2, uma exceção é lançada caso você acrescente dois campos com o mesmo nome no form. Confira a seguir um exemplo deste erro.

<?php
$field1 = new TEntry('field1');
$field2 = new TEntry('field1');
?>

5) Não alterar o APPLICATION_NAME nos dois arquivos necessários

A constante APPLICATION_NAME identifica o nome da aplicação em execução. Mas para que ela serve? As sessões são armazenadas levando em consideração esta constante para isolar as sessões entre uma e outra aplicação. Ela está definida em dois arquivos: engine.php e index.web.php. O problema é que muitas pessoas alteram ela em um arquivo e esquecem de alterar no outro. Qual o problema que isso acarreta? Tudo que envolve sessões fica comprometido e o primeiro ponto em que isso é perceptível é na tela de login, que deixa de funcionar. Portanto, se você for alterar esta constante, lembre de alterar nos dois arquivos.

<?php
define('APPLICATION_NAME', 'framework');
?>

6) Erros de acentuação

Em algumas vezes a aplicação não apresenta os caracteres acentuados da maneira correta, o que fazer? Todo o framework foi projetado para funcionar em UTF8. Assim, os arquivos devem estar neste encoding no momento de salvá-los em disco. Além disso, a base de dados deve também estar nessa codificação. Caso a base de dados esteja em ISO-8859-1, teremos caracteres sendo apresentados de maneira errada. Portanto, lembre-se que tudo deve estar em UTF8.

Obs: Se você usa Mysql, favor ler este post: www.adianti.com.br/forum/pt/view_572?acentos-utf-8

7) Tradução não realizada (Message not found:...)

Em algumas situações, a string (Message not found:...) é apresentada em tela, mas o que ela significa? Significa que você está usando as funcionalidades de tradução do framework, mas não cadastrou os termos no dicionário de traduções, mas como?

Sempre que você utilizar a função _t(), como em: _t('Label'), o framework vai buscar no dicionário de traduções pelo termo traduzido, conforme o idioma definido pelo método TApplicationTranslator::setLanguage() no engine.php. Estes termos traduzidos ficam localizados no arquivo app/lib/util/TApplicationTranslator.class.php e devem ser cadastrados por você na forma de vetor:

<?php
class TApplicationTranslator
{
// ...
private function __construct()
{
$this->messages['en'][] = 'File not found';
$this->messages['en'][] = 'Search';
$this->messages['en'][] = 'Register';
$this->messages['pt'][] = 'Arquivo não encontrado';
$this->messages['pt'][] = 'Buscar';
$this->messages['pt'][] = 'Cadastrar';
}
}
?>

Por fim, alguns se questionarão: Será que alguns destes erros não poderiam ser evitados? Certamente que sim. A próxima versão do framework (1.0.2), que está em desenvolvimento terá um maior número de críticas a serem realizadas sobre o código do desenvolvedor. Tudo para que ele saiba com maior precisão e velocidade onde está o erro.

um abraço!

Comentários (1)