JasperReports X JSP para relatórios, qual é melhor?

Então,

Eu tenho pouca experiência com Jasper, mas o pouco que usei (porem fortemente), ele sempre se mostrou bem versátil. Ele é um tanto chato na hora de montar o layout, atraves do iReport, por exemplo, mas acho que no final acaba sendo mais prático que o JSP e também tem a facilidade de vc reaproveitar diversos relatorios, apenas preenchendo os datasources com as fontes que voce quiser.

Eu achei legal. Nao sei se é a melhor opção, mas é bacana.

Renato.

O meu problema de versatilidade é justamente este.
Planejo fazer relatórios onde o usuário pode escolher os campos que estarão no relatório e como com o jasper eu tenho que compilá-lo antes de fazer isto, acho que com ele eu fico muito restrito…

Enquanto que se eu fizer um script no JSP que pegue o tamanho das colunas, com isto eu já poderei montar o meu relatório…

Abraços
Dirceu

vonlinkerstain:

O meu problema de versatilidade é justamente este.
Planejo fazer relatórios onde o usuário pode escolher os campos que estarão no relatório e como com o jasper eu tenho que compilá-lo antes de fazer isto, acho que com ele eu fico muito restrito…

Enquanto que se eu fizer um script no JSP que pegue o tamanho das colunas, com isto eu já poderei montar o meu relatório…

Abraços
Dirceu

Não sei qual a utilidade de se fazer um relatório escolhendo o campo, é mais um trabalho para o usuário, imagina:

Escolher os parametros e depois escolher os campos, não sei.

Mas como tem gosto pra tudo, o Jasper não precisa de ter um arquivo compilado.

Como vc pode ter observado, o JasperReports gera um relatório a partir de uma descição XML, quando vc faz o desenhozinho bonitinho no iReport, vc está gerando este XML.

E ainda existem classes do jasper que compilam em tempo de execução.

Portanto não existe falta de “versatilidade”, se vc for louco o bastante pode gerar em seu programa o XML, e depois mandar compilar o relatório por este XML. É trabalhoso? Acredito que sim, mas é praticamente o mesmo trabalho que vc terá em gerar o relatório em JSP.

Ué, pode gerar diferentes XML e compilar / usar o que corresponde à opção selecionada…

Mas dependendo do número de opções vai ter um calhamaço de xmls…

mantabodyboarder:

Ué, pode gerar diferentes XML e compilar / usar o que corresponde à opção selecionada…

Mas dependendo do número de opções vai ter um calhamaço de xmls…

Este é o problema, ter um calhamaço de opções…

LuizAvila:

Não sei qual a utilidade de se fazer um relatório escolhendo o campo, é mais um trabalho para o usuário, imagina:

Escolher os parametros e depois escolher os campos, não sei.

Mas como tem gosto pra tudo, o Jasper não precisa de ter um arquivo compilado.

Como vc pode ter observado, o JasperReports gera um relatório a partir de uma descição XML, quando vc faz o desenhozinho bonitinho no iReport, vc está gerando este XML.

E ainda existem classes do jasper que compilam em tempo de execução.

Portanto não existe falta de “versatilidade”, se vc for louco o bastante pode gerar em seu programa o XML, e depois mandar compilar o relatório por este XML. É trabalhoso? Acredito que sim, mas é praticamente o mesmo trabalho que vc terá em gerar o relatório em JSP.

Quanto ao xml do jasper eu sei, o problema é que se eu tiver que compilar, será que os relatórios não vão ficar muuuuuiiiito lerdos?

Agora eu não sabia destas classes do jasper que são jit.
Acabei me expressando errado, não vou deixar o usuário escolher todos os campos do relatório, mas alguns campos dos relatórios podem ser inúteis para alguns usuários, com isso eu quero deixar a opção de que eles possam retirar tais campos do relatório.

Nada impede você de gerar o .jrxml do Jasper e compilar em tempo de execução, atingindo o grau de flexibilidade que você quiser.

