Disponibilizo abaixo os slides da minha palestra de Behaviour-Driven Development e os projetos no github, como havia prometido.

Espero que tenham gostado!

• Slides
• Live coding RSpec
• Live coding Cucumber

• Possui agora 60 horas (20 de Ruby e 40 de Rails), ou seja, o módulo de SQL foi removido.
• As aulas serão no período da noite, em São Leopoldo.

Detalhes da formação na página Curso Rails.

NOVA AGENDA:
* Introdução a linguagem Ruby (20h)
Data: 13/07/2009 a 17/07/2009

* Ruby on Rails prático (40h)
Data: 20/07/2009 a 31/07/2009

LOCAL: Câmpus Unisinos – São Leopoldo
HORÁRIO: Noite – das 18:45 às 22:45

Primeiro ponto

Em primeiro lugar, a diferença fundamental é: RSpec é totalmente focado no teste de comportamento (Behaviour). Esse é o seu objetivo e a orientação de sua sintaxe. Ok, é possível sim fazer testes no estilo unit/test com RSpec, mas obviamente, não é a intenção ao usá-lo. É como uma implicação na lógica clássica: vou usar RSpec, logo (deveria) me focar em testar comportamento. E, numa implicação, o inverso não é necessariamente verdadeiro.

Resumindo: RSpec é focado em testar comportamento (Behaviour Driven Development). Shoulda não é focado em testar comportamento (Test Driven Development sem o “behaviour” na história), mas tem a intenção de melhorar o test/unit com helpers, macros e contextos. É um açucar sintático que torna os test/unit mais, digamos, pragmáticos e também documentados.

Dito isso, deve-se ter muito cuidado ao compará-los porque são ABORDAGENS e VISÕES diferentes, embora o objetivo de testar seja o mesmo.

Podemos comparar apenas da seguinte forma: Eu gosto mais de RSpec, ou eu gosto mais de Shoulda. Ponto. Qualquer comparação dizendo “este é melhor”, ou “este é pior” deve ser evitada e levar essa diferença fundamental em consideração: “Eu gosto de testar comportamento com o RSpec” ou “Eu prefiro testar no modelo test/unit com Shoulda” são argumentos válidos e não depreciativos entre ambos.

Segundo ponto

Agora, quando eu vejo alguém falando que faz “BDD com Shoulda”, isso me preocupa um pouco. Eu me pergunto: “Será mesmo?”. Confesso, sou um pouco purista no que tange a testar comportamento e estou sempre procurando uma melhor forma de fazê-lo. E já vi opiniões semelhantes por aí.
É possível fazer BDD com Shoulda? Sim, mas de fato não é a tendência ao usar o Shoulda. Vejamos porque.

Suponhamos a seguinte linha, retirada da documentacao do Shoulda:

class Article < ActiveRecord::Base {
  named_scope :visible, :conditions => {:visible => true}
}

E o teste para ela com Shoulda:

should_have_named_scope :visible, :conditions => {:visible => true}

Então eu pergunto: testei comportamento ou garanti que existe aquela linha de código no meu Model? Naturalmente, a segunda opção. Não que isso esteja errado, pelo contrário, seu teste tem 100% de cobertura.

Mas, e se minha lógica estiver errada? Digamos que você esqueceu que ao chamar Article.visible não deveria incluir os itens que não foram publicados ainda. Ou seja, você esqueceu uma condição que deveria fazer parte da regra. Mas você tem o teste, então (teoricamente) sua mente está livre do medo de ter errado.

É nesse ponto que entra a idéia de testar comportamento. É mais provável que você descubra esse problema se pensou anteriormente no comportamento que sua busca deveria ter. Note, eu disse que é mais provável, não é garantido que você perceberia isso imediatamente.

OK, e como eu testo o comportamento neste caso?

Estamos lidando com uma busca. Logo, vamos testar o comportamento desta busca simulando-a com exemplos (sintaxe abaixo é RSpec):

describe Article, "being displayed on the website" do
  it "should display only visible entries" do
    visible = Article.create(:name => "Art1", :visible => true, :published_at => Time.now)
    hidden = Article.create(:name => "Art2", :visible => false, :published_at => Time.now)
    visible_not_published = Article.create(:name => "Art3", :visible => true, :published_at => nil)
 
    Article.visible.should be_eql([visible])
  end
