Mãe!!! Prometo a partir de hoje não xingar mais o symfony, me conformar e parar de reclamar.
Já me conformei que ele é ruim, pesado, pouco prático e burocrático. É mãe isso não é pra mim, acho que o meu caminho é outro, afinal de contas existe tantas coisas lindas nesse imenso mundo.
É mãe para que eu vou insistir em algo ruim se a vida é tão breve.
Diariamente eu trabalho com o framework symfony 1.1 usando como ORM o Doctrine, mas são muitas as decepções com o Doctrine. Ele não é um ORM que propícia um desenvolvimento ágil.
Hoje eu precisei fazer uma consulta retornando todos os registros da tabela e ordenando pelo nome, tentei usar o método findAll do Doctrine, mas ele não permite informar uma coluna para ordenação, ou seja, o básico do básico ele não faz muito bem. Onde fica o desenvolvimento ágil em tudo isso? :-( Precisei fazer uma gambiarra usando o método findByDql para conseguir realizar a minha consulta.
Eu pretendia fazer algo do tipo:
1 2 3 4 5 6 7 8 9 | $states = Doctrine::getTable('DState')->findAll()->orderBy('short'); ou $states = Doctrine::getTable('DState')->orderBy('short')->findAll(); ou $states = Doctrine::getTable('DState')->findAll(array('order' => 'short')); |
Nada disso funciona, o método findAll não consegue trabalhar com ordenação. Não vejo vantagens em usar esse método se não posso trabalhar com a ordenação dos resultados.
Tive que fazer a seguinte gambiarra usando o método findByDql para conseguir executar a consulta de forma mais prática e ágil:
1 | $states = Doctrine::getTable('DState')->findByDql('id is not null order by short'); |
Eu precisei criar um where que funciona para tudo e depois especificar a ordenação.
Eu trabalho com o framework PHP symfony, mas faço frees em Ruby on Rails. A diferença de tecnologia é imensa, ainda mais quando se leva em conta a produtividade, padronização e resultados.
O PHP ainda tem uma longa evolução a ser feita, a sua orientação a objetos tem vários problemas de design, e nem todos os padrões foram implementados ainda. O framework symfony por usa vez está em um momento de definição de padrão, existe muitos bugs sérios e algumas tecnologias empregadas em sua estrutura agregam burocracia demais para um framework focado em desenvolvimento ágil.
Eu ficou com o Ruby on Rails, estudo a fundo a sua estrutura e até agora só fiquei feliz com tudo que vi.
Se você gostou desse texto e acha que ajudou você, me recomende: 
.
Esses tempos estava usando o object_select_tag (é uma mão na roda), mas precisava trazer os resultados em ordem crescente. Foi ae que eu descobri que existe uma opção peer_method onde é possível definir o método no model para retornar a lista de resultados.
Eu não curto o Propel, prefiro bem mais o Doctrine. Desta forma esse exemplo é baseado usando o Doctrine:
No template:
1 2 3 4 5 6 7 | <?php echo object_select_tag(isset($filters['Status']) ? $filters['Status'] : null, null, array ( 'include_blank' => true, 'related_class' => 'Status', 'text_method' => '__toString', 'control_name' => 'filters[Status]', 'peer_method' => 'getSorted' )) ?> |
No model StatusTable.class.php:
1 2 3 4 5 6 7 | public static function getSorted() { $q = new Doctrine_Query(); $q->from('Status')->orderBy('name ASC'); return $q->execute(); } |
No código acima que é possível definir a forma de ordenação e qual coluna que deve ser usada para ordenar.
Agora falta criar o método __toString no model Status.class.php:
1 2 3 4 | public function __toString() { return $this->name; } |
O método __toString e usado para imprimir os valores no combo box.
Pronto! ;-)
Pessoal,
Eu e o Nei nesse final de semanas participamos do Yahoo! Hack Day e construímos essa aplicação: http://www.patrickespake.com/hacktrip/web/ busque por cidades internacionais.
O objetivo da nossa aplicação era buscar informações sobre uma determinada cidade, mostrando informações sobre hotéis, notícias, restaurantes, dúvidas, trips, fotos e mapa.
Para construir o projeto nós usamos o symfony, svn (unfuddle.com), Prototype, Scriptaculous e algumas Api’s do Yahoo descritas abaixo:
1. Para Hotéis nós usamos a api: Yahoo local (http://developer.yahoo.com/local/) essa api é meio estranha não funciona muito legal, os parâmetros de configuração na documentação não funcionam como o esperado e as vezes trazem uns destinos malucos, funciona +- para destinos internacionais;
2. Para Restaurantes usamos a api: Yahoo local mesmo problema descrito acima;
3. Para Notícias usamos a api: BOSS (http://developer.yahoo.com/search/boss/), essa api foi mais tranquila de usar e a documentação está funcionando legal para ela, ela server para fazer buscar dos resultados do mecanismo de busca do Yahoo para uma determina string, fotos e notícias;
4. Para Trips usamos a api: Travel (http://developer.yahoo.com/travel/) essa api é bem enrolada, ela disse que trás uma porção de coisas e na verdade só traz trips marcadas pelas pessoas;
5. Para Fotos usamos a api: Flickr (http://developer.yahoo.com/flickr/) essa api permite puxar fotos uma determinada tag e conjuntos de tags ficou um recurso interessante para puxar fotos de uma determinada cidade, mas ela é meio enrolada na parte que informa onde essa api pode ou não pode ser usada;
6. Para Mapa usamos a api: Google Maps, nós tentamos usar a api de mapas do Yahoo, mas ela é muito ruim e o mapa é feio para caramba, se contar que a gente mandava setar os marcadores no mapa e algumas vezes ele se perdia, nós construímos dois mapas um com o Yahoo e outro com o Google e mandamos setar os marcadadores o do Yahoo alguns marcadores ficaram errados. Essa api de mapa deles é meio bichada.
Uma coisa legal que a gente fez foi implementar a api do geonames.org, essa api permite buscar cidades no mundo inteiro, nós usamos ela para fazer o autocomplete do campo de busca, você digita o nome da cidade e ele começa a buscar as informações de geo desse destino.
A minha conclusão sobre as Api’s do Yahoo! são as seguintes:
Elas são ruins, não são muito boas, falta documentação de qualidade e muitas vezes elas tem um comportamento estranho. As únicas api’s que parecem ser melhores são as do Yahoo! Respostas, Delicious e Flickr, as demais são meio problemáticas. O mais interessante é que a gente conversou com várias pessoas do Yahoo! sobre essas deficiências e eles nós aconselhavam a usar as api’s do Google ou de outros, é molé. Eu esperava que eles falassem que as api’s deles tem problemas e estão trabalhando para melhorar, mas na verdade não.
Bom na verdade eu esperava mais em termos de tecnologia legal deles, e fiquei meio desencatado para usar essas Api’s. Muitas só permitem sugar informações e não permitem interação.
O Nei perguntou sobre as Api’s Local e Travel e os caras nem sabiam que existiam, teve que aparecer um dev gringo para testar e descobrir algumas informações para a gente.
No geral os outros devs do evento também tiveram a mesma sensação que a nossa, essas críticas eram os comentários gerais do evento e até nas apresentações dos projetos o pessoal aproveitou para criticar esses problemas.
Eu acredito que o evento acabou tendo um efeito contrário, ao invés do pessoal querer usar as api’s do Yahoo eles agoram sabem todos esses problemas e perderam o interesse.
Para quem tiver interesse pode baixar o projeto: http://www.patrickespake.com/hacktrip.tar.gz
Abraço.
