Método para Gerar Índice para HTML com JS

var htmlMenu = {
    generate : function htmlMenu(id) {
        var headers = {};
        var stack = [];
        var lastLevel = 0;
        var text,level;
        var levels = {'H1':0,'H2':1,'H3':2,'H4':3,'H5':4}
        var menu = '';
        $('#' + id + ' :header').each(function(a){
            actualLevel = levels[this.nodeName];
            if(actualLevel < lastLevel) {
              for(var r = actualLevel+1; r <= lastLevel; r++) {
                  delete stack[r];
              }
            }
            text = $(this).html();
            if(stack[actualLevel] == undefined) {
                stack[actualLevel] = 1;
            }
            else {
                stack[actualLevel]++;
            }
            var index = '';
            var first = true;
            for(i in stack) {
                index += (first ? '' : '.') + stack[i];
                first = false;
            }
            headers[index] = text;
            $(this).append('<a name =" '">');
            menu += "<a href="'#">" + index + " - " + text + "</a><br/>";
            lastLevel = actualLevel;
        })
        return menu;
    }
};

Ver um Json no Browser Firefox de uma maneira decente.

Para ver um Json no firefox, use este plugin:

http://benhollis.net/blog/2009/02/24/jsonview-view-json-documents-in-firefox/

Tá difícil escrever testes para o seu código?

Claro que sim. Você escreveu o código primeiro. Que tal escrever código para os seus testes. Agora sim. Se precisar de refactoring, os testes garantem. Agora aquele código sem testes vai ter que ter refactoring para poder ser testado? Duas perdas de tempo:

1 refactoring sem uma malha de testes (tortura é bem parecido)
2 escrever testes tão depois de escrever código.

Além disso com certeza aí tem código inútil.... não foi escrito para passar nos testes, mas sim por que talvez um dia você possa precisar não é mesmo? O nome desse código para alguns pode ser "visão de futuro", mas para mim chama "teia de aranha". Só serve para se enrolar nele e atrapalhar um caminhar mais direto.

Digo isso vivi isso no dia a dia agorinha mesmo. Testes primeiro, caminho tranquilo, por a cabeça no travesseiro e dormir...

Gerenciando plugins em um repositório separado com svn:externals.

Se temos um código que queremos usar em dois projetos, mas por algum motivo, não queremos manter em um lugar centralizado e usar o "include_path" do php. Podemos criar um repositório só para este código e gerencia-lo como um novo projeto.

Este recurso é muito útil para plugins que são usados em mais de um projeto. Procurando na net é um tanto fraca a documentação a respeito de como usar o recurso svn:externals. No svn book ele mostra as informações fragmentadas e não o processo todo.

Neste texto eu descrevo o processo de criar um novo repositório, exportar os arquivos para ele e então gerar o link do externals apontando para o novo repositório. Vou descrever boa parte destas tarefas considerando o uso do tortoise no lado do cliente, mas a parte do externals também vou colocar a linha de comando, visto que a documentação no livro é muito fragmentada.

1 - Exportar o arquivos para uma nova pasta.

Usando o tortoise, escolhemos a pasta e selecionamos "export". Isso irá criar uma nova pasta não versionada, com tudo o que tinha ali dentro. Não versionada quer dizer sem aquele monte de .svn que ele cria.

2 - Criar o repositório no servidor.

svnadmin create jsCallPlugin

Neste ponto é importante verificar se a pasta tem permissões para ser alterada pelo usuário do svn. Existem várias maneiras de se fazer isso, mas uma que pode ser utilizada é atribuir ao diretório um grupo compartilhado por todos os usuários do svn.

3 - Fazer um check out do repositório na sua máquina.

com o tortoise, é só clicar na pasta e então escolher o checkout, colocar o endereço e pronto.

4 - Mandar os arquivos pro novo repositório.

Lembra aqueles arquivos que fizemos export. Pois é, estes arquivos devem ser copiados para o repositório. Veja que é uma boa prática criar as pastas trunk, branches e tags. Neste caso podemos copiar nossos arquivos para dentro da trunk. Depois é só fazer o "commit" normalmente.

Este é o método que considero mais simples, mas você também pode, tendo os arquivos no servidor, usar um import para coloca-los no novo repositório.

5 - Definir o externals.

Finalmente o que interessa.

O svn:externals é uma propriedade que atribuimos a um diretório na nossa cópia de trabalho. Esta propriedade será enviada para o servidor quando fizermos o commit. Esta propriedade indica que, ao se atualizar uma cópia de trabalho, o svn deverá buscar, para colocar dentro do diretório ao qual atribuimos a propriedade, dados de um outro repositório. Então precisamos entender 3 coisas nessa configuração:

a) o diretório que tem a propriedade (diretório local)
b) o caminho do repositório
c) o nome do novo diretório que será criado (diretório externo)