end

Nota: Num contexto real, estou usando o plugin factory_girl, da própria empresa que criou o Shoulda. É ótimo, sugiro o uso.

Simulei alguns cenários e acredito que é mais provável que eu encontre um erro no comportamento dessa forma, pois fui obrigado a formular um exemplo. Quem é acostumado a unit/test geralmente olha essa situação como um pouco de overkill: o que faria em uma linha, demorou bem mais tendo que pensar nos exemplos e na construção do teste em si.

Mas, o foco de BDD é CLAREZA nos testes e não DRY. Nem sempre um teste deve ser DRY.

É claro que é perfeitamente possível fazer isso com Shoulda e outras libs. A questão é: macros como should_have_named_scope induzem a esquecer o comportamento em benefício da simplicidade e rapidez em escrever o teste.

After all, it’s a matter of taste..

Escolher entre Shoulda e RSpec é uma questão de gosto, como eu falei no começo. Ou você gosta de focar seus testes no comportamento de um objeto, ou você prefere utilizar asserções do test/unit.

Para finalizar, volto a dizer que estamos falando aqui de BDD e TDD, e o objetivo aqui não é comparar frameworks nem gerar flames. “Shouldeiros”, não me crucifiquem por favor
E opiniões são bem vindas sobre isso tudo.

Obrigado!

Pixily, a well-funded start-up is looking for experienced Rails programmers. We provide you with excellent opportunities to learn and work with the best in the industry and build amazing products.

About Pixily:

Pixily helps professionals, home offices and small businesses aggregate, organize and find paper and digital documents. You mail-in your paper documents periodically to us in prepaid envelopes or boxes, we scan them into your online accounts and make the content searchable. You can then search, organize, share, and download documents. You can also upload documents or scan them into your account directly.

With Pixily, you save money, time, space and trees.

Get a taste for the beta by viewing this video

What you can expect:

• A great working environment
• An opportunity to work with the best
• An opportunity to learn and apply cool scalable technologies in cloud computing, Rails, Ajax, RSpec and Java
• An opportunity to be creative and make large contributions
• An opportunity to grow with the company

What we are looking for:

• Strong fundamentals (MVC, data structures, etc.,)
• Experience in at least one production Rails application
• A working knowledge of Javascript, CSS and SQL. (Expertise in Javascript and CSS would be a big plus)
• Good spoken and written communication skills in English
• Ability to work in geographically distributed teams over IM and phone
• A Smart Generalist. (Competent in both depth and breadth of technologies)

Please send your resume to careers@pixily.com, if you are interested.

Pixily is an Equal Opportunity Employer.

O Instituto de Informática Unisinos convida para o evento gratuito “Conhecendo Ruby on Rails”, onde serão abordados os seguintes tópicos:

• Conhecendo o Ruby on Rails: Princípios por trás do Rails. Por que Ruby on Rails?
• Mercado interno e externo: oportunidades
• Cases e Projetos
• Demonstração
• Entre outros tópicos

O evento é gratuito e acontecerá no dia 13/6 (sexta-feira) no Auditório do Centro Empresarial Presidente Kennedy, em Porto Alegre.
Inscrições até dia 11 de junho.

==> As vagas são limitadas!

Realização: 13/06/2008
Horário: às 18h30min
Local: Auditório do Centro Empresarial Presidente Kennedy
Avenida Carlos Gomes, 111 – Bairro Auxiliadora – Porto Alegre

INSCRIÇÕES ON-LINE

Acesse o link: http://www.ccti.unisinos.br/ccti_interna.php?corpo=acontece&codigo=253

A Pixily é um startup focado estritamente nos EUA. É um serviço online que ajuda clientes a agregar, organizar, localizar e compartilhar papéis e documentos digitais. Dessa forma:

Você coleta seus papéis e os envia por correio, é feita a conversão em arquivos PDF e os conteúdos são indexados para que seja possível buscar, compartilhar, organizar, etc.

Quero agradecer a ajuda do Fábio Espindula, que colaborou nesse processo e tem se mostrado uma pessoa fantástica. Ao Fábio Akita também, pelo auxilio nas dúvidas em relação a exportação de serviços e pelas dicas valiosas.

