Author: Andreia.Bellini
Date: 2010-02-25 03:00:40 +0100 (Thu, 25 Feb 2010)
New Revision: 28263
Modified:
doc/branches/1.4/more-with-symfony/pt/05-Custom-Widgets-and-Validators.markdown
doc/branches/1.4/more-with-symfony/pt/08-Advanced-Doctrine-Usage.markdown
Log:
corrections: chapter 05 and 08
Modified:
doc/branches/1.4/more-with-symfony/pt/05-Custom-Widgets-and-Validators.markdown
===================================================================
---
doc/branches/1.4/more-with-symfony/pt/05-Custom-Widgets-and-Validators.markdown
2010-02-25 01:46:16 UTC (rev 28262)
+++
doc/branches/1.4/more-with-symfony/pt/05-Custom-Widgets-and-Validators.markdown
2010-02-25 02:00:40 UTC (rev 28263)
@@ -1,11 +1,11 @@
-Widgets e Validators Personalizados
-===================================
+Widgets e Validadores Personalizados
+====================================
-* por Thomas Rabaix *
+*por Thomas Rabaix*
-Este capítulo explica como criar um widget e validadores personalizados para
uso
+Este capítulo explica como criar *widgets* e validadores personalizados para
uso
no framework de formulário. Ele irá explicar os detalhes internos de
`sfWidgetForm` e
-`sfValidator`, bem como a forma de construir tanto um widget simples quanto um
complexo.
+`sfValidator`, bem como a forma de construir tanto um *widget* simples quanto
um complexo.
Por Dentro do Widget e Validator
------------------------------
@@ -28,15 +28,15 @@
Embora não seja uma boa prática para substituir o construtor, o método
`configure()`
pode ser facilmente substituído.
-* `render()`: saídas de HTML para o widget. O método tem uma primeiro
argumento obrigatório,
+* `render()`: saídas de HTML para o widget. O método tem um primeiro argumento
obrigatório,
o nome do elemento HTML, e um segundo argumento opcional,
o valor.
-> **NOTE**
-> Um objeto `sfWidgetForm` não sabe nada sobre o seu nome ou o seu valor.
-> O componente é responsável apenas pela prestação do widget. O nome e
-> o valor são geridos por um objeto `sfFormFieldSchema`, que é o link
-> entre os dados e os widgets.
+>**NOTE**
+>Um objeto `sfWidgetForm` não sabe nada sobre o seu nome ou o seu valor.
+>O componente é responsável apenas pela prestação do widget. O nome e
+>o valor são geridos por um objeto `sfFormFieldSchema`, que é o link
+>entre os dados e os widgets.
### Por Dentro do sfValidatorBase
@@ -44,15 +44,15 @@
~`sfValidatorBase::clean()`~ é o método mais importante desta classe
pois ele verifica se o valor é válido, dependendo das opções fornecidas.
-Internamente, o método `clean()` realiza várias acções diferentes:
+Internamente, o método `clean()` realiza várias ações diferentes:
* Retira os espaços no início e no final do valor de entrada para valores
string (se especificado através da opção `trim`)
* Verifica se o valor é vazio
-* Chama o método `doclean()` do validador.
+* Chama o método `doClean()` do validador.
O método `doClean()` é o método que implementa a lógica principal de validação.
-Não é boa prática para sobrescrever o método `clean()`. Em vez disso,
-sempre execute qualquer lógica personalizada através do método `doClean()`.
+Não é uma boa prática sobrescrever o método `clean()`. Em vez disso,
+customize a lógica do método `doClean()`.
O validador também pode ser usado como um componente independente para
verificar a integridade de entrada.
Por exemplo, a validador sfValidatorEmail irá verificar se o e-mail é válido:
@@ -69,29 +69,29 @@
$this->forward404();
}
-> **NOTE**
-> Quando um formulário está vinculado aos valores de solicitação, o objeto
`sfForm` mantém
-> referências aos valores originais (dirty, "sujos") e os valores validados
(clean, "limpos").
-> Os valores originais são usados quando o formulário é redesenhado, enquanto
-> os valores "cleaned" são utilizados pela aplicação (por exemplo, para salvar
o objeto).
+>**NOTE**
+>Quando um formulário está vinculado aos valores de solicitação, o objeto
`sfForm` mantém
+>referências aos valores originais (*dirty*, "sujos") e os valores validados
(*clean*, "limpos").
+>Os valores originais são usados quando o formulário é redesenhado, enquanto
+>os valores *cleaned* são utilizados pela aplicação (por exemplo, para salvar
o objeto).
### O atributo `options`
-Tanto o `sfWidgetForm` e `sfValidatorBase` objetos têm uma variedade de opções:
-algumas são opcionais, enquanto outras são obrigatórias. Estas opções são
definidas
+Tanto o objeto `sfWidgetForm` quanto o `sfValidatorBase` têm uma variedade de
opções:
+algumas opcionais, outras obrigatórias. Estas opções são definidas
dentro do método `configure()` de cada classe através de:
* `AddOption($name, $value)`: define uma opção com um nome e um valor padrão
* `AddRequiredOption($name)`: define uma opção obrigatória
Estes dois métodos são muito convenientes pois garantem que os valores de
dependência
-são corretamente passados para o validador ou o widget.
+são passados corretamente para o validador ou o widget.
-Construir um Widget e Validator Simples
+Construindo um Widget e Validator Simples
--------------------------------------
Esta seção irá explicar como criar um widget simples. Este elemento particular
-será chamado de "Trilean widget". O widget exibirá uma caixa de seleção com
três opções:
+será chamado de "Trilean" widget. O widget exibirá uma caixa de seleção com
três opções:
`Não`, `Sim` e `Nulo`.
[php]
@@ -120,14 +120,14 @@
$attributes ['selected'] = 'selected';
}
- $options [] = $this->renderContentTag (
+ $options [] = $this->renderContentTag(
'option',
self::escapeOnce($option),
$attributes
);
}
- return $ this-> renderContentTag (
+ return $this->renderContentTag(
'select',
"\n". implode ("\n", $options). "\n",
array_merge(array('name' => $name), $attributes
@@ -135,10 +135,10 @@
}
}
-O método `configure()` define a lista de valores de opção através da opção
`choices`.
+O método `configure()` define a lista de valores da opção através da opção
`choices`.
Este array pode ser redefinido (ou seja, para alterar o rótulo associado a
cada valor).
Não há limite para o número de opções que um widget pode definir.
-A classe Widget base, no entanto, declara algumas opções padrão, que funcionam
de-facto
+A classe base widget, no entanto, declara algumas opções padrões, que
funcionam *de-facto*
como opções reservadas:
* `id_format`: o formato de id, o padrão é '%s'
@@ -208,7 +208,7 @@
`null` como um valor válido, o método deve voltar sempre `falso`.
**NOTE**
-> Se `isEmpty()` retorna true, o método `doClean()` método nunca será chamado.
+>Se `isEmpty()` retorna true, o método `doClean()` método nunca será chamado.
Embora este widget seja bastante simples, ele apresenta algumas
características de base importantes
que serão necessárias mais adiante. A próxima seção irá criar um widget mais
@@ -219,7 +219,7 @@
Nesta seção, vamos construir um widget complexo. Novos métodos serão
introduzidos e o widget terá alguma interação JavaScript também.
-O widget será chamado de "GMAW": "Google Map Address Widget".
+O widget será chamado de "GMAW": "*Google Map Address Widget*".
O que queremos alcançar? O widget deve fornecer uma maneira fácil para o
usuário final para adicionar um endereço. Ao utilizar um campo de texto e com
os
@@ -354,7 +354,7 @@
$value['longitude'] = isset($value['longitude']) ?
$value['longitude'] : ''; $ value [ 'longitude']:'';
$value['latitude'] = isset($value['latitude']) ? $value['latitude']
: ''; $ value [ 'latitude']:'';
- / / Define o widget address
+ // Define o widget address
$address = new sfWidgetFormInputText(array(),
$this->getOption('address.options'));
$template_vars['{input.search}'] =
$address->render($name.'[address]', $value['address']);
@@ -363,7 +363,7 @@
$template_vars['{input.longitude}'] =
$hidden->render($name.'[longitude]', $value['longitude']);
$template_vars['{input.latitude}'] =
$hidden->render($name.'[latitude]', $value['latitude']);
- / / Mesclarmodelos e variáveis
+ // Mescla modelos e variáveis
return strtr(
$this->getOption('template.html').$this->getOption('template.javascript'),
$template_vars
@@ -387,7 +387,7 @@
para o bloco de JavaScript (através da variável `template.js`), pelo qual o
JavaScript pode
tratar adequadamente os diferentes elementos.
-O método `rende ()` também instancia dois widgets internos: um widget
`sfWidgetFormInputText`,
+O método `render()` também instancia dois widgets internos: um widget
`sfWidgetFormInputText`,
que é usado para processar o campo `address` e um widget
`sfWidgetFormInputHidden`,
que é usado para processar os campos ocultos.
@@ -432,7 +432,7 @@
O objeto JavaScript tem alguns métodos interessantes:
* `init()`: o método em que todas as variáveis são inicializadas e eventos
- inputs
+ para diferentes inputs
* `lookupCallback()`: um método *estático* usado pelo método de geocoder
pesquisar o endereço fornecido pelo usuário
@@ -443,7 +443,7 @@
O código JavaScript final pode ser visto no Apêndice A.
Por favor, consulte a documentação do Google map para obter mais detalhes
sobre a funcionalidade
-do Google Maps [API](http://code.google.com/apis/maps/).
+do Google maps [API](http://code.google.com/apis/maps/).
### Validador `sfValidatorGMapAddress`
@@ -452,7 +452,7 @@
o valor não pode ser `null`. Assim, `sfValidatorGMapAddress` só precisa validar
os diferentes valores: `latitude`, `longitude` e `address`. A variável
`$value`
deve ser um array, mas como não se deve confiar na entrada do usuário, o
validador
-verifica a presença de todas as chaves para que os validadores internos passam
valores válidos.
+verifica a presença de todas as chaves para que os validadores internos passam
valores válidos.
[php]
@@ -460,7 +460,7 @@
{
protected function doClean($value)
{
- if (! if (!is_array($value))
+ if (! if(!is_array($value))
{
throw new sfValidatorError($this, 'invalid');
}
@@ -488,14 +488,14 @@
>**NOTE**
>Um validador sempre lança uma `excepção` `sfValidatorError` quando um valor
>não é
>válido. Por isso, a validação é cercada por um bloco `try/catch`.
->Neste validador, o validador re-lança uma nova excepção `invalid`, que
+>Neste validador, a validação re-lança uma nova excepção `invalid`, que
>equivale a um erro de validação `invalid` no validador
>`sfValidatorGMapAddress`.
### Testando
-Por que o teste é importante? O validador é a cola entre a entrada do usuário
-e a aplicação. Se o validador é falho, a aplicação é vulnerável.
+Por que o teste é importante? O validador é a ponte entre a entrada do usuário
+e a aplicação. Se o validador é falho, a aplicação esta vulnerável.
Felizmente, o symfony vem com o `lime` que é uma biblioteca de testes
muito fácil de usar.
@@ -541,11 +541,11 @@
de cada validador. Este teste reproduz este comportamento instanciando
o validador `sfValidatorGMapAddress` diretamente e testa diferentes valores.
-Reflexões Finais
+Considerações Finais
--------------
-O erro mais comum durante a criação de um widget é ser focar excessivamente em
+O erro mais comum durante a criação de um *widget* é ser focar excessivamente
em
como as informações serão armazenadas no banco de dados. O framework
formulário é
simplesmente um contêiner de dados e um framework de validação. Portanto, um
widget deve
gerenciar somente a sua informação relacionada. Se os dados forem válidos, em
seguida, os diferentes
-valores limpos poderão então ser utilizada pelo model ou no controller.
\ No newline at end of file
+valores limpos poderão então ser utilizados no modelo ou no controlador.
\ No newline at end of file
Modified:
doc/branches/1.4/more-with-symfony/pt/08-Advanced-Doctrine-Usage.markdown
===================================================================
--- doc/branches/1.4/more-with-symfony/pt/08-Advanced-Doctrine-Usage.markdown
2010-02-25 01:46:16 UTC (rev 28262)
+++ doc/branches/1.4/more-with-symfony/pt/08-Advanced-Doctrine-Usage.markdown
2010-02-25 02:00:40 UTC (rev 28263)
@@ -1,21 +1,21 @@
-Uso Avançado do Doctrine
-========================
+Uso Avançado do Doctrine
+=======================
-* Por Jonathan H. Wage *
+*Por Jonathan H. Wage*
-Criando um comportamento para Doctrine
---------------------------------------
+Criando um Comportamento no Doctrine
+---------------------------
-Nesta seção vamos demonstrar como você pode escrever um comportamento usando
Doctrine 1.2.
+Nesta seção vamos demonstrar como você pode escrever um comportamento
(*behavior*) usando Doctrine 1.2.
Iremos criar um exemplo que lhe permitirá manter facilmente um contador em
cache dos relacionamentos
-de modo que você não terá que consultar a contagem a todo momento.
+de modo que você não terá que consultar o contador a todo momento.
A funcionalidade é bastante simples. Para todos os relacionamentos que você
deseja manter
um contador, o comportamento irá adicionar uma coluna ao modelo para armazenar
a contagem atual.
-### O Schema
+### O Esquema
-Aqui está o Schema que você irá utilizar para começar. Mais tarde vamos
modificá-lo e adicionar a
+Aqui está o esquema (*schema*) que você irá utilizar para começar. Mais tarde
vamos modificá-lo e adicionar a
definição do `actAs` para o comportamento que estamos prestes a escrever:
[yml]
@@ -39,13 +39,13 @@
onDelete: CASCADE
foreignAlias: Posts
-Agora podemos criar tudo para este schema:
+Agora podemos criar tudo para este esquema:
- $ php symfony doctrine:build all
+ $ php symfony doctrine:build --all
### O Template
-Primeiro, precisamos escrever uma classe de template (modelo)
`Doctrine_Template` filha que será
+Primeiro, precisamos escrever uma classe filha de `Doctrine_Template` que será
responsável por adicionar as colunas ao modelo que irá armazenar a contagem.
Você pode simplesmente colocá-lo em qualquer diretório `lib/` do projeto que o
symfony
@@ -79,11 +79,11 @@
Quando a informação de mapeamento de um modelo é instanciada, quaisquer
comportamentos ligados
terão os métodos `setTableDefinition()` e `setUp()` invocados. Da mesma forma
que você têm
na classe `BasePost` em `lib/model/doctrine/base/BasePost.class.php`. Isto
-lhe permite adicionar coisas para qualquer modelo de modo plug n' play. Isto
pode estar
-nas colunas, relacionamentos, ouvintes de eventos, etc
+lhe permite adicionar coisas para qualquer modelo de modo *plug n' play*. Isto
pode ser
+nas colunas, relacionamentos, ouvintes de eventos (*event listeners*), etc.
Agora que você entende um pouco sobre o que está acontecendo, vamos fazer o
-comportamento `CountCache` realmente fazer alguma coisa:
+comportamento `CountCache` fazer alguma coisa de fato:
[php]
class CountCache extends Doctrine_Template
@@ -105,16 +105,16 @@
// Adiciona a coluna ao modelo relacionado
$columnName = $this->_options['relations'][$relation]['columnName'];
$relatedTable = $this->_table->getRelation($relation)->getTable();
- $ this-> _OPTIONS [ 'Relações'] [$ relation] [ 'className'] = $
RelatedTable-> GetOption ( 'nome');
+ $this->_options['relations'][$relation]['className'] =
$relatedTable->getOption('name');
$relatedTable->setColumn($columnName, 'integer', null,
array('default' => 0));
}
}
-O código acima irá agora adicionar colunas para manter a contagem do modelo
relacionados.
+O código acima irá adicionar colunas para manter a contagem do modelo
relacionado.
Portanto, no nosso caso, estamos adicionando o comportamento ao modelo `Post`
para o relacionamento
-com `Thread` Nós queremos manter o número de posts qualquer instancia de
`Thread`
-tem em uma coluna chamada `num_posts`. Então agora modifique o YAML schema
para
+com `Thread`. Nós queremos manter o número de posts que qualquer instância de
`Thread`
+tem em uma coluna chamada `num_posts`. portanto modifique o esquema YAML para
definir as opções adicionais para o comportamento:
[yml]
@@ -129,14 +129,14 @@
foreignAlias: Posts
# ...
-Agora, o modelo `Thread` tem uma coluna `num_posts`que irá manter-se atualizada
+Agora o modelo `Thread` possui uma coluna `num_posts`que irá manter-se
atualizada
com o número de posts que cada thread tem.
-### O Ouvinte de Eventos
+### O Ouvinte de Eventos (*Event Listener*)
-O próximo passo para a construção do comportamento é escrever um ouvinte de
evento registrador
+O próximo passo para a construção do comportamento é escrever um registrador
de ouvintes de evento (*record event listener*)
que será responsável por manter a contagem atualizada quando inserirmos novos
registros,
-excluir um registro ou executar DQL de exclusão de registros em lote:
+excluirmos um registro ou executarmos DQL de exclusão de registros em lote:
[php]
class CountCache extends Doctrine_Template
@@ -151,9 +151,9 @@
}
}
-Antes de prosseguirmos, precisamos definir a `classe` CountCacheListener que
-extende `Doctrine_Record_Listener`. Ele aceita uma variedade de opções que são
simplesmente
-transmitidos ao ouvinte a partir do modelo:
+Antes de prosseguirmos, precisamos definir a classe `CountCacheListener` que
+extende `Doctrine_Record_Listener`. Ela aceita uma variedade de opções que são
simplesmente
+repassadas ao ouvinte a partir do modelo:
[php]
// lib/model/count_cache/CountCacheListener.class.php
@@ -195,7 +195,7 @@
$table
->createQuery()
->Update()
- ->set($options['columnName'], $options['columnName'].' +1)
+ ->set($options['columnName'], $options['columnName'].' +1')
->where($relation['local'].' = ?', $invoker->$relation['foreign'])
->execute();
}
@@ -203,15 +203,15 @@
}
O código acima irá incrementar a contagem em um para todas os relacionamentos
configurados
-mediante a emissão de uma instrução DQL UPDATE quando um novo objeto como é
inserido abaixo:
+mediante a emissão de uma instrução DQL UPDATE quando um novo objeto como é
inserido, conforme o exemplo abaixo:
[php]
$post = new Post();
- $ post-> thread_id = 1;
+ $post->thread_id = 1;
$post->body = 'corpo da mensagem';
$post->save();
-O `Thread` com o `id` `1` terá a coluna `num_posts` coluna incrementado em `1`.
+O `Thread` com o `id` `1` terá a coluna `num_posts` incrementada em `1`.
Agora que o contador está sendo incrementado quando novos objetos são
inseridos, nós
precisamos manipular quando objetos são excluídos e diminuir o contador.
Faremos isso
@@ -241,7 +241,7 @@
}
O método `postDelete()` acima é quase idêntico ao `postInsert`. A
-única diferença é que nós diminuiremos a coluna `num_posts` em 1 ao invés de
+única diferença é que nós diminuiremos a coluna `num_posts` em `1` ao invés de
incrementá-lo. Ele manipularia o seguinte código se fôssemos remover o
registro `$post`
salvo previamente:
@@ -282,12 +282,12 @@
}
}
-O código acima clona a instrução `DQL DELETE` e transformá-lo em um `SELECT`
que
+O código acima clona a instrução `DQL DELETE` e transformá-a em em um `SELECT`
que
nos permite recuperar os `ID`s que serão excluídos, para que possamos
atualizar o contador
desses registros que foram excluídos.
-Agora, temos o seguinte cenário cuidando de que o contador será decrementado
-se tivéssemos de fazer o seguinte:
+Agora, temos o seguinte cenário tratado e os contadores serão decrementados
+se fizéssemos o seguinte:
[php]
Doctrine::getTable('Post')
@@ -306,7 +306,7 @@
->where('body LIKE ?', '%cool%')
->execute();
->**NOTA**
+>**NOTE**
>Para que o método `preDqlDelete()` seja invocado você deve habilitar
>um atributo. Os retornos DQL estão desligados por padrão devido a eles terem
>um custo
>um pouco maior. Então se você quiser usá-los, você deve habilitá-los.
@@ -340,7 +340,7 @@
$ php symfony doctrine:build --all --and-load
Agora tudo está criado e a massa de dados está carregada, por isso vamos
executar um teste para ver
-Se os contadores foram mantidas atualizados:
+se os contadores foram mantidas atualizados:
$ php symfony doctrine:dql "FROM Thread t, t.Posts p"
doctrine - executing: "FROM Thread t, t.Posts p" ()
@@ -396,7 +396,7 @@
->where('body LIKE ?', '%legal%')
->execute();
-Agora nós excluimos todos as mensagens relatadas e o valor de `num_posts`
deverá ser zero:
+Agora nós excluimos todas as mensagens relacionadas e o valor de `num_posts`
deverá ser zero:
$ php symfony doctrine:dql "FROM Thread t, t.Posts p"
doctrine - executing: "FROM Thread t, t.Posts p" ()
@@ -405,22 +405,22 @@
doctrine - num_posts: '0'
doctrine - Posts: { }
-E é isso! Espero que este artigo seja útil tanto no sentido de que você aprenda
-algo sobre os comportamentos e os comportamentos em si também sejam úteis à
você!
+E é isso! Espero que este artigo seja útil tanto no sentido de que você
aprendeu
+algo sobre os comportamentos e que os comportamentos em si também sejam úteis
à você!
Usando o Cache de Resultados do Doctrine
-----------------------------
Em aplicações web de tráfego pesado é comum necessitar de um cache de
informações
-para salvar recursos de CPU. Com a última versão do Doctrine 1.2 fizemos um
monte de
+para poupar recursos de CPU. Com a última versão do Doctrine 1.2 fizemos um
monte de
melhorias no cache de conjunto de resultados que lhe dará muito mais controle
sobre
-a remoção de entradas no cache a partir dos controladore de cache.
Anteriormente não era possível
+a remoção de entradas no cache a partir dos controladores de cache.
Anteriormente não era possível
especificar a chave de cache usado para armazenar a entrada no cache, então
você não podia realmente
-identificar a entrada de cache a fim de excluí-lo.
+identificar a entrada de cache a fim de excluí-la.
Nesta seção, mostraremos um exemplo simples de como você pode utilizar o
cacheamento de conjunto de resultados
para cachear todas as consultas relacionadas a seu usuário, bem como o uso de
eventos para se certificar
-de que eles sejam devidamente apurados quando alguns dado for alterado.
+de que eles sejam devidamente limpos quando alguns dadoa forem alterados.
### Nosso Schema
@@ -460,7 +460,7 @@
{
}
-Mais tarde no artigo você vai precisar adicionar algum código para esta classe
para fazer a anotação da mesma.
+Mais tarde, no artigo, você vai precisar adicionar algum código a esta classe
para fazer a anotação da mesma.
### Configurando o Cache de Resultado
@@ -491,7 +491,7 @@
### Consultas de exemplo
-Agora imagine que em sua aplicação você tem um grande número de consultas
realcioniona ao usuário
+Agora imagine que em sua aplicação você tem um grande número de consultas
relacionadas ao usuário
e quer apurá-los sempre que algum dado do usuário for alterado.
Aqui está uma consulta simples que podemos usar para processar uma lista de
usuários ordenados
@@ -507,21 +507,21 @@
[php]
$q->useResultCache(true, 3600, 'users_index');
->**NOTA**
+>**NOTE**
>Observe o terceiro argumento. Esta é a chave que será usada para armazenar a
>entrada
> cacheada para os resultados no controlador de cache. Isso nos permite
> identificar facilmente
>esta consulta e excluí-la do controlador de cache.
-Agora, quando executarmos a consulta quirá irá consultar o banco de dados para
buscar os resultados e armazená-
+Agora, quando executarmos a consulta que irá consultar o banco de dados para
buscar os resultados e armazená-
los no controlador de cache na chave chamada `users_index` e todas as
requisições posteriores
obterão as informações do controlador de cache em vez de pedir ao banco de
dados:
[php]
$users = $q->execute();
->**NOTA**
+>**NOTE**
>Isso não somente economiza o processamento no servidor de banco de dados, ele
>também ignora
-> o processo inteiro de hidratação que é como o Doctrine armazena os dados
hidratado. Isso significa
+> o processo inteiro de hidratação que é como o Doctrine armazena os dados
hidratados. Isso significa
> que irá também aliviar um pouco o processamento do seu servidor web.
Agora, se verificar no controlador de cache, você vai ver que existe uma
entrada chamada
@@ -548,7 +548,7 @@
Primeiro vamos apenas demonstrar a API crua do controlador de cache antes de
implementá
-lo em um evento.
->**Dica**
+>**TIP**
> Para ter acesso à instância do controlador de cache de resultado você pode
> recuperá-lo a partir da
> instância da classe `Doctrine_Manager`.
>
@@ -581,7 +581,7 @@
* `deleteBySuffix($suffix)`: Exclui as entradas de cache que combinem com o
sufixo
passado;
-* `deleteByRegex($regex)`: Exclui as entradas de cache que correspondam à
+* `deleteByRegularExpression($regex)`: Exclui as entradas de cache que
correspondam à
expressão regular passada;
* `deleteAll()`: Exclui todas as entradas de cache.
@@ -610,11 +610,11 @@
}
Agora, se fôssemos atualizar um usuário ou inserir um novo ele iria limpar o
cache para
-todas as consultas relarionadas ao usuário:
+todas as consultas relacionadas ao usuário:
[php]
$user = new User();
- $user->username = 'jorge';
+ $user->username = 'jwage';
user->password = 'mudeme';
$user->save();
@@ -624,11 +624,11 @@
Embora esse exemplo seja muito simples, ele demonstra muito bem como você pode
usar esses recursos para implementar um cacheamento refinado em suas consultas
Doctrine.
-Criando Hydratador Doctrine
+Criando Hidratador Doctrine
---------------------------
Uma das principais características do Doctrine é a capacidade de transformar
um objeto `Doctrine_Query`
-em várias estruturas de conjunto de resultado. Este é o trabalho dos
hidratadores do
+em várias estruturas de conjunto de resultados. Este é o trabalho dos
hidratadores do
Doctrine e até a versão 1.2, o hidratadores eram todos codificados rigidamente
e não
eram abertos aos desenvolvedores para serem personalizados. Agora que isto
mudou, é possível
escrever um hidratador personalizado e criar qualquer estrutura de dados que
for desejado
@@ -657,11 +657,11 @@
# data/fixtures/data.yml
User:
user1:
- username: jorge
+ username: jwage
password: mudeme
is_active: 1
user2:
- username: jorjao
+ username: jonwage
password: mudeme
is_active: 0
@@ -669,7 +669,7 @@
$ php symfony doctrine:build --all --and-load
-### Escrevendo o Hydratador
+### Escrevendo o Hidratador
Para escrever um hidratador tudo o que precisamos fazer é escrever uma nova
classe que se estende `Doctrine_Hydrator_Abstract`
e devemos implementar um método `hydrateResultSet($stmt)`. Ele recebe a
instância do `PDOStatement`
@@ -751,9 +751,9 @@
Array
(
- [jorge] => 1
- [jorjao] => 0
+ [jwage] => 1
+ [jonwage] => 0
)
Bem, é isso! Simplesmente lindo não? Espero que isso seja útil a você e como
resultado
-a comunidade terá alguns novos e impressivos hidratadores contribuídos.
\ No newline at end of file
+a comunidade terá contribuições de alguns novos e expressivos hidratadores.
\ No newline at end of file
--
You received this message because you are subscribed to the Google Groups
"symfony SVN" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/symfony-svn?hl=en.
