Experimentos, reflexiones y otros artefactos (y V)

He preferido que esta quinta entrega cerrara el título "Experimentos, reflexiones y otros artefactos", y despedir estos mini artículos o mini serie, si es que se pueden llamar así, con un ejemplo un tanto más avanzado, pero en la linea de los anteriores. Así que me habeis tenido aperreado toda la semana dandole vueltas a la cabeza sobre cómo iba a finalizar estas entradas. 🙂 No. No creais que es sencillo elegir el experimento ya que debe cumplir a priori algunas condiciones en cuanto a la extensión, a su complejidad, al uso de componentes que puedan ser compatibles en varias versiones y casi siempre en cuanto a que sea verdaderamente didáctico. Por lo que no vale cualquier idea que te venga a la cabeza sino que tienes que pelearte con ella y ver si realmente te vale. Y os confieso cuando uno llega a casa tras la jornada diaria quedan pocas ganas de pelearse con nada (os pasará tambien a vosotros casi con seguridad).

Experimentos, reflexiones y otros artefactos (IV)

Lo habíamos dejado en la parte en la que haciamos un pequeño boceto de las dos clases que ibamos a considerar. La clase TGenerador y la clase TAtributo. Eso nos permitía ver como se podían relacionar y a modo de prueba, imaginábamos un método para permitirnos alterar el orden de los mismos, en caso de ser necesario. Durante esta semana he podido sacer algunos minutos para adelantarme y darle forma a esas dos ideas. Pero no teneis que perder de vista, por favor, que lo importante no es el código en si mismo, que no es mas que un ejemplo cualquiera y puede contener alguna que otra errata al analizarlo con profundidad, sino el hecho mismo de solicitar de cada uno, un ejercicio de analisis previo y reflexión, intentando razonar en terminos de clases, en la medida que nos sea posible.

Experimentos, reflexiones y otros artefactos (III)

Como reza esa primera imagen que abre el post, es un buen momento para intentar razonar en terminos de clases, y experimentar con el ejemplo que intentabamos abordar y que nos servía para reflexionar. En él, podríamos capturar la idea de atributo, como ya se ha podido extraer de las dos entradas anteriores, consistía en un rasgo diferenciador que combinado con otros, nos servía para identificar un artículo determinado. Convenimos en aceptar la clase TAtributo como una representación de ese rasgo.

Experimentos, reflexiones y otros artefactos (II)

Nuestro formulario iba creciendo. De hecho habíamos incluído una pequeña modificación que invertía el código y el formulario, comenzaba a parecerse -con la prudencia que hace falta para comentar ésto ya que estas lineas son meramente experimentales- a una hipotética herramienta para generar combinaciones de códigos. Esto nos permite tomar una pequeña dosis de realidad en nuestro razonamiento. Una herramienta que iba a crecer pero ligada desgraciadamente a los componentes que iban formando su interfaz.

Experimentos, reflexiones y otros artefactos (I)

Vamos a iniciar una pequeña serie especialmente dedicada a los programadores que se inician en Delphi y me perdonareis que no tenga la menor idea de cuantos capitulos contiene ni de cuanto tiempo se pueda extender. ¿Uno, dos? ¿quizás tres? ¿veintiuno?. Realmente os confieso que no lo se.

Por curiosidad (y Parte III)

Tanto la propiedad Data como Delta se definen como OleVariants, y se organizan internamente como un array de bytes, y es esta característica la que va a dotar de flexibilidad a las dos estructuras, que soportaran por un lado los datos, el contenido real, en el caso de la propiedad Data, y un registro de actualizaciones que representa a la propiedad Delta. Dicho registro, logicamente es de solo lectura, dado que es la unica forma de garantizar que es tan solo manipulable por el propio dataset. Tambien es por esa razón, ya que no nos es permitido modificarlo, es por la que existen metodos que nos permiten limpiar esa cache de datos que contiene los registros de cambios.

Por curiosidad (Parte II)

Seguimos el experimento, intentado satisfacer nuestra curiosidad. 🙂 Vamos a hacer lo siguiente: * En el modulo de datos eliminamos los dos componentes TClientDataSet que contienen los detalles. Es decir, cdsComposicion y cdsComponentes desaparecen. Tambien eliminamos todos los campos persistentes del dataset maestro cdsArticulos Logicamente, una vez hecho esto, los dos componentes TDataSource ligados a los mismos (a cdsComposicion y a cdsComponentes) ahora han perdido las referencias a los dataset y apuntan a nil.

Por curiosidad (Parte I)