É isso aí, que venha o desafio!

Mais detalhes da formação.

A carga horária é de 80 horas, dividia em 3 módulos. A estrutura está adequada tanto para profissionais que já programam em outras linguagens como iniciantes. Na página acima têm todos os detalhes

Agora a logística parece ser Github + Lighthouse. O Github é muito bacana, já tem vários forks do Rails, o último que vi é um esforço para implementar características thread-safe.

Legal, vamos acompanhar o progresso da migração

UPDATE: Pois é, passei batido no feed do weblog.rubyonrails.com e não vi o anúncio oficial hehe. Não só o Rails foi para o Lighthouse, mas também o Capistrano e Prototype. Acontece

O Lucas Húngaro e o Tiago (Lecom), Ronaldo Ferraz e a Taís (Brasigo/BlogBlogs), Fábio Akita e Rodrigo (Sugerworks), Carlos Eduardo (e-Genial), Everton Carpes, Weldyss Santos, Vinícius Teles (ImproveIT), o pessoal da UDESC (Grupo Colméia), Sylvestre Mergulhão, entre outros que me fogem da memória neste instante.
Revi também os amigos, Júlio Santos Monteiro, Evandro Dutra, Pablo Targa e outros que convivem comigo na universidade, como o Joni Canal e o Eduardo Pittol.

Conheci também o Evan “Rabble” Henshaw-Plath, profissional que trabalha no Yahoo! e é responsável pelo recente Fireeagle.com, e outros sites como Odeo.com. Ele foi palestrante na RailsConf 2007 também. Chegou com irreverência no stand do Rails Brasil, questionando-nos “Onde estão os Macs?”. Extremamente gentil e simpático.

Assisti à palestra de Seaside com Randal Schwartz. Foi uma pena que ficou muito focada na linguagem, e o framework sobrou pouco tempo. Um detalhe interessante é que já nos primeiros slides ele disse acreditar que o Seaside será o próximo Rails. Ávidos e curiosos (rsrs), eu e o Júlio (que o abordou) conversamos rapidamente com ele, e resolvi perguntar o por quê desta opinião. Segundo ele, dois fatores: velocidade e debugging. A propósito, o debugging é fora do comum mesmo, pretendo olhar (novamente, mas com calma) o Seaside.

Algumas descobertas:

• A Globo.com está utilizando Rails em alguns de seus projetos, como a intranet. Estão contratando profissionais também.
• A Propus também usa Rails em alguns de seus projetos.
• O Yahoo! parece estar gradativamente entrando no Rails, agora com o Fireeagle. O Rabble nos contou mais ou menos a arquitetura deles, que está otimizada principalmente para o PHP, mas aos poucos o Rails tem entrado na jogada.

O encerramento foi magnífico, com o onipresente Jon “maddog” Hall que, com muita sabedoria e irreverência (assim como em TODOS os FISL que ele fala), levantou o público através de aplausos.

Resumindo: foi ótimo! Infelizmente minha câmera estava há alguns kilômetros daqui, mas aguardo as fotos do pessoal que estiver lendo e que, por gentileza, puder mandar para jonysk AT gmail DOT com.

As premissas, antes de tudo, eram:

1. Não usar SVN.
2. Flexibilidade para SVN e GIT como repositórios remotos.
3. Possibilidade de trabalhar em ambiente multiusuário, ou seja, vários desenvolvedores.

Deixe-me explicar a primeira premissa: Usar Subversion implicaria em merges a cada atualização dos plugins. Independente da solução que fosse usada para o merge de um plugin (piston, svnmerge, svn_load_dirs), o Subversion não trabalha bem com arquivos removidos/renomeados/movidos. Seja qual for a estratégia, o fato de fazer merge em repositórios diferentes no Subversion é um “tiro no escuro”: você nunca sabe está realmente idêntico ao repositório que você sincronizou, principalmente quando há mudanças drásticas neles (arquivos removidos/renomeados/movidos), e vai deixando seu rastro de desorganização com o tempo. No site do Piston eles também comentam sobre isso.