A grande dúvida nisto tudo é saber se gerando o jrxml e compilando ele, se isso não vai consumir muito tempo computacional…

O único jeito de saber é testando, e somente testando sob condições reais. Tente gerar um relatório mediano no seu ambiente final usando as duas soluções e compare os resultados.

A grande dúvida nisto tudo é saber se gerando o jrxml e compilando ele, se isso não vai consumir muito tempo computacional…

Pense bem, quanto mais recursos genéricos vc disponibilizar em um sistema mais tempo de processamento

Imagina, vc vai ter que gerar o XML on demand, depois mandar compilar pra gerar um arquivo “.jasper”, depois mandar carregar, tem mais processamento sim.

Aqui na empresa temos exatamente esta situação, alguns clientes um relatório com um determinado campo, outros com esse campo mais um outro qualquer, outros com este campo mais dois de cabeça pra baixo, o que fazems nesse caso?

o cliente aprova o modelo que ele quer e desenvolvemos um específico, acho que o ganho é muito maior, pois assim podemos trabalhar com os arquivos precompilados. Afinal relatório é sempre igual ele apenas muda os dados. Se um cliente usa um determinado tipo de relatório pra ele analisar uma determinada situação, ele vai usar esse relatório sempre.

o que eu tenho que fazer por aqui é tanto com jsp e com o jasper.

o jsp seleciona os dados e exibe na tela, como se fosse um relatorio. esses dados sao selecionados na hora pelo usuario, como se fosse uma tela de estatisticas.

a consulta envolve é claro o select, o where e ainda tem group by. isso tudo o jsp acessa e busca.

e ai tenho que pegar essa consulta e gerar um relatorio, tipo pdf, e se encaixa o jasper. a minha intencao é passar essa consulta sql pro jasper, e ai entao o jasper, já com o layout dos campos pronto, faria a consulta e geraria o pdf. Ou salvando o arquivo mesmo ou usando o jasperviewer, que tem a opcao de salvar ou nao o relatorio

o detalhe dessa estatistica é que nao é obrigado fazer uma consulta com todos os campos, mas no jasper já estou deixando pra exibir mesmo assim, pois nao sei ainda como exibir só os selecionados, até porque a organizacao do layout no jasper é uma coisa feita antes, nao é?

O layout do jasper é feita antes sim. O que eu queria era que o usuário tivesse a opção de escolher, na hora de gerar o relatório, quais dos campos entrariam naquele relatório.
Só que pensando bem, com isto, eu teria uma despadronização do caramba, pois a cada impressão, um usuário poderia gerar um mesmo relatório de maneira diferente.

é exatamente esse meu problema…

imagina em várias opcoes, um usuario pode escolher 2 e gerar um relatorio. depois ele seleciona mais opcoes e pede de novo o relatorio, e assim segue até o numero de combinacoes que pode ter dependendo da quantidade de informacoes que a gente tá deixando disponivel

a solucao disso eu nao sei ainda, por isso to deixando o relatorio exibindo todas as informacoes, independente do que o usuario escolheu. o que vai mudar é a quantidade de informacoes a ser exibida. nesse caso, mudaria o where da consulta (tipo o intervalo entre datas, ou um where que tenha valor x para tal atributo) e seriam retornadas menos tuplas

Acho que ai tu já tomou uma decisão meio precipitada. Isto pode ser bom para um certo tempo, porém a longo prazo isso será custoso.
Acho que a melhor solução no seu caso será você discutir com os usuários e padronizar os relatórios.
Depois de prontos, ai eles terão somente as informações necessárias e também, eles poderão escolher a faixa de dados que entrarão no relatório (o que já acontece hoje).

Estou procurando uma API de relatórios para Java justamente por isso.
Para criar relatórios dinamicos e cross tab com mais flexibilidade.
Estava pensando eu mesmo criar uma API se eu não encontrar baseado no IText para criar relatórios em PDF e Excell.
Eu já uso essas bibliotecas e são bem legais mas gostaria de dar mais abstração.