Pq não usar nome de models e controllers em pt-br?
Davis Cabral - Listas
Alguem poderia me dizer pq não usar?
Ontem tive uns problemas com "combustivel" => "combustiveis" e "cor" =>
"cores".
Gosto de modelar os processos, bancos e actions em pt-br.
Vou ter que me adequar?
abraços!
ps.: já rolou esse papo aqui ou em outras listas, mas eu sinceramente
não gosto de ter que usar inglês, sem xenofobia alguma.
ps2.: se puderem, junto com as opinioes, mandar uma solucao par meu
problema de inflecções, eu agradeço muito.
--
Davis <davis...@gmail.com>
Impact Media
--
C: +55 45 9928 0815
B: http://blog.impactmedia.com.br/
Rafael Henrique
Rafael.
Gustavo Amigo
eu já participei de projetos onde tudo era escrito em português. Os
invés de findAll, buscarTudo, ou findBy..., buscarPor. E por aí vai.
Eu gostei, achei que dá mais produtividade trabalhar dessa forma aqui
no Brasil. Não é todo mundo conhece inglês bem e nessa situação
vc acaba vendo uns erros no inglês bem feios. Se não é um projeto
open source, onde não há a menor possibilidade desse projeto parar
na mão de um gringo, acho que vale a pena programar em português.
Quanto a pluralização, eu acho que é um trabalho a toa pluralizar em
português, é mais fácil desabilitar essa feature que pouco ou nada a
acrescenta ao Rails.
[]´s
Gustavo Amigo
Davis Cabral - Listas escreveu:
Davis Cabral - Listas
> Quanto a pluralização, eu acho que é um trabalho a toa pluralizar em
> português, é mais fácil desabilitar essa feature que pouco ou nada a
> acrescenta ao Rails.
>
Comecei um pequeno projeto para pegar o jeito, mas já estou pensando em
outro open source.
Até o fim do ano que vem, o produto open source deve ser lançado na
comunidade.
De preferência em algum evento do meio.
Gustavo Amigo
Davis Cabral - Listas escreveu:
> Gustavo Amigo wrote:
> > Quanto a pluralização, eu acho que é um trabalho a toa pluralizar em
> > português, é mais fácil desabilitar essa feature que pouco ou nada a
> > acrescenta ao Rails.
> >
> Mas com isso, eu tenho que definir tudo manualmente?
Acredito que não, não lembro de cor agora, mas dá para desabilitar a
pluralização sim. Essa é uma feature meio controversa, nem todos
gostam dela. Muitos preferem desabilita-la.
Rafael MVC
Inflector.inflections do |inflect|
inflect.plural /ao$/i, 'oes'
inflect.singular /oes$/i, 'ao'
inflect.plural /l$/i, 'is'
inflect.singular /is$/i, 'l'
end
Logico que existem muito mais, mas é essas duas atendem bastantes casos.
Marlon José
inflect.singular /ores$/i, 'or'
Davis Cabral - Listas
> Entrando no assunto
> entao se eu adicionar
>
> inflect.plural /or$/i, 'ores'
> inflect.singular /ores$/i, 'or'
>
> ele vai entender que o plural de cor é cores e o singular de cores é cor?
Exato. Peguei isso ae e usei aqui e funcionou lindamente!
Abraço!
> ----- Original Message -----
> *From:* Rafael MVC <mailto:raf...@gmail.com>
>
> Inflector.inflections do |inflect|
> inflect.plural /ao$/i, 'oes'
> inflect.singular /oes$/i, 'ao'
> inflect.plural /l$/i, 'is'
> inflect.singular /is$/i, 'l'
> end
>
Valeu rafael! :)
Resolveu meu problema e a discussao ja abriu minha cabeça pra um futuro
proximo! :)
Marcos Tapajos
um bug em relacionamento n para n !!!!!)
Tem como você manter a pluralização ativa e definir como serão os
plurais que não são apenas um 's' no final. Você pode fazer seu sistema
de plurais.
Um abraço
Pedro Mariano Belo
coisa (terminados em s, em geral) Para os outros basta configurar o
inflector ou usar esse plugin (mas eu nunca o vi).
On 11/29/06, Gustavo Amigo <gustav...@gmail.com> wrote:
>
>
Davis Cabral - Listas
> Po eu não vejo motivos, mesmo com nomes em português ela acerta alguma
> coisa (terminados em s, em geral) Para os outros basta configurar o
> inflector ou usar esse plugin (mas eu nunca o vi).
Inflector.inflections do |inflect|
inflect.plural /ao$/i, 'oes'
inflect.singular /oes$/i, 'ao'
inflect.plural /l$/i, 'is'
inflect.singular /is$/i, 'l'
inflect.plural /or$/i, 'ores'
inflect.singular /ores$/i, 'or'
end
Valeu ae galera!
Obrigado!
Ontem eu tentei colocando irregular, nem me toquei na sutileza do plural
-> singular!
Agora entendi o esquema! :)
Gustavo Romero
cultura local, evita a colonização e tem outras vantagens, ... como
poder usar "Novo" que nunca me deu erro de "reserved word" :)
Agora que programo em ruby estou encurtando os nomes, mas no velho
Delphi e C# ya escrevi ExtensasDefinicoesDaVariavelOuFuncao()
@evolucao
Gustavo Romero.
... Gustavo Amigo escreveu:
Nando Vieira
@evolucao? Não... prefiro @evolution....
Se eu quiser manter a cultura local, faço um livro de poesias. ;)
Mas gosto é gosto, e por isso, cada um tem seu editor! ;)
Davis Cabral - Listas
Pode ser inglês ou português, mas tem que ser bem feito! ;)
Rafael MVC
Davis Cabral - Listas
> Eu acho util usar o codigo feito em pt-br e usar o codigo do framework
> em inglês. Eu utilizo a lingua para facilitar a diferenciação do que
> foi feito pela empresa e o que foi feito pelo framework. Outra coisa,
> se você começa a fazer uma tradução total, igual ao buscarPorEmail ou
> buscarTodos, os novos desenvolvedores levarão um baita choque ao
> entrar na sua empresa.
Não mecho no codigo do framework pra nao ter retrabalho.
Gosto do que eu faço em pt-br.
Mas por diversas vezes tive que fazer em ingles, principalmente quando o
trampo é pra fora.
Juraci Krohling Costa
exatamente o motivo para fazer o código em inglês... Veja este
exemplo:
Person.find_all_by_first_name_and_last_name(first_name, last_name)
Este método é respondido pelo Rails (finders automáticos), mas quem
"consome" não precisa saber isso. Inclusive, é perfeitamente possível
ter a implementação deste método, caso queira ordenar por alguma
coluna. Então, fazer a diferenciação entre o que é framework e o que é
"da empresa" nem sempre é um bom negócio :-)
- Juca.
2006/11/30, Rafael MVC <raf...@gmail.com>:
--
juraci krohling costa
http://jkcosta.info
Davis Cabral - Listas
> Eu ia falar que a diferenciação entre o framework e a aplicação é
> exatamente o motivo para fazer o código em inglês... Veja este
> exemplo:
>
> Person.find_all_by_first_name_and_last_name(first_name, last_name)
>
> Este método é respondido pelo Rails (finders automáticos), mas quem
> "consome" não precisa saber isso. Inclusive, é perfeitamente possível
> ter a implementação deste método, caso queira ordenar por alguma
> coluna. Então, fazer a diferenciação entre o que é framework e o que é
> "da empresa" nem sempre é um bom negócio :-)
>
> - Juca.
Vou dar uma parada no desenv. e projetar melhor. É um caso a se pensar
esse dae.
Realmente bacana, mas da mesma forma que "confunde" quem consome, se não
tiver uma boa documentação, pode confundir quem desenvolve junto também né?
Juraci Krohling Costa
certamente retorna a lista de pessoas, com base no nome e sobrenome.
Se ele retornasse uma lista de discos, aí sim precisaria de
documentação :-) Quem bate o olho, sabe o que o método faz. Pode não
saber *como* faz, mas faz. E qualquer problema, abre-se o model em
questão e reimplementa-se método ou altera-se (caso já esteja
implementado).
- Juca.
2006/11/30, Davis Cabral - Listas <daviscabr...@gmail.com>:
Davis Cabral - Listas
> Na verdade, não deveria confundir... Um método com este nome
> certamente retorna a lista de pessoas, com base no nome e sobrenome.
> Se ele retornasse uma lista de discos, aí sim precisaria de
> documentação :-) Quem bate o olho, sabe o que o método faz. Pode não
> saber *como* faz, mas faz. E qualquer problema, abre-se o model em
> questão e reimplementa-se método ou altera-se (caso já esteja
> implementado).
A respeito do que é do framework e o que é da aplicação.
Programador teu acabar chamando método onde não existe e talls...
Mas é questão de adequação tb...
Dpz que um padrão é estabelecido, esse tipo de coisa não acontece né...
O nome em si, é deveras elucidativo. :-)
Renato Suelotto
Valeu!
--
Renato Suelotto
Gustavo Amigo
cá pra nois, essa é uma feature pouco interessante do Rails. Uma
classes precisa ter os seus métodos bem definidos, este principio
básico de programação orientada a objetos, ter sua interface bem
definida. Na medida em que o ActiveRecord permite vc montar métodos
que mimicam queries de banco de forma dinâmica e isto está
disponível publicamente, ele quebra com essa premissa. Pior de tudo
que seria fácil ele não quebrar com a premissa, bastaria
disponibilizar esses métodos como protegido. Parece que há um plano
para que o Rails 2.0 tenha todos esses métodos protegidos para com
isto induzir uma boa prática e para que as Classes que herdam o
ActiveRecord tenham sua interface bem definida. Do contrário vamos
continuar com o anti-pattern Controller Gordo Model Magro.
[]´s
Gustavo Amigo
Juraci Krohling Costa escreveu:
Juca
"cá pra nois, essa é uma feature pouco interessante do Rails."
Não consideraria isso pouco interessante não :-) Eu acho que é uma
das coisas mais *bonitas* do Rails, apesar de usar pouco. Isso usa duas
features muito interessantes do Ruby (passagem de mensagens ao inves de
"chamada de metodos" e "method missing catcher"). Isso sim é OOP =D
"Uma classes precisa ter os seus métodos bem definidos, este principio
básico de programação orientada a objetos, ter sua interface bem
definida."
Bom, o que vc entende por métodos bem definidos? O que temos em Ruby
são "receptores de mensagens" (aka métodos). Nessa condição, todos
os métodos estão tecnicamente bem definidos, já que o método que
vai responder ao finder dinâmico se chama "method_missing" e está bem
definido na classe AR::Base :-) Veja, esquecendo um pouco a
formalidade, você não acha que qualquer um entenderia que, se o
método não existe no model, ele é tratado pelo framework? Então, a
mesma pessoa entenderia que se ela sobrescrever o método, ele vai
funcionar da forma que ela quer, certo? Então, qual o problema em não
estar "formalmente definido" no model? :-) Para alguém que não
entende de Ruby e de Rails, isso pode realmente significar um bom tempo
para "descobrir". Mas se alguém não estudou Ruby ou Rails antes de
começar a trabalhar, então merece perder este tempo :-) (repare que
já disse em outras mensagens que tenho medo da "massificação" do
Rails, e este é o principal motivo).
"Pior de tudo que seria fácil ele não quebrar com a premissa,
bastaria disponibilizar esses métodos como protegido."
Estes métodos não *existem* formalmente. O Rails não monta todas as
combinações possíveis de finders dinâmicos :-) Se eles não
existem, não tem como deixá-los como protegido. A não ser que
faça-se a mesma coisa no method_missing, mas aí, que vantagem Maria
leva?
"que há um plano para que o Rails 2.0 tenha todos esses métodos
protegidos para com isto induzir uma boa prática e para que as Classes
que herdam o ActiveRecord tenham sua interface bem definida. "
Faz algum tempo que não vejo os blogs por aí, mas isso aí me parece
uma especulação das grandes. Primeiro, pelo motivo que falei acima.
Estes finders dinâmicos *não existem*. Segundo, porquê isso
certamente seria algo contra o DRY. Ter dois métodos (um protegido e
um público) só para que você tenha um finder dinâmico não é das
melhores idéias...
"Do contrário vamos continuar com o anti-pattern Controller Gordo
Model Magro"
Veja que *essa* feature em específico não contribui para este
anti-pattern :-) O finder *está* no model. A diferença é se ele vai
ser respondido pelo framework ou pelo model em si.
- Juca.
Juca
Então, eu prefiro fazer em inglês pq semanticamente faz mais
sentido... Ex.: redirect_to :action=>"index" ao invés de redirect_to
:action=>"indice" . Ou ainda @pedido.save . "@pedido.save" não
significa nada, se for pensar bem. É uma frase (comando) metade em uma
lingua, metade em outra. É como se você fosse ao McDonalds e pedisse
"Can you please me dar uma batata frita?". Até funciona, mas fica
estranho pra caramba :-)
Então, em geral, prefiro em inglês. Mas claro, quem não sabe inglês
*deve* programar em português. Não é só pq alguém não sabe
inglês que não vai programar, né? :-)
- Juca.
Gustavo Amigo
o meu problema não é com a forma dinâmica em que o Ruby trabalha,
mas sim com essa coisa de que eu posso ir lá e chamar o find_by_(query
substituindo espaço por virgula) e isso funciona. Isso não podo ser
uma interface pública de uma classe, é permissivo demais. Olha de
outra forma, se vc olha a implementação de um activerecord, algo
assim
class Pessoa < ActiveRecord::Base
belongs_to :grupo
end
A olha no código controller e vê isso sendo usado assim
Pessoa.find_all_by_age_and_eye_color...
Puxa vida, se não foi a mesma pessoa que implementou, isso cai como
uma surpresa. Não, não é assim que eu aprendi programação
orientada a objeto. O principio básico é, o contrato entre os objetos
deve ser algo claro e bem definido. Na medida em que o contrato pode
ser moldado por magicas dinâmicas, esse principio é quebrado. Não
concordo com a feature e acho que ela leva a uma má prática.
Duas coisas que eu não gosto do Rails, essa forma dele disponibilizar
esse metodos dinamicos e de forma aberta e o fato de vc olhar para uma
implementação do ActiveRecord e não saber quais atributos estão
ali, vc tem que ir no banco e lembrar que ele pega aquilo por
reflexão. Novamente não é uma boa escolha, se eu tenho que saber o
detalhe de implementação de uma outra coisa, no caso a tabela,
significa que o meu acoplamento está alto e meu encapsulamento baixo.
Por isso que eu estou gostando de aprender o MonoRail e pretendo
aprender o DJango, eles te abrem os olhos para os erros do Rails. A
página do DJango que fala das filosofias por traz do design é algo
bem interessante
(http://www.djangoproject.com/documentation/design_philosophies/)
Não querendo desqualificar o Rails aqui de forma alguma, seria
redundante da minha parte dizer as maravilhas do rails e como eu admiro
o framework, mas é importante ter uma visão critica com relação ao
tudo.
[]´s
Gustavo Amigo
Nando Vieira
Mas é justamente nesse ponto que o Java peca. Restringir ao máximo o
que o desenvolvedor pode fazer, evitando que ele atire no próprio pé,
e por conta disso, se tornou uma linguagem extremamente burocrática.
E a proposta do Rails é exatamente a contrária. Ser flexível e deixar
por conta do desenvolvedor que ele não atire no próprio pé.
--
Nando Vieira
bloggin' @ http://simplesideias.com.br
Juraci Krohling Costa
Imagina isso:
class Pessoa < ActiveRecord::Base
belongs_to :grupo
end
class PessoasController < ApplicationController
def index
Pessoa.find(1)
Pessoa.find_all_by_name("Juca")
end
end
Eu ainda não entendi o que você está enxergando de problema com o
finder dinâmico :-) Pelo exposto, você não concorda com o
find_all_by_name. Mas concorda com o find ? Afinal, ele também não
está definido no model. Para o consumidor (controller), ambos são
exatamente iguais... São finders, que retornam uma coleção de objetos
ou um objeto Pessoa. Faz diferença para o controller (ou para você
mesmo) o *como* estes dois métodos são implementados?
Agora, veja este trecho:
class Pessoa
attr_accessor :name, :age, :eye_color
end
De forma similar, os métodos "getter" e "setter" não são "visíveis"
nessa classe pessoa, mas existem (métodos "age", "age=", "name",
"name=", ...). São criados pelo "attr_accessor" quando a classe é
carregada. Mas poderia ser implementada "on the fly", por method
missing catcher. Qual a diferença que faz para nós se ele é
implementado por method missing catcher ou quando a classe é
carregada? :-)
Essa idéia de ficar "desencanado" sobre a implementação é própria do
Ruby, e não do Rails em si. O Rails usa com muita classe (com o perdão
do trocadilho) estas features do Ruby. Confesso que quando vi Rails no
começo, achei que era uma gambiarra tremenda. Mas depois que li o
Pickaxe, acabei percebendo que tudo foi muito bem pensado :-)
Quanto a ter que saber "o detalhe de implementação da tabela", acho
que é exatamente o contrário... Você pode manter isso absolutamente
transparente. Imagine o seguinte código:
person = Person.find_by_login("juca")
puts person.age
Age é um método de Person, certo? E quem me garante que é um campo no
banco de dados? Veja, para quem consome, isso *não importa*. Olhando
para o código, você pode achar um método que calcula a idade em anos
com base no campo birthdate, ou você pode achar "nada", o que
significaria que existe um campo "age" no banco de dados. Vale lembrar
que um dos conceitos do Rails, e que o faz ser ágil e não-chato é o
DRY - Don't Repeat Yourself . A relação Tabela <-> Modelo é o melhor
exemplo. Se os campos já existem no banco de dados, porquê falar tudo
de novo para o model ? Sei que não vale como argumento, mas caso
queira ver os campos que um model tem no banco de dados, instale o
plugin annotate_models :-)
Acho importante a visão crítica, com certeza. Mas acho igualmente
importante entendermos tanto a linguagem, o framework e os conceitos
por trás. A linguagem e o framework são reflexos de seus conceitos.
Então, eu não chamaria estes pontos de "erros do Rails". No máximo,
"coisas que não concordo nos conceitos do Rails" :-)
Abraco
Juca.
2006/11/30, Gustavo Amigo <gustav...@gmail.com>:
Pedro Mariano Belo
Mas se você não gosta dos finders dinâmicos também não deve gostar do
AR puxando atributos do BD, concorda?
Ou seja, da mesma forma que aparece um find_by_eye_color também
aparece o atributo eye_color "do nada".
Arthur Henrique Zapparoli
O method_missing é uma das coisas mais legais do Ruby (não estou
falando do Rails)...
O problema é achar todas essas coisas estranhas, pq na linguagem que
vc usava não era assim. :)
Dêem uma lida nesse post:
http://pythonologia.org/2006/11/24/cada-macaco-no-seu-galho/
--
[]'s
Arthur Zapparoli
Everton J. Carpes
Buenas, para quem tem problemas com o fato de ter que ler os schemas para saber o que cada modelo possui,
podem ler mais sobre dois plugins: annotate_models e column_comments.
Estes plugins geram aos modelos, comentarios adicionais com parte da estrutura do teu schema
eu nao sinto muitos problemas com isso, portanto usei apenas uma vez o annotate e apenas para testes, mas fica a dica.
Quanto a questao da adaptacao a evolucoes e a necessidade contratual mais rigida, bem estas fraquezas acabam sendo superadas.
Estava lendo o material lah do Akita sobre os design patterns (http://www.balanceonrails.com.br/articles/2006/10/30/design-patterns-representam-defeitos-nas-linguagens ) e concordei plenamente copm a viusao dele. Acho que ela eh muito aplicavel aqui.
Houve um tempo em que pela falta de recursos linguisticos, se construia um singleton ineficiente em Java ou se fazia os getters e setters na mao (ou ainda mandava a IDE fazer pra ti...).
Com o tempo, as linguagens evoluem e os paradigmas tbm... se eu vou fazer um getter e a maquina pode fazer ele por mim, deixe-a fazer e se preucupe com problemas do teu cliente e nao do teu compilador (bem Ruby isso..)
Eu posso hj largar tudo pro alto e voltar a usar struct pra simular classe em C... alias faco isso, mas quando estou de ferias e brincando no meu minix...
No resto do tempo, preciso de agilidade.
Everton J. Carpes
Mobile: +55 53 9129.4593
MSN: mas...@gmail.com
UIN: 343716195
Jabber: everton...@jabber.org
Gestum
http://www.gestum.com.br/
O.S. Systems
http://www.ossystems.com.br
http://projects.ossystems.com.br
João Paulo Camargo
Davis Cabral - Listas
> Eu sou um cara de poucas palavras, mas criticar o Rails porque ele
> trabalha em cima de um conceito chamado DRY, é simplesmente errado.
> Critique o conceito se quiser.
>
> my 2 cents.
>