Passei horas e horas pesquisando e rascunhando no papel estratégias com repositório central. A solução que mais se aproximou àquela que eu gostaria foi esta aqui, que trabalha com git-submodule.
Fantástica por sinal! Adorei o git-submodule. Como o GIT não permite fazer clones parciais, apenas de repositórios inteiros, achei que fosse a solução. Fiz vários testes, e quando eu havia compreendido muito bem o seu funcionamento, percebi que o git-submodule era muito peculiar para trabalhar com alterações, e certamente causaria confusões na equipe.
Mas essa solução é muito bacana. Se o objetivo for centralizar um repositório de plugins, essa solução pode muito bem ser avaliada.

Mas ela já mata a primeira e a segunda premissa: tem em sua base um servidor Subversion. Ao passo que alguns plugins vêm sendo gerenciados por GIT, já começariamos aqui a ter que colocar repositórios GIT no Subversion! Um retrocesso à nossa meta, na minha opinião

Enfim, o braid!

Até que encontrei o braid (O Fábio Akita já havia comentado sobre ele no Rails Podcast Brasil). O braid é uma ferramenta simples pra gerenciar vendor branches (no nosso caso, plugins do Rails) de repositórios diferentes. Mais ou menos um Piston para GIT.

Resumindo o funcionamento do braid: ele faz uma branch chamada braid/track e nela adiciona clones (git-svn init) para os seus plugins, e ainda faz o merge nesta branch. Quando julgar necessário, você faz merge com sua branch principal.

Experimentando

Para instalar o braid, faça:

1
2
3
4

$ git clone git://github.com/evilchelu/braid.git
$ cd braid
$ sudo gem install main open4
$ sudo ruby setup.rb

Com o braid instalado, inicie um projeto apenas para teste:

1
2
3
4
5
6
7
8

$ mkdir testing
$ cd testing
$ git init
$ echo "test" > file
$ git add file && git commit -m "import inicial"
 
# Jabá brazuca como exemplo: adicionar o plugin feito pelo Carlos Brando
$ braid add  http://plugins.nomedojogo.com/custom_resource_name --type svn vendor/plugins/custom_resource_name

Isto cria a seguinte estrutura:

1
2
3
4

$ git branch -a
  braid/track
* master
  braid/svn/vendor/plugins/custom-resource-name

Quando houver modificação no plugin, basta fazer:

1
2

$ braid update  # atualiza o plugin
$ git merge braid/track # merge com sua branch principal (master)

Bacana, mas e a equipe?

Num cenário real (como o que motivou essa estratégia), o repositório está num servidor central que os outros desenvolvedores fazem seus clones. Mas nesse repositório não ficarão os dados da branch recém criada. Então, como os desenvolvedores atualizarão os plugins?

Uma maneira é passar aos demais desenvolvedores os repositórios remotos para que eles adicionem manualmente no .git/config dos seus clones.

1
2
3
4
5
6
7
8
9
10
11

