| Autor |
Mensagem |
|
|
Ironlynx wrote:
Qual a nova data de lançamento?
Discuta isso comigo no email, pq o Douglas tá enrolado no CadFuncNadQualquerCoisa lah do Serpro.
Pô Ironlinx, é CadSincNac - Cadastro Sincronizado Nacional. Aliás, por ironia do destino, em breve o termo CNPJ, provavelmente, será substituído por algo assim. Já que o Cadastro Nacional de Pessoas Jurídicas vai ser incorporado pelo Cadastro Sincronizado Nacional. Os nomes das classes já podem estar caducos! rs
Por falar nisso, os números de CNPJ que tem 0001 no final não são mais, necessariamente, a matriz. Muitas rotinas verificam o número do CNPJ procurando esse "0001" no fim pra saber se a empresa é matriz. Já não é mais assim. (boa sorte)
Minha equipe (de 4 pessoas!!) está com 2 de férias e os prazos você já conhece! Se alguém quiser fazer como o Renato, e dar uma olhada e criticar o pacote "br", é uma boa! Sempre que puder eu respondo aqui alguma dúvida. Código novo, como o do "chain" é bem vindo também.
Uma coisa que deveria ser escrita é uma clase de teste para cada Inscrição estadual validando um número considerável de IEs de cada estado. Algumas certas e outras erradas. Eu segui os algorítimos do Sintegra mas alguma coisa pode ter mudade desde então.
http://www.sintegra.gov.br/ clique em "Informações Gerais -> Inscrições Estaduais"
|
 |
