Manejo de Eventos TreeView - Ejemplo

EJEMPLO - EVENTOS TREEVIEW

Las listas 7.7 y 7.8 dan un código completo para un ejemplo de página de selección TreeView, como muestra las figuras 1 y 2. Estas figuras también ilustran sus nodos productos usando check boxes. El usuario puede también checkear uno o mas de estos boxes, y entonces clickear el boton comprar.

Figura 1 Ejemplo de manejo de árbol selección de nodos

Figura 2 TreeEventHandling.aspx

Listing 7.7 TreeEventHandling.aspx

Listing 7.8 TreeEventHandling.aspx.cs

using System;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
public partial class TreeEventHandling : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
if (!IsPostBack)
{
// Fill tree with data
FillTree();
// Let's begin with all the nodes collapsed as well
treeMain.CollapseAll();
}
}
///

/// Helper method to fill tree with data
///

private void FillTree()
{


// Get all the groups and iterate through them
string[] groups = ProductCatalog.GetGroups();
foreach (string grp in groups)
{
// Create the node for the group
TreeNode groupNode = new TreeNode(grp);
// For each group get their subheadings and process them
string[] subheadings =
ProductCatalog.GetSubHeadingsByGroup(grp);
foreach (string sub in subheadings)
{
// Create the node for the subheading
TreeNode subheadingNode = new TreeNode(sub);
// For each subheading, get their products
// and process them
Product[] products =
ProductCatalog.GetProductObjectsBySubHeading(sub);
foreach (Product prod in products)
{
// Create new product tree node
TreeNode productNode = new TreeNode(prod.Name);
// Set the node's value to the product id
productNode.Value = prod.Id.ToString();
// Add product node to its parent
subheadingNode.ChildNodes.Add(productNode);
}

// Add subheading node to its parent
groupNode.ChildNodes.Add(subheadingNode);
}
// Add group node to its parent
treeMain.Nodes.Add(groupNode);
}
}
///

/// Handles the tree node selection event
///

protected void SelectProduct(object sender, EventArgs e)
{
// Get the tree node that was selected
TreeNode node = treeMain.SelectedNode;
// Only process selection if a leaf node selected
if (node.ChildNodes.Count == 0)
{

// Retrieve the product id that we placed in the node
int id = Convert.ToInt32(node.Value);
// From that product id get the product
Product prod = ProductCatalog.GetProductById(id);

// If this is a valid product, display details
if (prod != null)
{
txtId.Text = prod.Id.ToString();
txtIsbn.Text = prod.Isbn;
txtName.Text = prod.Name;
txtPrice.Text = String.Format("{0:c}", prod.Price);
}
}
}
///

/// Handles the purchase button click event
///

protected void btnPurchase_Click(object sender, EventArgs e)
{
// Handle the fact there may be no checked products
if (treeMain.CheckedNodes.Count <= 0)

labChoose.Text =

"You did not choose any products to purchase";

else

{

labChoose.Text = "You have selected the following products:";

double total = 0.0;

bulSelected.Items.Clear();

// Loop through each checked node

foreach (TreeNode node in treeMain.CheckedNodes)

{

// Retrieve the product info about this node int id = Convert.ToInt32(node.Value);

Product prod = ProductCatalog.GetProductById(id);

// If valid product, add it to list

// and add it to running total

if (prod != null)

{

string s = prod.Name;

s += "(" + String.Format("{0:c}", prod.Price) +

")";

ListItem item = new ListItem(s);

bulSelected.Items.Add(item);

total += prod.Price;

}

}

labTotal.Text = "Total purchase price: ";

labTotal.Text += String.Format("{0:c}", total);

}

}

}

Codificacion: Los siete Pilares del desarrollo

CODIGO EN MOVIMIENTO



Por Laura Wingerd y Christopher Seiwald
“BEAUTIFUL CODE” – OREILLY

Al principio en el planeamiento de este libro, el colaborador Greg Wilson pregunto si Beautiful Code fue un apropiado titulo.”Mucho de lo que discutirás es diseño y arquitectura de software, antes que código” nos escribió.

Pero este capitulo es acerca de código, no es acerca de que hace el código, no es acerca que cuan hermoso es esto. En lugar de eso, este capitulo trata del look del código, específicamente, como ciertas características visibles de codificación hacen posible la colaboración.

Esto es lo hermoso del “Código en movimiento”.

