Outras formas de geração
Renato
Em primeiro lugar, parabéns pelo Bopepo e pelo projeto JRimum como um
todo. Já utilizei o JBoleto e pelo que vi até agora é outro mundo,
muito menos engessado e já bem arquitetado logo de início.
Gostaria de saber se alguém de vocês já fez alguma visualização direta
para o JRViewer (do JasperReports) do arquivo completo de boletos, em
vez de salvar em PDF diretamente.
No meu caso, específicamente, isto é importante pois eu tenho meu
próprio Viewer que extende o JRViewer do Jasper e recebe um
JasperPrint para fazer a exibição, pode salvar, imprimir, enviar por e-
mail com uma interface padrão da minha aplicação, entre outras coisas.
Uma forma meio fora de padrão de fazer isso, pelo que vejo, seria em
vez de utilizar o template em PDF gerado pelo BrOffice, usar um
template .jrxml do próprio Jasper, que seria usado para criar o
JasperPrint e então ser passado para o JRViewer.
Não cheguei a olhar o código que gera o PDF, mas usa o iText
diretamente, correto? Qual seria o impacto de eu criar um outro
Generator que em vez de "Template.pdf -> Resultado.pdf" fizesse
"Template.jrxml -> JasperPrint" ?
Vocês conseguem vislumbrar a forma menos trabalhosa de se poder gerar
a visualização dos boletos pelo JRViewer sem substituir o template?
Agradeço desde já.
Renato Atilio.
Misael Barreto de Queiroz
Pô cara, você já pegou o espírito da coisa. Uma dos novos recursos que queremos implementar e disponibilizar é justamente a geração de templates usando jasper, porque daí o pessoal que usa JASPER pode continuar em casa e além disso ganharemos várias visualizações além do PDF (Ex: HMTL, XML, ODT ...). Agora não podemos abandonar a idéia do template PDF, pois é muito prático, simples, não está amarrado ao BROffice (pode ser qualquer programa que edite e/ou gere fomulários PDF) e muitos usuários não tem conhecimento de JASPER.
Hoje nós temos um viewer (org.jrimum.bopepo.view.PdfViewer) que trabalha com templates PDF e retorna um PDF, utilizando no caso o iText. Poderíamos no caso criar um outro viewer, que trabalha-se com templates jasper, e ao invés de retornar só PDF, poderia retornar outras formas de visualização (Ex: HMTL, XML, ODT ...) e também, por que não, um JasperPrint.
Há um tempo atrás fiz um teste básico, criando um boleto "primário" no JASPER e passando um objeto boleto, mas tive que parar com a implementação porque pintaram algumas coisas mais urgentes para serem implementadas, como por exemplo a GUIA (versão 0.3-Litio, em desenvolvimento) e também melhorias no componente como um todo (versão 0.2-Helio, em desenvolvimento). Esperamos fechar ambas as versões até o Natal.
Você gostaria de contribuir conosco? O que você poderia fazer para adiantar era criar um template do boleto, no JASPER, e criar uma classe que fizesse o preenchimento deste template JASPER, e métodos que gerassem como retorno um arquivo PDF, HTML, ODT, XML, etc. Que acha? Vamos trabalhar juntos nisto? Sua ajuda é de grande valia para nós do JRIMUM, ainda mais nesta correria atual (trabalho, estudo, "muié e bicho de pé").
Daí depois que você implementasse, você enviaria para nós esta implementação e nós disponibilizaríamos isto oficialmente dentro do componente. Que achas? Dependendo do tempo poderíamos até liberar este novo recurso dentro da versão 0.3-Lítio (GUIA e Template JASPER, presentão de Natal - Rou rou rou....).
Um abraço.
Pode contar com a time JRimum.
Misael Barreto
JRimum Developer
http://www.jrimum.org
http://www.blog.jrimum.org
.
Analista de Sistemas
Squadra Tecnologia
A serviço do:
Departamento de Desenvolvimento de Sistemas
Tribunal de Justiça do Estado do Rio Grande do Norte
e Conselho Nacional De Justiça
+55 (84) 3616.6200 r6415
+55 (84) 3616.6415
Gilmar P.S.L.
Primeiramente, no que se refere a:
Gostaria de saber se alguém de vocês já fez alguma visualização direta
para o JRViewer (do JasperReports) do arquivo completo de boletos, em
vez de salvar em PDF diretamente.
Como misael falou sim, já fizemos alguns testes básicos.
Uma forma meio fora de padrão de fazer isso, pelo que vejo, seria em
vez de utilizar o template em PDF gerado pelo BrOffice, usar um
template .jrxml do próprio Jasper, que seria usado para criar o
JasperPrint e então ser passado para o JRViewer.
É verdade, é uma forma de fazer. Na verdade (pessoalmente) compartilho da visão de que no máximo uma ou duas classes utilitárias seriam feitas para preencher o parametros ou disponibilizar beans para o jasper. Acho que o valor do Bopepo está na geração do modelo (código de barras, linha digitável, etc..), a visualização com o jasper é bem fácil tendo isso tudo em mãos.
Não cheguei a olhar o código que gera o PDF, mas usa o iText
diretamente, correto? Qual seria o impacto de eu criar um outro
Generator que em vez de "Template.pdf -> Resultado.pdf" fizesse
"Template.jrxml -> JasperPrint" ?
Correto usamos o iText diretamente na manipulação dos PDFs. Acredito o impacto do ponto de vista do design seria apenas a dependência das lib jasper. Em termos de esforço, acredito que seja mínimo. Talvez separássemos em dois módulos por questões de dependências de bibliotecas e criássemos um viewer pra o módulo jasper.
Vocês conseguem vislumbrar a forma menos trabalhosa de se poder gerar
a visualização dos boletos pelo JRViewer sem substituir o template?
Talvez a melhor coisa seja criar um módulo jasper usando o modelo do bopepo mesmo.
Como Misael falou, podemos trabalhar juntos nesse novo módulo.
Atenciosamente
Gilmar P.S.L.
--
Você está recebendo esta mensagem porque se inscreveu no grupo "JRimum Community" dos Grupos do Google.
Para postar neste grupo, envie um e-mail para jrimum-c...@googlegroups.com.
Para cancelar a inscrição nesse grupo, envie um e-mail para jrimum-communi...@googlegroups.com.
Para obter mais opções, visite esse grupo em http://groups.google.com/group/jrimum-community?hl=pt-BR.
Renato Atilio
Renato Atilio
Renato Atilio
Misael Barreto de Queiroz
Cara, a idéia inicial é esta mesma. A primeira coisa que tem de ser feita é montar o boleto no JASPER, idêntico ao PDF. No projeto de teste que fiz, eu montei alguns campos básicos (cedente, agência /código do cendente) e foquei no código de barras, na linha digitável e na logo do banco. Consegui fazer legal, daí parei para fazer outras coisas. Eu tinha esse projeto de testes no meu notebook, mas numa bronca que deu cabei perdendo.
No projeto de teste eu fiz assim:
- Criei um projeto JAVA.
- Adicionei o jar do Bopepo e suas dependências.
- Adicionei o jar do Jasper e as dependências necessárias.
- Criei uma classe que chamei de BoletoParser4Jasper. Ela recebia um objeto boleto em seu construtor e a sua missão era facilitar o preenchimento das informações dentro do JASPER. No caso o BoletoParser4Jasper já possuia os atributos já tratados e prontos para exibicão no Jasper, como por exemplo "Agência / Código do Cedente", Sacado (que pode ou não ter endereço) etc. Inicialmente eu até tentei não ter que usar esse parsser, e acessar os atributos do objeto boleto diretamente no jasper, tipo "titulo.getCedente().get...()", só que as vezes precisamos fazer algum tratamento nos dados, concatenar informações, e achei complicado ficar fazendo isso no JASPER em alguns casos.
- Criei uma classe com um método estático que retornava uma Collection<BoletoParser4Jasper>. Daí no template, para exibir alguns dados, era simplesmente escrever o nome do atributo do BoletoParser4Jasper. Ex: F{fieldCedente}, F{fieldAgenciaCodigoCliente}. Para testar eu usava o ambiente do iReport, e esse método estático era a minha fonte de dados (JavaBean DataSource)
Assim que arranjar um tempo vou remontar esse projeto, daí a gente trabalha junto nisso ai. Tu poderia ir montando o template JASPER, tipo deixar o template com o mesmo aspecto visual do template existente PDF?
Se quiser ir montando e já preenchendo o template, como o foco é boleto e não guia, podes usar o último snapshot do Bopepo-0.2.3-Helio:
http://jrimum-community.googlegroups.com/web/JRimum-Bopepo-SNAPSHOT-20101124.jar
Abraço.
Misael Barreto
JRimum Developer
http://www.jrimum.org
http://www.blog.jrimum.org
Renato Atilio
Misael Barreto de Queiroz
O projeto em anexo é do Eclipse Helios. Eu refiz aquilo que tinha falado para você. Ele tá bem básico, dá pra entender legal.
O template está em "TesteBopepoComJasper\template\BoletoTemplate.jrxml".
Pra testar você pode rodar o MAIN da classe TestJasperReport.java.
PS: O relatório foi criado usando o IRepot 3.7.4. Para rodar a classe de testes eu criei uma USER LIBRARY no Eclipse, apontando para o diretório "..\Jaspersoft\iReport-3.7.4\ireport\modules\ext".
A idéia de utilizar uma imagem de fundo pode ser utilizada, mas gosto mais da idéia de montar tudo no Jasper e aproveitar a borda dos campos para montar o boleto em si, acho que o tamanho ficará bem menor do que usar imagem de fundo. Que acha?
Vou ver com Gilmar se já temos um usuário "anonymous" no SNV somente de leitura, daí passamos para você.
Vamos nessa mermãoooooooooooo!
Um abraço.
Renato Atilio
Renato Atilio
Fiz uma forma bem mais invasiva, alterei um bocado de coisa interna da
classe PdfViewer, mas *mantendo compatibilidade* com a API pública de
geração de PDF.
Criei uma classe AbstractViewer, que define as regras genéricas pra
geração, como o texto será formatado, etc. Não depende nem do iText
nem do Jasper.
Então o PdfViewer extende o AbstractViewer colocando as coisas
específicas para o PDF, implementado os métodos setText(), setImage()
e setBarcode(), que fazem a substituição dos campos no template.
Em seguida criei o JasperViewer que extende o AbstractViewer e faz a
parte específica do Jasper, implementando os mesmos métodos.
Tomei cuidado para manter no Jasper os mesmos nomes de campos do ODT,
porque assim a gente mantem um padrão de customização.
Em anexo o mesmo jrxml que você tem lá, mas considerando esta
estrutura que imaginei. Anexei também as classes alteradas.
É uma sugestão. Eu vou usar esta forma de qualquer jeito, mesmo que
não fique no source oficial, acredito que tenha separado a manipulação
dos dados da geração de PDF propriamente dita, podendo permitir uma
nova forma que use outro tipo de template, tipo Eclipse BIRT, ou
qualquer outra coisa, sem muito trabalho.
Desta forma, um build com a classe PdfViewer depende do iText, um
build com a classe JaperViewer depende do Jasper. Simples assim. Não
tem nada engessado de nenhuma das implementações na classe base.
Se vocês toparem, dou continuidade. Apenas não mexi no BoletoViewer,
mas para ficar bem genérico, o BoletoViewer não pode ter um atributo
interno com nenhum viewer, apenas receber um AbstractViewer. Mas isto
é minha opinião.
Ah, não tendo mexido no BoletoViewer, precisei deixar algumas coisas
publicas no JasperViewer, para testar. Mas
Caso seja interessante para vocês que esta forma seja utilizada, só avisarem.
Além disso, dei uma limpada no jrxml. E talvez eu mexeria ainda um
pouco nas Exceptions. Não conclui a implementação, mas acho que ficou
explicado.
Qualquer dúvida, estou à disposição.
Abraço,
Renato Atilio.
2010/12/2 Renato Atilio <rena...@gmail.com>
>
> Opa Misael,
> Muito obrigado, já estou dando uma olhada aqui.
> Sobre a imagem, eu apenas enviei a do JBoleto pra ter uma idéia do layout mais compacto que comentei, mas usá-la como fundo é deixar tudo muito engessado e perder o sentido de usar o Jasper.
> Abraço,
> Renato.
>
> 2010/12/2 Misael Barreto de Queiroz <misael...@tjrn.jus.br>
>>
>> Renato, na correria aqui criei um projeto básico do bobepo com o jasper, usando o último snapshot do Bopepo que te falei. Tu já pode ir adiantando o trabalho.
>>
>> O projeto em anexo é do Eclipse Helios. Eu refiz aquilo que tinha falado para você. Ele tá bem básico, dá pra entender legal.
>> O template está em "TesteBopepoComJasper\template\BoletoTemplate.jrxml".
>>
>> Pra testar você pode rodar o MAIN da classe TestJasperReport.java.
>>
>> PS: O relatório foi criado usando o IRepot 3.7.4. Para rodar a classe de testes eu criei uma USER LIBRARY no Eclipse, apontando para o diretório "..\Jaspersoft\iReport-3.7.4\ireport\modules\ext".
>>
>> A idéia de utilizar uma imagem de fundo pode ser utilizada, mas gosto mais da idéia de montar tudo no Jasper e aproveitar a borda dos campos para montar o boleto em si, acho que o tamanho ficará bem menor do que usar imagem de fundo. Que acha?
>>
>> Vou ver com Gilmar se já temos um usuário "anonymous" no SNV somente de leitura, daí passamos para você.
>>
>> Vamos nessa mermãoooooooooooo!
>> Um abraço.
>>
>>
>>
>> Misael Barreto
>> JRimum Developer
>>
>>
>> http://www.jrimum.org
>> http://www.blog.jrimum.org
>>
>>
>>
>>
>>
>>
>>
>> Em 02/12/2010 15:01, Renato Atilio escreveu:
>>
>> Sim, já estou baixando aqui.
>> Eu pedi acesso read-only ao repositório pois estou com certa urgência e já pretendo terminar isso entre hoje e amanhã, de uma forma que não prejudique o que já está lá. Ai mando um patch e se vocês aprovarem, melhor.
>> De qualquer forma já estou agilizando a implementação, já saquei fora o JBoleto e já está funcionando com o Bopepo, mas salvando em PDF ainda.
>> Vou trabalhar no Viewer agora.
>> Renato.
>>
>> 2010/12/2 Misael Barreto de Queiroz <misael...@tjrn.jus.br>
>>>
>>> Fala Renato,
>>>
>>> Cara, a idéia inicial é esta mesma. A primeira coisa que tem de ser feita é montar o boleto no JASPER, idêntico ao PDF. No projeto de teste que fiz, eu montei alguns campos básicos (cedente, agência /código do cendente) e foquei no código de barras, na linha digitável e na logo do banco. Consegui fazer legal, daí parei para fazer outras coisas. Eu tinha esse projeto de testes no meu notebook, mas numa bronca que deu cabei perdendo.
>>>
>>> No projeto de teste eu fiz assim:
>>> - Criei um projeto JAVA.
>>> - Adicionei o jar do Bopepo e suas dependências.
>>> - Adicionei o jar do Jasper e as dependências necessárias.
>>> - Criei uma classe que chamei de BoletoParser4Jasper. Ela recebia um objeto boleto em seu construtor e a sua missão era facilitar o preenchimento das informações dentro do JASPER. No caso o BoletoParser4Jasper já possuia os atributos já tratados e prontos para exibicão no Jasper, como por exemplo "Agência / Código do Cedente", Sacado (que pode ou não ter endereço) etc. Inicialmente eu até tentei não ter que usar esse parsser, e acessar os atributos do objeto boleto diretamente no jasper, tipo "titulo.getCedente().get...()", só que as vezes precisamos fazer algum tratamento nos dados, concatenar informações, e achei complicado ficar fazendo isso no JASPER em alguns casos.
>>> - Criei uma classe com um método estático que retornava uma Collection<BoletoParser4Jasper>. Daí no template, para exibir alguns dados, era simplesmente escrever o nome do atributo do BoletoParser4Jasper. Ex: F{fieldCedente}, F{fieldAgenciaCodigoCliente}. Para testar eu usava o ambiente do iReport, e esse método estático era a minha fonte de dados (JavaBean DataSource)
>>>
>>> Assim que arranjar um tempo vou remontar esse projeto, daí a gente trabalha junto nisso ai. Tu poderia ir montando o template JASPER, tipo deixar o template com o mesmo aspecto visual do template existente PDF?
>>>
>>> Se quiser ir montando e já preenchendo o template, como o foco é boleto e não guia, podes usar o último snapshot do Bopepo-0.2.3-Helio:
>>> http://jrimum-community.googlegroups.com/web/JRimum-Bopepo-SNAPSHOT-20101124.jar
>>>
>>>
>>> Abraço.
>>>
>>>
Renato Atilio
Apenas alguns comentários sobre o que eu mudaria do que fiz, após
conversa ontem com o Gilmar. Se vocês derem o OK pra gente continuar
isso, já altero.
1. Em vez de ter $F{boleto}.get("txtRsCampo") dentro do Jasper, usar
um JRMapCollectionDataSource em vez do JRBeanCollectionDataSource e
declarar todos os campos, que serão acessados por $F{txtRsCampo},
ficando mais intuitivo para quem for criar outros modelos.
2. Deixar apenas um template padrão em vez de ter um COM e outro SEM
Avalista, usando apenas um band que só é exibido se
boleto.getTitulo().hasSacadorAvalista().
3. Além de ter todos os campos txtRsEtc (que considero importantes
para manter a compatibilidade com o template PDF), ter também um campo
do tipo Boleto num field $F{boleto}, que vai conter todos os valores
originais (numéricos, data, etc) sem formatação ainda. Isto é
interessante pois no caso anterior poderia usar
$F{boleto}.getTitulo().hasSacadorAvalista(), sem contar que pode ser
usado para definir cores para valores negativos ou outras coisas que
venham a ser pertinentes com base nos valores originais.
4. Dentro do jrxml, em vez de usar HTML para definir formatação, usar
as próprias ferramentas do Jasper e sempre separar staticText
("Sacado:") de textField ("$F{txtRsSacado}") também.
5. Comentar um pouco mais o código (Javadoc) e criar os tests.
Abraço
Renato Atilio.
2010/12/2 Renato Atilio <rena...@gmail.com>:
Misael Barreto de Queiroz
Cara, dei uma espiada aqui por cima no que você fez e esse é o caminho mesmo. Você entendeu a idéia que quis passar e já se adiantou adaptando-a dentro do Bopepo.
Aproveitando o teu último e-mail, após conversa com o JRiBoy Gilmar, vou fazer comentários em cima dele:
=====================================================================
1. Em vez de ter $F{boleto}.get("txtRsCampo") dentro do Jasper, usar
um JRMapCollectionDataSource em vez do JRBeanCollectionDataSource e
declarar todos os campos, que serão acessados por $F{txtRsCampo},
ficando mais intuitivo para quem for criar outros modelos.
2. Deixar apenas um template padrão em vez de ter um COM e outro SEM Avalista, usando apenas um band que só é exibido se boleto.getTitulo().hasSacadorAvalista().
3. Além de ter todos os campos txtRsEtc (que considero importantes
para manter a compatibilidade com o template PDF), ter também um campo
do tipo Boleto num field $F{boleto}, que vai conter todos os valores
originais (numéricos, data, etc) sem formatação ainda. Isto é
interessante pois no caso anterior poderia usar
$F{boleto}.getTitulo().hasSacadorAvalista(), sem contar que pode ser
usado para definir cores para valores negativos ou outras coisas que
venham a ser pertinentes com base nos valores originais.
4. Dentro do jrxml, em vez de usar HTML para definir formatação, usar
as próprias ferramentas do Jasper e sempre separar staticText
("Sacado:") de textField ("$F{txtRsSacado}") também.
=====================================================================
Uma coisa que eu não sei se vocês comentaram foi algo sobre alguns métodos presente em BoletoViewer, como o "groupInOnePDF". Esse método faz sentido no PDFViewer, mas não faz sentido no JasperViewer, logo ele não pode ficar em BoletoViewer (fazendo a ponte), já que BoletoViewer contém um AbstractViewer.
Eu até pensei em matar o BoletoViewer, que atualmente faz a ponte para PDFViewer. No caso, os usuários escolheriam qual visualizador gostaria de utilizar. O PDFViewer (que poderia ser renomeado para BoletoPdfFormViewer) e o JasperViewer (poderia ser renomeado para BoletoJasperViewer). Com isto, o que fosse peculiar de um viewer poderia ser tranquilamente implementado e exposto, e o que form comum estaria no AbstractViewer.java.
No caso do JASPER, já podemos oferecer métodos prontos do tipo getPdfAsFile, getXmlAsFile, getOdtAsFile, getJasperPrint etc.
Que acham?
Renato, parabéns aí pela iniciativa cara. Esse é o espírito da coisa.
Aliás, parabéns aí para toda a comunidade JRimum. Galera tá show de bola.
Vamos fechar essa idéia aí!!!
Abraço a todos.
Renato Atilio
Misael Barreto de Queiroz
Não é o Gilmar não cara, é o MISAEL.
Acho que tu leu correndo e não percebeu que eu concordei com a idéia que tu tinha trocado com Gilmar.
No caso do item 1, eu sei que o atributo poderia ser lido, o que quis dizer é que "txtRsCampo" não é um atributo REAL de boleto, daí nao faria muito sentido chamar um atributo que não existe REALMENTE no objeto, ficaria confuso, entende? Desta forma é melhor mesmo chamar o campo diretamente, mantendo o mesmo padrão tanto para iText como pro Jasper, como você fez.
Quanto ao BoletoViewer, se ele morrer, com certeza a idéia é deixar ele DEPRECATED, e criar aquelas outras possibildiades que te falei, senão realmente quebra a banca.
Abração.