|
|
RafaelRio wrote:
Benefícios:
- métodos isCnpj() e isCpf() não são mais necessários;
- eliminação de flags isCpf, isCnpj;
- mais fácil de entender: cnpj é cnpj, cpf é cpf.
Desvantagens:
- alguma duplicação de código, pelo fato dos algoritimos de validação de Cpf e Cnpj serem parecidos. (Douglas, foi por isso que você criou uma classe CpfCnpj, não foi?)
Existe um problema prático que depois de desenvolver muitos sistemas acabei antecipanto na classe CpfCnpj. Ela não existe apenas pra ter código em comum e depois ter uma Cpf e uma Cnpj. Na verdade, na maioria dos casos, você não sabe exatamente se vai ter um Cpf ou um Cnpj! Isso complica bastante a equação. Por acaso o algorítimo é semelhante e pode ser usado um só.
Em muitos casos, um objeto CpfCnpj que inicialmente era um Cpf vira um Cnpj! Assim você até pode ter classes de Cpf e Cnpj para os casos onde essa "mutaçao" não é possível, mas ela acontece. Logo, o quanto mais código na superclasse, que não pode ser abstrata, melhor. O mesmo vale pro método estático que faz a validação do número. Ele deve estar preparado pra receber um (11) ou outro (14). Na verdade, há algum tempo tenho me questionado sobre a existência dessas classes da forma como estão. Acho que o método estático que valida os números é o que 99% das pessoas precisa. E da forma que está não serve pro 1% restantante. Acho que essas exceptions de Validation devem sair.
Quanto às alterações na Inscrição Estadual ficaram ótimas. Principalmente porque não altera o que já estava feito. Se for garantido a opcionalidade de usar essa validação em cascata fica ótimo.
|
|
|
|
RafaelRio wrote:
Depende. É por isso que existe o método addChain (vide exemplo acima). Se eu colocar apenas duas classes de validação na cadeia, se a IE for inválida para os dois estados representados pela classe, ela será invalidada após ser testada apenas pelas duas classes.
Se colocar seis classes (São Paulo, Rio, Paraná, Amazonas, Ceará, Mato Grosso), se a IE for inválida para todos os estados, retorna após a execução do teste pelas seis classes que estão na cadeia.
Ok ?
Acho que compreendi como usar o padrão. A delegação fica a cargo do usuário da API não da própria API. Vc cria umas IEs e junta as que vc precisar. Passa um número pra primeira e as outras são acionadas em seguida. Mas a fila de IEs é definida pelo uauário através de addChain() ou coisa do tipo.
|
|
|
|
felipesp wrote:Companheiros,
Pesquisei neste tópico se já havia post de código de formatação de CEP. Como não encontrei estou enviando. Espero ser útil.
Felipe,
Existe uma classe chamada Cep no pacote org.brazilutils.br.endereco.
Não entendi exatamente o que significa formatar 4-8 para 00004-008. Normalmente eu vejo muito em sistemas formatação de 5 para 8 caracteres, o que normalmente se faz adicionando três zeros ou consultando alguma base de dados.
Em que casos se usa essas formatações que você postou? Pode-se adaptar a calsse de Cep adicionando parte desse código que você fez.
|
|
|
|
RafaelRio wrote:Chain é um dos padrões catalogados pela GoF.
Douglas, você tinha pedido sugestões porque está para fazer mudanças nessas classes. Não tinha pensado em nada ainda. Já faz um tempinho que estava pensando numa ótima maneira de usar as classes de validação e acho que essa pode ser uma delas.
T+!
Pessoal, perdoe a minha ausência nesse período, já nem sei mais que dia da semana é pq estou trabalhando direto. Vou tentar dar uma atenção maior ao projeto.
Rafael,
Eu entendi o que é o padrão, mas acho que você poderia colocar um exemplo usando as próprias classes que estão no pacote de inscrição estadual. Acho que a utilização desse padrão não inviabiliza o que já está lá. Só tenho uma questão: como uma classe de IE vai saber que um número de IE é inválido por não se daquele estado ou porque é inválido mesmo? Se eu entendi bem, um número de IE só será considerado inválido após ser invalidado pelas 27 classes. Correto?
|
|
|
|
Ironlynx wrote:
Ainda não encontrei nada publicado nesta pagina:
Calma!Breve encontrará. Aliás, eu vou ver como arrumar aquele layout lah do java.net.Nós temos logos e ainda não colocamos.
Pessoal(principalmente rafaelRio,dudansk e douglas):
dia 12(outubro) temos mais um daqueles feriados na quinta(que muitas vezes acabam por emendar na sexta...), e gostaria de saber da disponibilidade de vocês em participar de uma reunião online(pode ser Skype,google talk...) para fazermos um mini "HandsOn" com todo mundo testando o código de todo mundo e finalmente marcarmos um release.
Pra mim ok. Dia 14 vou viajar, espero. No dia das crianças eu vou estar em casa. 
|
|
|
|
Pessoal,
Estava devendo uma geral no código que eu fiz há algum tempo. Gostaria de saber se alguém esta usando alguma parte da API, principalmente do pacote br. Estou querendo dar um super refactoring, pois o código que está lá é da época que estávamos testanto várias idéias. Hoje eu baixei os fontes e vi que tem muita porcaria que precisa sair, além de adaptar o código ao java 1.4, se for o caso.
Aparente mente os pacotes cpfCnpj, telefone e uf/ie (inscrição estadual) não sofreram grandes mudanças mas o resto deve passar por uma geral. Essa é uma boa hora pra dar alguma opinião pois já já deve sair o prmeiro release.
Devemos ter cuidado com o que entra nessa primeira distribuição pra não ter que tirar ou mudar muito depois. Por isso quero fazer isso agora.
Rafael,
Quanto ao email que você me mandou, vou responder aqui pois pode valer pra outros membros do projeto também. Acho que o prioritário é terminar e testar as classes que já estão lá, senão é mais um ano pra sair a primeira versão.
Se você leu o post inteiro, percebeu que algumas sugestões foram bem loucas (muitas minhas a propósito), e que sequer foram pra frente. No início, o objetivo era levantar idéias mesmo, mas algumas acho meio fora de escopo. O objetivo do projeto é gerar uma API, algumas idéias estavam muito além disso, alguns códigos que fiz (como o de validação) também foram muito longe tomando caminho de uma espécie de framework, o que é um pouco demais (por isso o refactoring). Se alguém quiser pensar/criar novas classes, pelo menos agora, pensem am algo pequeno e específico, como foi o pacote de código de barra, que ficou muito bom.
Aguardo retorno
|
|
|
|
Ironlynx e Rafael,
Acho que a questão de usar 1.4 ou 5.0 deve ser pensada com mais calma. Lembrem-se que fazer na 5.0 vai impedir que muita gente use a API. Quanto a questão do desempenho, acho que algum ganho nesse sentido está muito mais ligado em como o sistema cliente é feito do que nas APIs que são rápidas ou lentas. As funcionalidades não me parecem críticas: validação, código de barras; cálculos talvez.
Pessoalmente acho que deveríamos fazer na 1.4 e aumentar o leque de pessoas usando a API e dando retorno.
Tive uma experiência aqui no projeto tremendamente desagradável de ter que desfazer código feito em 5.0 para 1.4 justamente porque o servidor de aplicação ainda não estava pronto para 5.0. Isso é uma realizade bastante comum.
Nós nem fizemos um levantamento de qual parte da API precisaria mesmo se feita em 5.0, acho que devemos começar por aí.
|
|
|
|
MarcioTavares wrote:
Rafael Nunes wrote:...qual a influencia sobre os signos de Caronte, Ceres e Xena também considerados planetas anões?
Pois é, o ponto é que a Astrologia não é uma "ciência exata", e tudo o que está definido hoje não é definitivo. Para acontecer alguma mudança na Astrologia atual, como verificar a influência de algum outro astro na vida das pessoas, seriam necessárias décadas e talvez séculos de estudos. A própria Astrologia não foi concebida de uma hora pra outra. Talvez eles até tenham grande influência na Astrologia mesmo, mas levaria muito tempo para algo ser oficializado.
Acho que isso chegou a ser falado no Fantástico, naquela série Poeira das Estrelas.
Independente de se acreditar ou não em Astrologia, acho que devemos ter em mente que Astrologia NÂO é ciência de forma alguma, nem exata nem de nenhum tipo.
http://pt.wikipedia.org/wiki/Ci%C3%AAncia
Por isso mesmo acho que uma definição científica sobre se Plutão é ou não um planeta não deve (ria) fazer a menor diferença para os Astrólogos.
|
|
|
|
Há mais ou menos 2 meses, eu e os desenvolvedores do meu projeto tivemos a ingrata surpresa de, depois de 4 meses desenvolvemdo em java 5, ficar sabendo que o sistema só poderia ser posto em produção no 1.4 (ia ser 1.3) porque o servidor de aplicação era de uma versão antiga e a nova sabe-se lá quando chega.
Refazer o código tem sido muito triste. Ter que comentar os Generics e Annotatios me parte o coração.
Tendo o desprazer dessa experiência, posso fazer uma lista igual a do Thingol só que com o que achei mais complicado desfazer do java 5 para 1.4 de volta:
thingol wrote:Minha lista:
- Generics +/- (muito acadêmico pro meu gosto)
- Enums +/- (muito parecido demais com o Effective Java; podia ser mais bobo)
- Static imports --- realmente não funcionam bem
- foreach +
- autoboxing +/-
- varargs +/- (eu em particular preferiria uma sintaxe de arrays "anônimos")
- annotations +
- Generics +/- (é só comentar a aturar os warnings)
- Enums ++ (esse é F***, muda o código dependente pra caramba)
- Static imports ? (acho que não usamos)
- foreach + (bem chatinho de refazer)
- autoboxing +/- (muito código inútil apareceu de novo)
- varargs +/- (usou-se pouco)
- annotations +/- (só comentar também)
|
|
|
|
Fui testar o Plugin no Eclipse e agora ele abre sem me perguntar qual workspace eu quero usar. Já tentei várias configurações do Workspace mas ele nunca mais perguntou.
Alguém já teve esse problema?
|
|
|
|
Eu gosto de fazer o download do Eclipse com o Wtp embutido:
http://download.eclipse.org/webtools/downloads/drops/R-1.0.2-200604200208/
Faça download do "All-in-One", descompacte e pronto.
|
|
|
|
|
Coloque o código todo, pois se o erro estiver em "gerarRota()" ou "getRota()" não vai dar pra saber. Aparentemente não tem erro de ArrayList e sim na criação da rota em si.
|
|
|
|
|
Você está tentando criar um objeto da classe DialogLayout2 (linha 25) que parece não existir. O mesmo vale para DialogSeparator. Me parece que está havendo confusão entre os nomes das classes e os dos atributos.
|
|
|
|
O problema desse código é que você está tratando a excessão ao criar um Cliente por que você já sabe que pode dar erro no constructor. Algum desavisado não iria fazer isso e o programa ia dar pau feio!
Já que você pretende lançar uma excessão se o código ou nome forem inválidos, deixe isso claro para no constructor da classe.
|
|
|
|
|
|