Lo que estas leyendo esta tomado mayormente del articulo de Christopher Seiwald’s,
”Los siete Pilares de Buen Código” (http://www.perforce.com/perforce/papers/prettycode.html.).

En Resumen los siete pilares son:

Ø Siendo “bookish” (Formato de libros)

Ø Verse semejante.

Ø Venciendo la anidación.

Ø Desenredando bloques de código

Ø Comentando Bloques de código

Ø Decluterring

Ø Aliarse con un estilo existente.

Mientras estos pueden sonar igual a convenciones de codificación, son más que eso. Ellos son manifestaciones exteriores de las prácticas de desarrollo que siempre producen evolución sobre la comprensión.

En este capitulo, veremos como los siete pilares tienen soportado a una pieza de código que estuvo siendo parte de un sistema de software comercial por 10 años.

Esta pieza de código es DiffMerge, un componente del Sistemas Gestor de Configuración del software Perforce.

DiffMerge trabaja para producir un clásico “Combinador por comparación”, comparando dos versiones de un archivo de texto (“tramo 1” y “tramo 2”) a una versión de referencia (“La base”).


En los archivos ingresados, el resultado salida de líneas interpoladas con placeholders marcan las líneas que están en conflicto.

Si has usado Perforce, has visto DiffMerge para trabajar en el comando p4 resolve y en gráficos Perforce’s .

DiffMerge fue originalmente escrito en 1996. A pesar de su simple objetivo, un combinador de texto, esta función cambio para ser llenado con complejidad.
Siendo una elevación de casos especiales de la idiosincrasia de interfaces de usuario, lenguajes de programación, personalidad de codificaciones y los programadores mismos. (“Eso no es un conflicto”, “si es”, “no es”)
En los años DiffMerge en un convirtió en una parte de desarrollo critico en el software Perforce.


Siendo “bookish”

“Los Siete pilares del buen código” describe guías que nosotros usaremos en Perforce Software. Los siete pilares no son solo guías de codificación a usar, no están aplicadas a todos nuestros proyectos de desarrollo. Nosotros aplicamos estos a componentes tal como DiffMerge donde el mismo código esta probablemente activo en varias versiones soportadas al mismo tiempo y modificadas por varios programadores.
El efecto de los siete pilares es hacer código mas comprensible para los programadores quienes son los que leen esto, en varios de los escenarios en los que ellos mismos buscan leer el mismo.

Por ejemplo, los siete pilares aconsejan ser “bookish.” Los Textos de libros y revistas están compuestas de columnas, usualmente en pocas columnas apretadas en la pagina.

Porque? Porque la estreches reduce el trabajo de ir de atrás a adelante capturadando por nuestros ojos cuando leemos. Leer es fácil cuando nuestros ojos trabajan menos.
Leer también es fácil cuando lo que nosotros tenemos leyendo y lo que estamos próximos a leer están ambos en nuestro rango visual. Investigaciones muestran que como nuestros ojos cambian de foco de palabra a palabra, nuestros cerebros pueden tomar señales desde el circunvecino, desenfocando la forma. Muchos de nuestros cerebros pueden recabar “el preventivo avance” del sentido textual dentro de la periferia visual, lo bueno es que están permitidos a dirigir a nuestros ojos para maximizar la comprensión.


El código no es estrictamente texto, pero para propósitos de legibilidad humana, el mismo principio aplica. Código “Bookish”- esto es, código formateado en libro- como columnas y trozos – es fácil de comprender.
Bookishness es más que una simple conservación en líneas cortas. Esta es la diferencia entre codigo que luce igual a esto:

Y codigo que luce igual a esto:

El segundo de estos códigos pertenece a DiffMerge. Cuando nosotros leemos esto, nuestros cerebros sienten el alcance de la lógica a la mano, y nuestros ojos no tienen que llegar muy lejos de lado a lado para entender.


Verse igualmente Semejante

El Fragmento DiffMerge en la sección previa también ilustra otro principio de escritura para la compresibilidad: código que es observado semejante.

Nosotros vemos esto en todo el código DiffMerge. Por ejemplo:

La demostración precedente como líneas cortas puede crear un patrón visual que hará esto fácil para nuestros cerebros ver un patrón lógico. Nosotros podemos decir en una mirada que tres de las cuatro pruebas en esta declaración While son esencialmente lo mismo.


Aquí esta un ejemplo mas de verse semejante. Esta única ilustración de codificación que deja que nuestras mentes hagan una exitosa operación: “una de estas no es de la misma forma”.


Aun si no conoces acerca del código, esta claramente a la vista, por ejemplo, que readfile y state están establecidos en todos los tres casos, pero solo en el tercer caso esta state establecido incondicionalmente. El programador quien escribió esto esta concentrado para construir una apariencia semejante; aquellos de nosotros que leemos esto después, podemos ver en una mirada donde esta la lógica esencial.


El peligro del código Anidado

Todos enseñamos a usar la Anidación para mostrar la profundidad del anidamiento en los bloques lógicos. La profundidad del anidamiento, más allá, a la derecha de página deberá aparecer el código anidado. Código Formateado así es una muy buena idea, pero no porque esto haga a código alguno fácil de leer.

Si cualquier, código profundamente anidado es difícil de leer. Importante lógica es apiñada fuera de la derecha, sumergiendo casi a insignificantes notas al margen por las capas de codigo if-then else que rodean esto, mientras triviales pruebas aplicadas en bloques exteriores parecen elevados en importancia.
Así mientras la anidación es útil para mostrar donde comienzan y finalizan los bloques, esta no hace para nosotros el código fácil de comprender.


El gran peligro es la animación; el código anidado esfuerza la comprensión humana, claro y simple. Edward Tufte no estaba siendo halagador cuando el escribió que “Algunas veces son tan complejas e intensamente anidada que ello se asemeja a código de computador ”. Steve McConnell advirtió sobre el uso anidado de declaraciones if
- no porque ellos sean ineficioentes o ineficaces, sino porque ellos son difíciles sobre la comprensión humana. El dice :” Para entender el codigo, tu tienes observar el conjunto entero de anidaciones if en tu mente al mismo tiempo”.No sorprende que en investigaciones señalan a las condicionales anidadas como el mas propenso a error de todas las estructuras de programación. Una gran evidencia de esto es “DiffMerge’s”

A lo largo de los marcados DiffMerge’s

Nosotros tenemos un registro de cada cambio, división, y anexión correspondiente a DiifMerge a lo largo de sus 10 años de historia. Y es un interesante record. La Figura 32-3 ofrece una pequeña vista de los cambios a las versiones liberadas de DiffMerge. Esto muestra que DiffMerge comenzó en la línea principal y ha estado siendo versionado hacia más de 20 versiones.
Los cambios a DiffMerge han ocurrido en la Línea Principal, la mayor parte. Pero el grafico muestra una actividad peculiar en algunos de los más recientes releases.

Un grafico de conteo de parches del DifMerge’s por release , ver en la figura 32-4, es aun mas intrigante. Esto muestra que DiffMerge fue raramente parchado después que fuese liberada – hasta el release2004.2 esta. Cuando el subsiguiente – parche release evalúa altamente, solamente para decrecer otra vez en el release 2006.2. Porque están los releases 2004.2 hasta el 2006.1 así, ¿ un acertijo entre parches?



Aquí esta la historia: DiffMerge comenzó como un aprovechable pero simple programa combinador. En esta temprana vida, esta hizo poco para discriminar entre combinaciones actuales conflictivas y no conflictivas, cambios de líneas. En el 2004, nosotros mejoramos DiffMerge para ser atildado respecto a la detección y resolución de conflictos. Como en el release 2004.2, DiffMerge fue por supuesto más capaz, pero este fue un buggy. Nosotros conseguimos reportes de error en el 2004.2 y 2005.1 -
Por lo tanto un gran numero de parches.


Nosotros probamos en limpiar el código para el release el 2005.2, pero la limpieza resulto en un error tan intratable que nosotros tuvimos que restaurar la versión 2005.1 dentro del release 2005.2. Entonces, en el 2006, nosotros reescribimos las partes problemáticas del DiffMerge completo. La reescritura fue bien exitosa, aunque tuvimos un susto en el release 2006.1.Desde entonces, DiffMerge fue muy estable, y el indicador de parches post-release bajaron a cero.

Así, cuanto hicimos mal cuando nosotros reescribimos DiffMerge en el 2004? Nosotros pensamos que esto sucedió cuando dejamos el código convertirse en incomprensible.
Quizás nuestra revisión de código en el tiempo perdió de vista los siete pilares, o quizás nosotros salteamos algunas revisiones enteramente.

En cualquier índice, aunque esta continuado el grafico de regresión, DiffMerge navego dentro de releases llenos de Bugs que no vimos en el grafico.
No tenemos forma para medir cuan legible es el código fuente o cuan bien esta adaptado a los siete pilares.
La Figura 32.5 muestra un número de declaraciones if y sus respectivos niveles de anidamiento (depths) en cada periodo inicial de DiffMerge. En esa época nosotros modificamos y ramificamos DiffMerge para el 2004.2, al parecer, nosotros duplicamos el número de declaraciones if en el código. Y por primera vez, allí estaban ifs anidados a más de tres niveles de profundidad.


Correlación no es causalidad, como se dice, y podrá haber otros factores contribuyentes.
El diseño de la mejora, los casos de prueba, las otras construcciones codificadas -hasta el tamaño del archivo código fuente- algunas o todas de estas podrá contribuir a la alza de las estadísticas de errores. Sin apreciar que conocemos acerca de profundidad de las condicionales anidadas y la comprensibilidad, no es difícil tomar esta deslumbrante correlación para valorar.


Conclusión

Para un programador trabajando sobre código en evolución, hermoso es el código que puede ser modificado con un mínimo de agitación. Tú lees el código, determinas que hace, y cambias esto. Tu éxito depende mucho sobre cuan bien sobreentiendes el código al comienzo mediante tu habilidad para programar. También depende sobre cuan bien tu código es entendido por los próximos programadores que abordaran este; si ustedes nunca llamaron ayuda de fuera, ustedes tuvieron buen termino.


A todos nos debe gustar realmente leer desde la izquierda para decir que el éxito del código en movimiento depende de cuan comprensible es esto para los programadores quienes leerán el código.