| Autor |
Mensagem |
|
|
|
Não entendi o problema, então. O que não está funcionando como você esperava?
|
 |
|
|
Weber MK wrote:
Console:
isValid: true
isCnpj: true
isCpf: false
O resultado é o esperado. O número em questão tem 14 dígitos e realmente não é um CPF (deve ter 11). Quanto a validação do DV, sempre que você colocar a repetição de um número (zero no caso) dará true.
|
|
|
|
Weber MK wrote:
Testei a validação de CPF e CNPJ, mas não consistiu dígito verificador...
Oi Weber,
Posta exatamente o teste que você fez pra podermos ver o que há. Tem classes de teste para CPF e CNPJ lá no projeto. Elas não estavam acusando erro, mas pode ser que tenha algo não coberto. Nesse caso você já está convocado pra participar da correção.
Um abraço,
|
|
|
|
Pessoal,
Estamos distribuindo um sistema com grande número de acessos simultâneos no WebSphere e estou precisando limitar o número de usuários até que um servidor mais potente nos seja fornecido. O pessoal que administra o WebSphere me diz que não tem como fazer, inclusive dizem que o suporte da IBM fala a mesma coisa.
Alguém sabe se isso procede ou sabe como fazer tal limitação para um determinado contexto/aplicação que rode lá?
Obrigado, um abraço.
|
|
|
|
Pessoal,
Preciso criar um plugin para o Eclipse para editar arquivos de uma determinada linguagem. Olhei o material do help do eclipse e até fiz um projeto baseado no Editor XML. Alguém sabe de um plugin simples com destaque de cores e complemento de código com os fontes pra eu dar uma olhada?
Valeu
|
|
|
|
Sobre normalização de endereços:
1 - Qual é a lista dos Tipos de Logradouro que será adotada? tem uma que eu estava usando na versão que não fo disponibilizada que era baseada no site do correio). Essa questão parece boba mas não é. O que fazermos com tipos de logradouro de sistema legados? No meu sistema, aqui, tem "Buraco", "Vala" e "Trincheira" entre outros  . Todos aceitos pelos correios.
2 - Quais são os campos usados no endereço? Estava assim: TipoLogradouro, NomeLogradouro, Numero, Complemento, Bairro, Municipio, UF e CEP. Devemos usar País também? Mais algum?
3 - Tinha pensado em 2 classes pra fazer isso (além do endereco) Normalizador e Normalizacao. Onde um normalizador aplica uma (ou mais) normalização sobre um endereço. O Normalizador contém uma ou várias Normalizações. Assim o cliente da API pode implementar uma NormalizacaoEspecializado oumemso um NormalizadorEspecializado que já é iniciado com algumas Normalizações dentro dele. Normalizador tem add e remove pra colocar e tirar Normalizações. algu assim ... 
4 - Os Tipos de Logradouro virão em um XML ou similar? A lista de municípios também? Em resumo: O que fazer com as listas?
Esses três pontos já são um bom ponto de início. Gostaria da opinião de vocês.
|
|
|
|
Oi Pessoal,
É bom iniciar um novo tópico pra tocar o projeto. Vamos aproveitar este tópico do BrazilUtils e otimizar as discussões sobre a API. Devo lembrar a todos que o objetivo desse tópico é fazer o código, bem como o trabalho da API como um todo, evoluir. Sempre vamos encontrar críticas e isso é normal. O código sempre poderá melhorar e isso também é normal.
Várias vezes no outro tópico algum membro do fórum postava várias boas idéias apontando vários erros/equivocos no código proposto. Muitas vezes eu já tinha visto esses erros e na maioria delas eu até concordava com a crítica. Não corrigir ou não ter feito da melhor forma da primeira vez pode simplesmente ser falta de tempo e/ou disponibilidade pra se dedicar ao código.
Se vocês procurarem no outro tópico vão ver que eu mesmo critiquei a forma como está a parte de Cpf/Cnpj, mas esta é a forma como já está lá e funcionando. Espero melhorar e fazer o melhor possível. Sempre procuro trabalhar assim, mas vamos ter em mente que este é um projeto open source. Nos últimos meses tenho tido quase nenhum tempo e não pude fazer nem um décimo das alterações que eu gostaria de ter feito antes de soltar a primeira versão. Na verdade, só deu pra passar o código pra 1.4 e olhe lá. O pacote de endereço nem saiu.
Uma das funções de um projeto como este é que quem participa aprende. E aprender errando faz parte do aprendizado. No outro tópico tá cheio de exemplos onde a API foi pra berlinda (pra usar um termo leve) e eu e Ironlyx nunca deixamos isso nos afetar. Quando pudemos fizemos o que pudemos.
Há alguns meses eu assumi a liderança de um projeto enorme e prá lá de complicado pela natureza política. Hoje eu tenho clareza que o BrazilUtils precisou de mais planejamento. Os objetivos não foram bem traçados e a coisa foi andando sempre meio sozinha e com esforços heróicos (louváveis). Eu e Ironlynx sempre dissemos que precisávamos de um gerente pois nenhum de nós tinha experiência nisso. Precisamos dividir algumas tarefas básicas como, por exemplo, alguém pra gerar as distribuiçoes. Fizemos de uma forma a aprendemos com ela o que funciona e o que não funciona.
Ao pessoal que está chegando ou simplesmente fazendo uma crítica eu peço um pouco de paciência e compreenção sobre como funciona esse tipo de trabalho. Muitas vezes vocês vão estar fazendo uma crítica à alguém mais experiente e com mais conhecimento mas que, por algum motivo, não fez o melhor código. Muitas vezes será o inverso, alguém com pouca experiência mas que precisa de incentivo pra melhorar.
Ao pessoal que está fazendo código e participanto eu peço que se preocupem mais com o conteúdo técnico das críticas que com a forma como ela foi feita. Isso é uma coisa produtiva pra vocês mesmos. Eu recomendo que vocês leiam o tópico antigo e vejam como foram feitas as críticas sobre Regex que não estávamos usando onde poderíamos (eu nem sabia o que era). Não foram nada simpáticas. Hoje em dia, aqui no projeto (trabalho), sempre sou eu que faço códigos com Regex e muitas vezes um código horroroso é trocado por uma Regex que simplifica bastante. Isso porque, ná época, eu me preocupei com o conteúdo técnico das críticas feitas, por mais sarcásticas e até pessoais que tenham sido. Comprei um livrinho de Regex e todo mundo saiu ganhando.
Bom trabalho a todos. As críticas são sempre bem vindas.
|
|
|
|
Fischer wrote:Opa, cai de para-quedas aqui  . Eu estou tentando utilizar a API de vocês aqui e me deparei com a seguinte situação: quando eu passo o CNPJ 06124268000111 para o método de validação Cpf.isValid(CNPJ) eu obtenho true como resposta, ou seja, está validando o número  . Agora, quando eu tento criar um objeto da classe Cpf passando o mesmo CNPJ (Cpf cpf = new Cpf(CNPJ)) o método lança uma ValidationException.
Isto é para acontecer ou estou utilizando a API de você forma incorreta (ou os dois quem sabe)?
Grato pela atenção!
Fischer
Olá. Creio que já esteja resolvido esse problema. As classes CPF e CNPJ sobreescrevem o método isValid() e só testam se o tamanho for correto. Se você passar um CNPJ em CPF.isValid() vai ter retorno false.
|
|
|
|
Ironlynx wrote:
Falandio nisso, como vão os teste?
Os do Douglas eu ainda não sei, o meu deu uma atrasada pq o site que eu usava para comparar não está mais no ar e eu uso outros 2 agora para isso.
Se não estivesse atrasado teria algo errado. Minha definiçao de "prazo" se tornou muito singular nos últimos meses.
No domingo devo disponibilizar os testes.
|
|
|
|
Ironlynx wrote:
Como dificilmente alguém vai criar novas subclasses de InscricaoEstadual, e todas as que já existem são final, não sei se vale a pena mexer. O que acham?
Acho que NÃO vale a pena mexer.
Vamos marcar um skype no FDS para discutirmos?
Por mim tudo bem. Devo estar trabalhando mesmo. Se vai ser liberado algo no dia 22 já é bom gerar o jar e fazer testes. Quando às alterações nas classes, acho que a prioridade gerar uma versão.
|
|
|
|
Rafael,
Estava dando uma olhada nas clases de Inscrição Estadual e vi que todas elas ganharam um atributo nextValidator que é onde é guardado o próximo validador a ser chamado. Esse atributo não poderia estar na classe InscricaoEstadual como "protected"? Talvez até como "private" com os métodos implementados somente na classe InscricaoEstadual já que são todos idênticos. Ao invés de ter 27 métodos idênticos nas classes filhas teria só um na classe mãe.
|
|
|
|
RafaelRio wrote:
Justo o pacote de meu maior interesse! 
Então vamos lançar logo a primeira versão para eu começar a colocar as minhas mãos no pacote de endereço. Douglas, você me dá uma força, não é?
Como eu disse anteriormente, o enum TipoLogradouro deve ser substituído por uma classe e os dados por um arquivo XML. Não é só esse. O de municípios, países e UFs também. Tenho trabalhado diretamente com esses padrões de endereço desde janeiro do ano passado. O pacote de endereço está meio desatualizado. Depois que sair a primeira versão podemos reiniciar a implementar esse pacote. Posso adiantar que tem muitas funcionalidades que atualmente não são contempladas. Acabei trabalhando em um código em java que é baseado nesse só que com um ano de evolução e acesso a realidades práticas e problemas de sistemas que têm nos endereços uma informação chave. Acredito que a forma como esse pacote vai ficar vai contemplar do sistema mais simples ao mais complexo. Pra isso eu preciso liberar algum tempo, se tiver ajuda melhor ainda.
RafaelRio wrote:
Não entendi o que fazer com as classes de CPF/CNPJ. Deixa como está?
O código que você postou como sendo a nova proposta é totalmente possível com as classes como estão. Por isso acho que não é necessário trocar agora. Se numa segunda versão fizermos as alterações que você sugeriu este código não se altera em nada. A diferença é que neste código chama-se setCpf() e setCnpj(), poderia ser um mesmo para ambas as classes como setNumero().
Além disso, como já havia dito, a proposta de novas classes tem que contemplar as situações de Cpf e Cnpj que não são pré definidas. Acho que na primeira versão elas deveriam ficar como estão, ou talvez aquele método único de set para ambas as classes.
|
|
|
|
RafaelRio wrote:
Dever de casa (Douglas):
Passar código-fonte do Java 5 para Java 1.4.
Vários TODO - Verificar máscara
Fazer um tutorialzinho sobre as nuances de InscricaoEstadualRO
Esse dever de casa não é nada mole. Tem uns enuns pra substiruir. Isso significa que a forma como se usa essa classe muda pelo código. Já passei por isso este ano e não é nada agradável. Porém, atendendo a pedidos, eu refiz as classes UF e TelMask de forma que os pacotes UF (UF e inscrições estaduais) e Telefone estão já compatíveis com 1.4. O mesmo vale pro pacote cpfcnpj. Fica faltando o de endereço que acho que um erro de projeto. O Enum TipoLogradouro não deveria ser uma lista "chapada" em código e sim um arquivo xml acoplado. A lista que tá lá, tá caduca e a normalização tem que ser melhorada antes de ser liberada.
O pacote ID deve ser excluído já que era apenas uma idéia que ninguém comprou e implementou as classes. Assim, acho que pra primeira versão pode-se ignorar o pacote endereço (por enquanto) e deletar de vez o pacote id que não acredito vá fazer sentido.
O Enum UF pode ser um dia substituído por xml também, mas nesse caso como são só 27 e uma mudança nisso implica, de qualquer forma, em impacto em código acho que pode ficar assim.
Já dei commit no "dever de casa", tinha inclusive coisa pra alterar na classe "Inscrição Estadual", era uma List com Generics que eu tirei. Recomendo que os Generics que já estão no código sejam simplesmente comentados pra no futuro serem postos de volta.
Por incrível que pareça eu rodei o teste escrito há séculos e ele rodou!
Acho que pra primeira versão, o pacote "br" deve incluir só o seguinte:
pacote cpfcnpj - com classes de Cpf e Cnpj
pacote telefone - com as classes de telefone
pacote uf- com a classe de UF e as de Inscrição estadual.
Mas ainda acho que se pode retirar também o pacote "validation" e as referencias a interface Validable e GenericValidation. Essa amarração não é necessária.
Rafael, dê uma olhada na classe UF como ficou agora e veja se o padrão chain não pode ser aplicado lá também. Aliás, como uma UF tem internamente uma Inscriçao Estadual, talvez seja nela que esse padrão deva ser implementado, não sendo necesário que as IEs tenham referência umas pras outras, mas é só um palpite. Você pode dizer melhor o que fazer sobre isso.
|
|
|
|
RafaelRio wrote:E me posicionem sobre a questão da validação de CPF/CNPJ. Se já tivessem decidido, elas já estariam prontas.
Atualmente existe a classe CpfCnpj que concentra os códigos de validação de uma ou outra coisa. Ao instanciar um objeto dessa classe, este objeto pode ter comportamento de uma ou outra. Pode iniciar como um e transformar-se em outra. Isso, de fato, acontece. Mas se vc quiser, no seu sistema, usar tudo bem separado desde o início pode usar o código como você postou com as classes novas mesmo usando as que já estão lá.Basta usar as classes Cpf e Cnpj seperadamente. Por isso elas existem. Ao declarar e instanciar um Cpf ele sempre será Cpf, idem pro Cnpj. Mas no caso "mutante" deve-se declarar e talvez instanciar um CpfCnpj. Essa possibilidade não é possível na implementação nova. Os flags a mais dentro do algorítimo de validação são um custo baixo pra quem tem o problema da "mutação". isCpf() e isCnpj() podem, obviamente, ser ignorados se você estiver usando as classes especializadas Cpf e Cnpj, mas no caso de indeterminação eles ajudam bastante.
Acho que pra primeira distribuição deve-se retirar o pacote validation que tá obriganto classes como CpfCnpj, Ie e etc implementar como num framework. Isso tá meio forçado (da minha parte na época) pro usuário da API.
|
|
|
|
|
*** clicado "citar" no lugar de "editar". perdão!
|
|
|
|