Por curiosidad, ya que hablamos de AdoExpres y Datasnap, vamos a perder unos minutos en un par de comentarios que me parecen interesantes y que me hicieron reflexionar varios días de la semana que ha acabado. Como muchos de los comentarios que hemos compartido, han surgido a raiz del trabajo diario. En este caso, concretamente al modificar la ficha de Clientes ya que se consideraba la implementación de un proceso que recalculara las comisiones, que era uno de los detalles de la misma. Aquella pestalla mostraba las comisiones generadas por las compras de dicho cliente y era otro mas de los detalles de la ficha. Veamos... el proceso iba a disparar un procedimiento en la base de datos cuya misión era recalcular las comisiones que se mostraban en la rejilla y, en principio, no iba a retornar un conjunto de datos sino unicamente el exito en la finalización o el codigo del error de existir éste. Esto era problematico en el sentido de que, dado que nuestro conjunto de datos se ubica en la cache local y el procedimiento es disparado en nuestro servidor, los valores visualizados por el usuario podian en determinados casos diferir de los reales tras la ejecución del proceso, y podríamos necesitar invalidar el contenido de aquel dataset para mostrar los nuevos datos.

Cero contra quinientos sesenta ( Anexo)

No iba a escribir esta entrada pero me ha pasado algo similar a lo que me ocurrió con los comentarios sobre JediVCL, donde despues de haber acabado el segundo artículo, sentía que quedaban cosas que comentar y redacté un pequeño anexo con el que dejaba lo que me parecía mas importante zanjado. El resto de funciones se pueden ver sobre la marcha. Es más cuestión del día a día, a medida que te van surgiendo las dudas. Con este tema, siento que pasa algo similar. Hemos compartido dos entradas donde comentabamos como se generaban, y en base a que criterios, las sentencias sql que el proveedor (TDataSetProvider) finalmente "ejecuta" (o manda ejecutar). Bueno. Ya visteis que no él, sino que se apoya en una clase que crea a demanda, que se llama TSQLResolver. Concretamente, y para entrar un poco mas en detalle se iniciaba todo desde la función CreateResolver.

Cero contra quinientos sesenta ( y Parte 2)

En esta segunda parte de la historia, debería pienso, empezar a explicar el por qué del título, que seguramente os puede haber causado extrañeza. Todo tiene una explicación. Vereis, en estos casos, cuando existe un error y no tienes una explicación lógica que lo justifique, es cuando hacemos uso de herramientas de depuración que casi nos hacen sentirnos como sabuesos. Nos vemos a media tarde, siguiendo paso a paso la depuración del código o como en esté caso concreto nos paso, haciendo uso de una herramienta que nos permitía husmear entre bastidores, como puede ser el analizador de sql de SQL Server.

Algunas ventajas… (¡si eres capaz de recordarlas!) – Parte III

Recordando la entrada anterior, en la que me cuestionaba la oportunidad de haber dotado una estructura clásica de nuestra programación, como puede ser la del registro (Record), de aspectos que podían acercarla notablemente a las clases, me llevó a profundizar un tanto sobre los motivos y ciertamente, tras la lectura de uno de los capítulos del libro "Delphi 2007 Handbook" de Marco Cantú, encontré que se aludían básicamente motivos de rapidez en la ejecución del código, por la forma en que se gestiona el acceso y la carga de la memoria en ambas estructuras. Los registros tienen menor coste en su gestión. Una variable local de registro, por poner un ejemplo, se gestiona en memoria desde la pila, motivo suficiente para que su coste sea menor que el soportado por una instancia de una clase que se ubica en una dirección de memoria y se gestiona desde el sistema de memoria (memory manager).

Dos artículos interesantes de Jose Castillo sobre Delphi

En este caso, ambos artículos, me pasaron inadvertidos en las lecturas que he podido hacer del blog de Jose Castillo, y ha sido al leer el boletin informativo que remite DanySoft por correo electrónico, donde he podido advertirlos. Y la verdad es que me parecen muy interesantes. Ambos articulos hablan de como atomizar las transacciones en el caso de DataSnap cuando queremos incluir en una sola transacción dos o mas ClientDataSet, de forma que podamos controlar que concluyen con exito todas las modificaciones para validar la operación y consolidar los datos.

Multifind

El 29 de Julio del 2003 y tras varias semanas de trabajo, Jose Manuel Navarro y yo, decidimos presentar Multifind a un pequeño concurso que se celebra en una web de Internet: http://www.delphiheaven.com/ El premio consistía en un libro de Marteens, a la postre uno de los autores que divulgan conocimientos sobre bases de datos... Leer más →

TThreads

  TITULO ARTICULO Nº REVISTA DESCARGA TThread I Síntesis Nº 11 Visualizar - TThread II Síntesis Nº 12 Visualizar Fuentes TThread III Síntesis Nº 13 Visualizar Fuentes TThread IV Síntesis Nº 14 Visualizar Fuentes TThread V Síntesis Nº 15 Visualizar Fuentes TThread VI Síntesis Nº 16 Visualizar Fuentes

Objetos auxiliares

  TITULO ARTICULO Nº REVISTA DESCARGA Objetos Auxiliares I Síntesis Nº 3 Visualizar - Objetos Auxiliares II Síntesis Nº 4 Visualizar Fuentes Objetos Auxiliares III Síntesis Nº 5 Visualizar - Objetos Auxiliares IV Síntesis Nº 6 Visualizar - Objetos Auxiliares V Síntesis Nº 7 Visualizar Fuentes Objetos Auxiliares VI Síntesis Nº 8 Visualizar Fuentes Objetos... Leer más →

Blog de WordPress.com.

Subir ↑