Haciendo Reportes para Aplicaciones Web: Parte 3
Bien, continuando con esta última parte de la serie de de reportes para aplicaciones web, vamos a basarnos en el reporte que ya teníamos antes para hacer una construcción de subreportes o reportes anidados.
En primer lugar, debemos decir que un subreporte no es más que un reporte independiente que es definido y llamado desde dentro de otro reporte. En el diseñador de reportes debemos seleccionar el objeto Subreport y arrastrarlo hasta nuestro reporte.
Hay dos requerimientos importantes que debemos mencionar acerca de los subreportes:
1. La estructura del subreporte debe ser por medio de una tabla (diseño en forma de tabla, no se refiere a que los datos deben provenir de una tabla de base de datos).
2. En el reporte padre solamente se muestra la parte de “Body” del subreporte (el header y footer son ignorados).
Haciendo Reportes para Aplicaciones Web: Parte 2
Esta es la segunda parte de la serie de artículos dedicada a la construcción de reportes para aplicaciones web. En esta parte vamos a examinar dos aspectos muy importantes en la construcción de reportes. El primero es como “hacer” reportes que se parametrizan por código y el segundo es como enviarle parámetros a los reportes para que puedan filtrar información y mostrar solo lo que nos interesa.
En primer lugar debemos ver en detalle el código generado en nuestro ejemplo de órdenes de la base de datos Northwind. Recuerden que no hemos escrito hasta ahora ninguna línea de código, a pesar que la aplicación fue creada en C#, aún no hemos creado nada usando lenguaje.
Lo prmero es ver el código fuente de la página:
<%@ Page Language=”C#” AutoEventWireup=”true” CodeBehind=”Default.aspx.cs” Inherits=”Report.Part1._Default” %>
<%@ Register Assembly=”Microsoft.ReportViewer.WebForms, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a” Namespace=”Microsoft.Reporting.WebForms” TagPrefix=”rsweb” %>
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
<html xmlns=”http://www.w3.org/1999/xhtml” >
<head runat=”server”>
<title>Untitled Page</title>
</head>
<body>
<form id=”form1″ runat=”server”>
<div>
<rsweb:ReportViewer ID=”ReportViewer1″ runat=”server” Font-Names=”Verdana”
Font-Size=”8pt” Height=”400px” Width=”649px”>
<LocalReport ReportPath=”Ordenes.rdlc”>
<DataSources>
<rsweb:ReportDataSource DataSourceId=”ObjectDataSource1″ Name=”DataSet1_Orders” />
</DataSources>
</LocalReport>
</rsweb:ReportViewer>
<asp:ObjectDataSource ID=”ObjectDataSource1″ runat=”server”
SelectMethod=”GetData”
TypeName=”Report.Part1.DataSet1TableAdapters.OrdersTableAdapter”>
</asp:ObjectDataSource>
</div>
</form>
</body>
</html>
Haciendo Reportes para Aplicaciones Web: Parte 1
Muchas veces nos encontramos realizando sistemas de información que se dedican a capturar datos pero que también necesitan una manera de procesarlos y mostrarlos. Para esta tarea entran en juego los famosos Reportes que no son más que objetos que entregan información en un formato particular y que permiten realizar ciertas operaciones como imprimirlos, enviarlos por email, guardarlos a un archivo, etc.
Es importante mencionar que los datos almacenados son útiles en la misma medida que se puedan convertir en información para las personas que los necesitan. También es importante subrayar que la plataforma tecnológica que utilicemos debe poder tener facilidades para convertir los datos en información y poder entregarlos a los usuarios de forma que sean útiles.
Pues bien, el caso es que el .net Framework no es la excepción. Al instalar cualquiera de los productos, desde las versiones express hasta la versión TeamSuite podemos realizar reportes y presentarlos a los usuarios para que puedan utilizar la preciada información.
Primero debemos entender que estamos haciendo y porqué. El caso es el siguiente, por lo regular, un reporte será impreso en hojas de papel con un tamaño específico, esto nos lleva al primer desafío, tenemos que poder entregar información que quepa dentro de estas hojas de papel y que pueda ser impreso sin problemas a una impresora local o remota. El segundo desafío es poder realizar esta operación desde una aplicación web; pero ¿Cuál es el problema aquí? Pues muy sencillo, lo que sucede es que una página web es un objeto que tiene un despliegue único, es decir, todos los datos se muestran en una “tira” continua de información lo que hace difícil sino imposible hacer que la impresión sea consistente y predecible. El tercer desafío es poder hacer que la solución sea utilizable para “cualquier navegador” lo que en si es todo un reto.
Entonces, la solución que encontramos en el .net Framework es la del objeto Microsoft.ReportViewer.WebForms. Este objeto nos permite realizar todas las operaciones descritas con anterioridad y permite también superar los desafíos planteados.
En primer lugar, debemos decir que un reporte en una aplicación web se compone de 4 partes principales: 1) Un documento reporte. 2) Un objeto ReportViewer. 3) Una fuente de datos. 4) Una página que permita mostrar al ReportViewer.
Blogs externos
-
Archivos
- Junio de 2008 (3)
- Mayo de 2008 (3)
- Abril de 2008 (4)
- Marzo de 2008 (7)
- Febrero de 2008 (12)
- Enero de 2008 (11)
- Diciembre de 2007 (3)
- Noviembre de 2007 (13)
-
Categorías
-
RSS
Subscripciones RSS
RSS de los Comentarios