$ cat .git/config 
[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
 
# esta parte aqui e mais eventuais outros plugins instalados:
[svn-remote "braid/svn/vendor/plugins/custom-resource-name"]
        url = http://plugins.nomedojogo.com/custom_resource_name
        fetch = :refs/remotes/braid/svn/vendor/plugins/custom-resource-name

Sim, isto funciona. Depois basta fazer um braid update.

Mas não é uma forma muito interessante. Ótimo seria explorar o arquivo que o braid cria automaticamente, chamado .braids, que mantém os dados dos vendor branches adicionados:

1
2
3
4
5
6
7

$ cat .braids 
--- 
vendor/plugins/custom_resource_name: 
  local_branch: braid/svn/vendor/plugins/custom-resource-name
  type: svn
  branch: master
  remote: http://plugins.nomedojogo.com/custom_resource_name

Uma maneira seria modificar o braid e adicionar a funcionalidade de ler este arquivo e adicioná-lo com comandos do GIT. O criador do braid já havia comentado que isso seria feito. Como ainda não foi feito e eu queria testar essa solução, criei um patch e enviei a ele.

Com este patch, um desenvolvedor pode fazer um clone do repositório e, em seguida, executar git rebuild, que reconstruiria a branch e os links remotos a partir do arquivo .braids.
Em breve será feito algo semelhante no braid, seja a partir deste patch ou um novo

É isso!
Vale lembrar que o braid ainda está amadurecendo. O gem, por exemplo, ainda nem foi publicado.
Se você tiver alguma outra idéia ou modelo, fique à vontade em comentar

Capistrano é uma ferramenta que, a grosso modo, permite realizar tarefas remotas de todos os tipos. Uma das aplicações comuns é no processo de deployment do Rails que é, de longe, facilitado pelo Capistrano

mongrel_cluster é, em suma, um Gem que agrupa um cluster de servidores de aplicação Mongrel, simplificando a tarefa de gerenciá-los.

Remote cache é uma estratégia de deployment do Capistrano que executa uma tarefa interessante: ela faz um clone do repositório GIT (ou um checkout, se for Subversion) e atualiza a aplicação apenas com um rsync, ou seja, copia apenas os arquivos modificados para a release atual.

Dentre as estratégias existentes de deployment do Capistrano, prefiro utilizar o remote_cache. Porém, quando em conjunto com mongrel_cluster, existe a necessidade de que o arquivo de configuração do mongrel_cluster (config/mongrel_cluster.yml) exista para que os processos Mongrel possam ser levantados e o deploy tenha sucesso.

Uma saída seria adicionar o arquivo config/mongrel_cluster.yml ao repositório. Entretanto, perderíamos a flexibilidade de centralizar nosso deploy no deploy.rb (arquivo principal do Capistrano na aplicação). Qualquer modificação exigiria, em seguida, executar mongrel:cluster:configure e comitar para o repositório.
Uma saída simples que montei para manter a flexibilidade de fazer o deploy usando mongrel_cluster e as configurações foi:

require 'mongrel_cluster/recipes'
 
# outras configurações omitidas...
 
set :deploy_via, :remote_cache
set :mongrel_conf, "#{current_path}/config/mongrel_cluster.yml"
 
# outras configurações omitidas...
 
before "deploy:start", "mongrel:cluster:configure"
before "deploy:restart", "mongrel:cluster:configure"

Com as duas últimas linhas acontece o seguinte: quando um cap deploy ou cap deploy:cold é executado, a configuração do mongrel_cluster é gerada no servidor, a partir das configurações do seu deploy.rb.

Simples, quem sabe seja útil no seu próximo deploy.

Sem mais, acho que dessa vez achei um tema bem agradável. Nada mais de bordas quadradas!

Como o nome sugere, é uma formação bastante abrangente que envolve não apenas o desenvolvimento de aplicações com Ruby on Rails, mas também módulos de HTML/Webstandards e SQL, provendo uma base necessária para construir aplicações web completas.

A carga horária em Ruby e Rails é forte. Serão 60 horas no total (20-Ruby, 40-Rails) onde propõe-se uma formação consistente em tópicos não só básicos, mas também deployment, RESTful, etc, assim como o desenvolvimento de uma aplicação com contexto real e útil.

Cabe um comentário pessoal aqui: Estou bastante satisfeito em pensar que esta é mais uma iniciativa visando a divulgação do Ruby on Rails no Brasil. Espero contribuir ampliando a rede de desenvolvedores e boas aplicações saindo do Brasil. Ah, e nos veremos também no FISL, nos stand do Rails Brasil!

INFORMAÇÕES E INSCRIÇÕES:

Telefone e fax: (51) 3328-2221
Proposta on-line: http://www.ccti.unisinos.br/ccti_interna.php?corpo=faleconosco

DETALHES DA FORMAÇÃO:

Objetivo:
Capacitar os profissionais a desenvolver aplicações Web utilizando os recursos do framework Rails e da linguagem Ruby, seguindo os princípios e práticas que norteiam o modelo de desenvolvimento ágil.

Público-Alvo:
Desenvolvedores PHP, Java, .NET e/ou outras linguagens; Programadores com pouca ou bastante experiência.

Pré-requisitos:
Conhecimentos em ambiente Windows ou Linux; Noções básicas de programação; Desejável conhecimento em Orientação a Objetos.

Realização da formação: De 29/03 à 05/07
Local: Câmpus Unisinos – São Leopoldo
Horário > Sábado 08:30 até 12:30 e das 13:30 até 16:00

CONTEÚDO PROGRAMÁTICO:

HTML e WebStandards – 20 horas -> apresenta a linguagem HTML e os últimos padrões de desenvolvimento de páginas para Web, incluindo os Web Standards, a linguagem XHTML, e o desenvolvimento de páginas utilizando CSS e Tableless Design.
Realização: 29/03/2008 – 12/04/2008 – São Leopoldo

Linguagem SQL Padrão ANSI – 20 horas
Realização: 19/04/2008 – 03/05/2008 – São Leopoldo

Introdução à linguagem Ruby – 20 horas -> Compreender a linguagem Ruby e a aplicabilidade de suas principais funcionalidades para otimizar a construção de algorítimos.
Realização: 10/05/2008 – 24/05/2008 – São Leopoldo

Ruby on Rails prático – 40 horas -> Capacitar o aluno a desenvolver aplicações web com o framework Rails utilizando seus principais recursos, melhores práticas e técnicas de desenvolvimento, voltadas a projetos e cenários reais.
Realização: 31/05/2008 – 05/07/2008 – São Leopoldo

Veja a página da extensão.

Agora, PHP é oficialmente suportado pela Microsoft em seus servidores IIS. Em suma, PHP para Windows (2003) está finalmente com suporte estável. Mais uma justificativa para argumentar caso surja um “.NET” no meio da conversa com os clientes que utilizam Windows como servidor, ou aquele temeroso papo de performance do PHP no Windows

Mais detalhes no site do Andi Gutmans ou em vários outros no Planet PHP.

19/10 – 13h às 16h
Minicurso: Introdução ao Ruby on Rails
Ministrante: Jony dos Santos Kostetzer
Local: Sala 6L 118
Objetivo: Conhecer alguns conceitos, recursos e práticas no desenvolvimento de aplicações em ambiente web utilizando a linguagem Ruby e o framework Rails.
Conteúdo: Introdução à linguagem Ruby; Instalaçao em amb. Windows e Linux; IRB; Modelo MVC; Introdução ao Rails; Primeiros passos; Relacionamentos; Ajax; IDEs; Atualidade e futuro do RoR.

Quem é estudante da Unisinos ou reside na região e gostaria de conhecer um pouco a linguagem Ruby e o framewok Rails, fica o meu convite

Importante:

• É necessário fazer a inscrição no evento através do site
• É solicitado aos inscritos que informem ao coordenador do evento (pelo e-mail cazella@unisinos.br) se desejarem realizar o minicurso: NOME COMPLETO, E-MAIL e NOME DO MINICURSO (Introdução ao Ruby on Rails). Este controle torna-se necessário devido ao número de vagas disponíveis ser limitado para minicursos.

Conto com a presença de vocês!

UPDATE: Muito obrigado pela presença de todos! Foi um ótimo encontro

Aqui estão os slides conforme prometido: Introdução ao Ruby on Rails

Até a próxima!

CREATE TABLE "estado"
(
"id" NUMBER  NOT NULL,
"nome" VARCHAR2(50),
"sigla" VARCHAR2(2)
);

MySQL e PostgreSQL não apresentaram problemas. Porém, a inserção deste SQL no Oracle força que todas as tabelas e campos sejam criados na forma de caracteres minúsculos.

Ou seja, se você fizer uma consulta diretamente no banco¹ da seguinte forma:

SELECT nome FROM estado;

Receberá um erro informando que a tabela não existe! Apenas nesta forma funcionaria:

SELECT "nome" FROM "estado";

Conseqüentemente, todas as consultas efetuadas através dos objetos de mapeamento do banco geradas pelo Propel não funcionarão. A solução foi simples: remover as aspas duplas do arquivo SQL gerado (utilizei a ferramente rpl do linux):

rpl '"' '' data/sql/*

Uma solução não muito adequada, mas resolveu. Até que resolvi consultar a lista symfony-users sobre o problema e um integrante, Charley Tiggs, sugeriu a seguinte configuração no propel.ini:

propel.disableIdentifierQuoting = true

Simples e funcional. Fica a referência para consultas futuras

¹ Sugiro o Oracle SQL Developer, uma ótima ferramenta GUI desenvolvida em Java para acessar bancos em Oracle, MySQL e SQL Server. Sendo uma ferramenta Java, pode ser executada perfeitamente no Linux, como estou utilizando aqui!

Por exemplo:

project:
id:
title: varchar(255)
sf_guard_user_id:

O código acima resultará no seguinte erro:

“Unable to resolve foreign table for column “sf_guard_user_id”"

Pesquisando sobre o assunto, uma sugestão seria alterar o namespace onde são gerados os arquivos de ORM do Propel. Particularmente, não achei interessante. Na lista symfony-users, uma referência diz que essa é uma limitação do Propel.

A verdade é que a “solução” é extremamente simples:

project:
id:
title: varchar(255)
user_id: { type: integer, foreignTable: sf_guard_user, foreignReference: id, required: true, onDelete: cascade }


Supondo um endereço de intranet, o WSDL deste webservice estaria disponível na URL:

• http://intranet/sugarcrm/soap.php?wsdl

Este how-to abrange a integração do SugarCRM com o Symfony. Neste cenário, uma aplicação deve manter os mesmos registros de contas (Accounts) que existem no SugarCRM. Vamos apenas gerar um array onde a chave será o ID da conta e o valor será o nome da conta.

Uma curiosa surpresa ao iniciar a integração foi descobrir que havia um plugin para o Symfony chamado sfSugarCRM, constituído de duas classes:

• sfSugarCRMSOAPClient: Classe com um método no padrão Singleton que retorna a instância de SoapClient conectada ao WSDL do SugarCRM.
• sfSugarCRM: Classe que abstrai algumas requisições ao Webservice do SugarCRM.

Importante: este plugin não utiliza NuSOAP, mas sim as bibliotecas SOAP distribuídas nas versões do PHP5 e posteriores. Certifique-se que a extensão SOAP está instalada.

Inicialmente, seguindo a breve documentação de exemplo do sfSugarCRM, vamos instalar o plugin:

./symfony plugin-install http://plugins.symfony-project.com/sfSugarCRMPlugin
./symfony cc

Pulemos os passos de criação da aplicação e do módulo no Symfony, o código abaixo conecta ao Webservice:

$sugar = new sfSugarCRM("http://intranet/sugarcrm/soap.php?wsdl");
$sugar->setUsername("usuario");
$sugar->setPassword("senha");

O trecho acima armazena o usuário e a senha em variáveis de instância, e as utiliza para a chamada de alguns métodos do servidor SOAP, que são:

• Localizar contatos pelo nome: searchContactsByName()
• Localizar contatos pelo e-mail: searchContactsByEmail()
• Retornar lista de usuários: getUserList()
• Métodos para criação de registros: createLead(), createContact(), createAccount(), createOpportunity(), createCase()

Um detalhe a importante é que os métodos acima enviam usuário e senha a cada requisição ao Webservice. Alguns métodos do Webservice, entretando, exigem como parâmetro o ID do login, uma string gerada com a chamada ao método login() do Webservice. Como a classe sfSugarCRM não implementa nenhum método para isso, abaixo um patch que cria essa função:

• Patch sfSugarCRM

Para aplicar o patch, entre na raiz do projeto e digite:

patch -p0 < patch.txt

Após aplicado o patch, você tem os novos métodos na classe sfSugarCRM: getLoginId() e doLogin() , que facilitam a chamada para diversos métodos do Webservice. Dessa forma, é só criar novos métodos na classe sfSugarCRM! Criei um método chamado getEntryList() (que utiliza o método get_entry_list() do webservice), veja como retornar todos os clientes:

$params = array(
  "module_name" => "Accounts",
  "order_by" => "name ASC",
  "offset" => 0,
  "select_fields" => array("name"),
  "max_results" => 1000
);
$sugar->getEntryList($params);
$response = $sugar->getResponse();
$contas = array();
foreach ($response->entry_list as $entry) {
    $contas[$entry->id] = $entry->name_value_list[0]->value;
}
print_r($contas);

Então é isso! Este material não será de uso constante, mas fica como referência quando um cenário semelhante surgir

Referências:

• SugarCRM SOAP Overview (.rtf)
• PHP Soap Extension
• Symfony plugins: sfSugarCRM
• Soap Intro and pratical examples

Ok, sem mais para o primeiro post, mesmo porque ninguém o lê por completo se for extenso.