Sabendo destes elementos fica fácil não cair em erros comuns que vemos pelos foruns da net.

Então, para fazer o externals do jeito mais difícil (no dos) usamos o seguinte comando:

svn propedit svn:externals . --editor-cmd edit

O ponto é o endereço do diretório local ao qual atribuimos a prop. (que pode ser trocado, é claro)

O comando --editor-cmd indica que vamos usar o edit.bat para editar as propriedades.

bom, dentro deste arquivo precisamos colocar os nomes dos diretórios externos e seus respectivos repositórios:

dir1 http://repos/plugin1/trunk
dir2 http://repos/plugin2/trunk

e depois é só salvar o arquivo normalmente. No próximo update, o svn vai buscar destes repositórios e criar as pastas dir1 e dir2, trazendo o conteúdo de plugin1 e plugin2 respectivamente.

Bom, e do jeito mais fácil ?

No tortoise, basta clicar sobre o diretório local e escolher o comando properties (dentro dos comandos do tortoise, é claro). Com isso vai aparecer uma lista das propriedades e suas configurações. Adicione a propriedade svn:externals com uma linha com "[nomedodiretorio] [urldorepositorio]" para cada externals

Atribuindo métodos a tipos do js, adicionando um método .repeat() a todas as strings.


String.prototype.repeat = function(numTimes) {
var ret = '';
for(var a = 0; a < numTimes;a++) {
ret += this;
}
return ret;
}


Usando classes do Zend Framework no Symfony

1 - incluir as classes em plugins/Zend/lib

2 - configurar o caminho no settings.yml

# Zend Framework
zend_autoload: on
zend_lib_dir: "%SF_PLUGINS_DIR%/Zend/lib"

3 - inicializar o autoload no frontendConfiguration:

/**
* @package system
* @subpackage configuration
*/
class frontendConfiguration extends sfApplicationConfiguration
{
public function configure()
{

}

public function initialize()
{
parent::initialize();
/**
* Zend Framework Autoloading
*/
if(sfConfig::get('sf_zend_autoload', true) && ($sf_zend_lib_dir = sfConfig::get('sf_zend_lib_dir'))) {
set_include_path($sf_zend_lib_dir.PATH_SEPARATOR.get_include_path());
require_once($sf_zend_lib_dir.DIRECTORY_SEPARATOR.'Zend'.DIRECTORY_SEPARATOR .'Loader.php');
spl_autoload_register(array('Zend_Loader', 'loadClass'));
}

/**
* DOMPdf Autoloading
*/
if(sfConfig::get('sf_dompdf_autoload', true) && ($sf_dompdf_lib_dir = sfConfig::get('sf_dompdf_lib_dir'))) {
set_include_path($sf_dompdf_lib_dir.PATH_SEPARATOR.get_include_path());
// require_once($sf_dompdf_lib_dir.DIRECTORY_SEPARATOR.'dompdf_config.inc.php');
// spl_autoload_register('DOMPDF_autoload');
}
}
}

Lendo um diretório com SPL

$r = new RecursiveIteratorIterator(
  new RecursiveDirectoryIterator(dirname(__FILE__)),
  RecursiveIteratorIterator::LEAVES_ONLY
);

foreach ($r as $file) {
  echo $file.'
';
}