Opciones personalizables para los usuarios de una aplicación Web: posibles soluciones

[dec]

Hola,

Empezado por Román

Yo no creo que sea necesario actualizar nada. Por ello mencioné lo de valores por defecto. Cuando un usuario se conecte, al momento de deserializar, el objeto OpcionesUsuario tendrá más propiedades, pero éstas tendran valores por defecto. Cuando guardes las opciones ya guardarás todas ellas pues lo que habrás actualizado será el método Save del objeto.

Me pierdo un poco en el tema de la inicialización de las opciones. En lo que "he caído" es en que acaso no sea preciso serializar todo el objeto, sino que bastaría con hacerlo con el Array que guarde las opciones, propiamente. Esto es posible porque PHP no sólo serializa Objetos (ignoro ahora mismo si un Array lo es en PHP, pero, me parece que no), sino, variables de tipo "mixed"... y Arrays, por ejemplo.

Empezado por Maeyanes

Ahora, como sería? Como usuario inicio sesión, la aplicación lee las opciones de la base de datos ("deserializa" el objeto), hago algún cambio de estas opciones, trabajo con la aplicación y finalizo la sesión, la aplicación aquí guarda las opciones (o puede guardarlas desde que aplico los cambios a estas opciones).

Exacto. Las opciones por defecto siempre serán las mismas hasta que el usuario las cambie... en el apartado de opciones de la aplicación. Efectivamente, tendrá que "aplicar los cambios", puesto que, por las características de una aplicación de este tipo, no es posible guardar las opciones "cuando el usuario salga de la aplicación", pongamos por caso.

Pero, de todos modos, los programas no tienen porqué guardar las opciones al salir, aunque ahora me doy cuenta de que esto lo he hecho alguna que otra vez... hombre, tal vez algunas opciones han de guardarse al salir, como la posición de un formulario en pantalla, pero, buena parte de las opciones se "tocarán" en el apartado de opciones, se editarán y se guardarán desde ahí cuando el usuario lo precise.

Empezado por Maeyanes

Dado lo anterior, ¿en que momento se podría agregar una opción nueva? Esto lo pregunto por que no se exactamente como funciona la serialización de objetos en PHP. A lo que voy, si creo el objeto con un arreglo de X elementos, al "deserializar" este objeto conteniendo X - 1 elementos, ¿se pierde el elemento extra con el que inicialicé el arreglo o solo se sobreescriben los que ya existían?

Si serializas un objeto que contiene diez "propiedades" al deserializar será eso lo que recuperes. Ahora... cómo añades opciones... pues supongo que "todo a la vez". Esto es, supongamos un Plugin que necesitara añadir un par de opciones de usuario... cuando esto se llevara a cabo habría se añadirían las opciones al Array correspondiente, y, efectivamente, habría en ese mismo punto que actualizar la base de datos, es decir, para que en sucesivas ocasiones la nueva opción estuviera disponible.

No he podido resistir y he escrito este poco de código en un momento como aquél que dice (no lo he probado ni nada) y lo expongo aquí porque creo que puede dar alguna idea de cómo llevar a cabo el tema, haciéndolo como venimos diciendo:

Código PHP:

<?php

class Opciones
{
  var $idUsuario = 0;
  var $opciones = null;

  function Opciones($idUsuario)
  {
    $this->opciones = array();
    $this->idUsuario = $idUsuario;    
    $this->Cargar();
  }

  /**
   * Cargamos las opciones del usuario.
   */
  function Cargar()
  {
    global $bdatos;
    $consultaSql = "SELECT opcion_contenido FROM opciones 
     WHERE opcion_id_usuario = '{$this->idUsuario}' LIMIT 1;";
    $this->opciones = unserialize($bdatos->Variable($consultaSql));    
  }

  /**
   * Guardamos las opciones del usuario.
   */
  function Guardar()
  {
    global $bdatos;
    $contenido = serialize($this->opciones);
    $consultaSQL = "UPDATE opciones SET opcion_contenido = '$contenido'
     WHERE opcion_id_usuario = '{$this->idUsuario}' LIMIT 1;";
  }
  
  /**
   * Averiguamos si existe una opción de usuario en concreto.
   *
   * @param string $clave
   * @return boolean
   */
  function Existe($clave)
  {
    return array_key_exists($clave, $this->opciones);
  }

  /**
   * Leemos el valor de una opción. Si esta no existe retornamos el valor
   * por defecto que se especifique en el parámetro correspondiente.
   * 
   * Nota: esos "mixed", ¿qué pasa con ellos?
   *
   * @param string $clave
   * @param mixed $valorPorDefecto
   * @return mixed
   */
  function Leer($clave, $valorPorDefecto = '')
  {
    if(!isset($this->opciones[strtolower($clave)]))
      return $valorPorDefecto;    
    else 
      return $this->opciones[strtolower($clave)];
  }

  /**
   * Escribimos el valor de una opción del usuario.
   *
   * Nota: Otra vez el "mixed" sale a relucir...
   * 
   * @param string $clave
   * @param mixed $valor
   */
  function Escribir($clave, $valor)
  {
    $this->opciones[strtolower($clave)] = $valor;    
    $this->Actualizar();
  }  
  
  /**
   * Actualiza las opciones del usuario.
   */
  function Actualizar()
  {
    $this->Guardar();
  }
  
} // class Opciones

?>

Por supuesto el código anterior no está ni probado, ni "concluído" ni nada de nada... pero puede dar alguna idea, espero. En caso de dudas aquí estamos. ¡Y otra vez muchas gracias a todos muchachos!

[[maeyanes]]

Yo me refiero a la serialización de arreglos, ya que es de lo que has hablado, que tu clase opciones contenga un arreglo con estas y sus valores, es por eso mi ejemplo. En cuanto a propiedades si me doy la idea de como sería.

Saludos...

[dec]

Hola,

Bueno. No creas que tengo del todo claro el asunto Maeyanes, ni mucho menos... ahora mismo estoy haciendo alguna que otra prueba, pero, según voy avanzando me va surgiendo algún que otro reparo... qué sé yo... pero, vamos a ver si sacamos algo en claro. Desde luego este Hilo me ha venido estupendamente.

Si todo esto no es más que por un usuario de Loturak, que quiere que las descripciones de los enlaces siempre estén visibles, ya ves tú... no tiene otra cosa mejor en qué pensar... el jodío, y yo, que, sabiéndolo, pues quiero darle el gusto, porque además creo que esto abre la puerta a otras posibilidades.

Ahora, espero que nos os toque nunca un usuario tan puñetero como el que os digo.

[[maeyanes]]

Hay de todo en la viña del señor...

Pues también mucho de esto me servirá para cuando me adentre más en esto del PHP... jejeje



Saludos y suerte...

[dec]

Hola,

Ea. Pues ya es posible que este usuario puñetero (que está tardando en decirme algo bonito) vea siempre la descripción de los enlaces de Loturak. Ya está añadida esa opción,... y creo que no sería complejo añadir otras, pero, me temo que no tan "sencillamente" como esta que digo, a lo menos no en todos los casos. Se han dejado no pocos cabos sueltos.

Sin embargo, puede que lo que ha salido de este Hilo sea la base de la que partir. Es decir, como digo, parece que la cosa marcha bien. Piénsese que los usuarios de Loturak no notarán cambio alguno, esto es, los enlaces se verán como hasta ahora, porque la opción por defecto es no mostrar la descripción de estos de primeras, pero, ya pueden hacer que esto no sea así.

Por ejemplo, me llama la atención que Loturak cuenta con 85 usuarios, pero, la tabla de opciones cuenta con un registro: mis propias opciones. Sin embargo, como digo, no tendré que "rellenar" la tabla de opciones para el resto de usuarios, puesto que, siempre se tomará la medida "por defecto" en caso de que las opciones de un usuario no existan.

¿Y cuando existirán? Evidentemente, cuando el usuario eche un vistazo a sus opciones (en el apartado correspondiente) y decida "aplicar los cambios".

La clase que estoy utilizando ahora mismo es tal que así, empero, he subido la misma al Servidor para que el puñetero usuario que he mencionado (y quien quiera) pueda ver cómo queda el asunto. Evidentemente el código fuente que se ha implicado en todo esto (sorprendentemente sencillo) hay que repasarlo mejor.

Código PHP:

<?php

class Opciones
{
  var $idUsuario = 0;
  var $opciones = null;

  function Opciones($idUsuario)
  {
    $this->opciones = array();
    $this->idUsuario = $idUsuario;    
    $this->Cargar();
  }

  /**
   * Cargamos las opciones del usuario.
   */
  function Cargar()
  {
    global $bdatos;
    $consultaSql = "SELECT opcion_contenido FROM opciones 
     WHERE opcion_id_usuario = '{$this->idUsuario}' LIMIT 1;";    
    $contenido = $bdatos->Variable($consultaSql);
    
    if($contenido)
    {
      $this->opciones = unserialize($bdatos->Variable($consultaSql));      
    }
      
    return;
  }

  /**
   * Guardamos las opciones del usuario.
   */
  function Guardar()
  {
    global $bdatos;
    $contenido = serialize($this->opciones);
    
    $consultaSQL = "SELECT opcion_contenido FROM opciones 
     WHERE opcion_id_usuario = '{$this->idUsuario}' LIMIT 1;";    
    $resultado = $bdatos->Resultados($consultaSQL); 
    
    if($resultado)
    {
      $consultaSQL = "UPDATE opciones SET opcion_contenido = '$contenido'
       WHERE opcion_id_usuario = '{$this->idUsuario}' LIMIT 1;";
       $bdatos->Resultados($consultaSQL);       
    }
    else 
    {
      $contenido = $bdatos->Escapar(serialize($this->opciones));
      $consultaSQL = "INSERT INTO opciones (opcion_id_usuario,opcion_contenido)
       VALUES('{$this->idUsuario}', '$contenido');";
      $bdatos->Resultados($consultaSQL);             
    }
    
    return;    
  }
  
  /**
   * Averiguamos si existe una opción de usuario en concreto.
   *
   * @param string $clave
   * @return boolean
   */
  function Existe($clave)
  {
    return array_key_exists($clave, $this->opciones);
  }

  /**
   * Leemos el valor de una opción. Si esta no existe retornamos el valor
   * por defecto que se especifique en el parámetro correspondiente.
   * 
   * Nota: esos "mixed", ¿qué pasa con ellos?
   *
   * @param string $clave
   * @param mixed $valorPorDefecto
   * @return mixed
   */
  function Leer($clave, $valorPorDefecto = '')
  {    
    if(!$this->Existe($clave))
      return $valorPorDefecto;
    
    if(!isset($this->opciones[strtolower($clave)]))
      return $valorPorDefecto;    
    else 
      return $this->opciones[strtolower($clave)];
  }

  /**
   * Escribimos el valor de una opción del usuario.
   *
   * Nota: Otra vez el "mixed" sale a relucir...
   * 
   * @param string $clave
   * @param mixed $valor
   */
  function Escribir($clave, $valor)
  {
    $this->opciones[strtolower($clave)] = $valor;    
    return;    
  }  
  
  /**
   * Actualiza las opciones del usuario.
   */
  function Actualizar()
  {
    $this->Guardar();
    return;    
  }
  
} // class Opciones

?>

Como he dicho antes, esta clase se instancia en un objeto cuya referencia se guarda en una variable privada de la clase "Usuarios" conque contamos en Loturak. ¡Muchas gracias a todos otra vez, de no haber sido por vosotros seguramente no hubiera hecho nada y tendría a Ro... al puñetero diciéndome que qué pasa, que si no sé programar o qué!

[*Emilio*]

Hola dec,

Pues no se que decirte, a mi gusto a quedado extremadamente farragoso, me gustan las cosas simples, sencillas y funcionar seguro que funciona, llegar a Roma seguro que has llegado, pero no comprendo que te ofrece para enmarañarlo tanto.

Ojo, es sólo una opinión que intenta ser constructiva, seguro que me lo explicas y hasta me convences, pero es que no lo veo claro por mi mismo.

[dec]

Hola,

Ya he afinado un poquitín más el asunto y he actualizado el archivo Zip que contiene la última versión del código fuente de Loturak, por si queréis echar un vistazo, lo digo.

En cuanto a lo que dices Emilio, me queda la duda de no haber utilizado (siempre se está a tiempo) una Cookie, pero, desde luego, no creo que el tema haya quedado farragoso.

Fíjate. ¿Qué ha sido necesario hacer? Crear una tabla en la base de datos de nombre Opciones, con tres campos, el ID de las opciones, el ID del usuario de estas, y el propio campo que contiene las opciones.

Ahora bien. ¿Ha sido necesario hacer algo más en la base de datos? No. ¿Hemos tenido que añadir algo a la tabla Opciones para que la cosa funcione? No. ¿Los usuarios notarán algo raro mientras no cambien sus opciones? No.

¿Básicamente qué es lo que hacemos? Hemos escrito una clase Opciones para tratar con estas en la base de datos de una forma más o menos sencilla... y la hemos escrito en un momento, como aquél que dice, y sabemos ya que puede ampliarse... que abre posibilidades...

De acuerdo, pero, ¿realmente es complicado acceder a las opciones, determinar qué camino a seguir en función de estas, qué es lo que nos cuesta averiguar la información que nos ofrece una opción? Veamos la única que existe ahora mismo, ¿cómo la utilizamos?

Código PHP:

if($usuario->opciones->Leer(APP_OPC_FORZAR_DESCRIPCION, '0') == '0')
{
  // No forzar la descripción del enlace
}
else
{
  // Forzar la descripción del enlace
} 


No parece muy complicado. Se busca una opción, se ofrece un valor "por defecto" en caso de que no exista la opción y obramos en consecuencia.

Pero, ¿Y qué hacemos para actualizar las opciones? Veámoslo:

Código PHP:

$usuario->opciones->Escribir(APP_OPC_FORZAR_DESCRIPCION, 1);
$usuario->opciones->Actualizar(); 


Es decir, se escribe el valor de las opciones que sean menester y se actualizan en consecuencia. No he querido "actualizar" en el propio método "Escribir", precisamente, para poder guardar varias opciones de un golpe, y, sobre todo, para no tener que hacerlo una a una...

Ahora bien, ¿dónde ves la complicación en todo esto Emilio? Estoy dispuesto a rectificar si encuentro que lo que hasta ahora hay hecho sirve, por supuesto.

Al contrario, yo creo que la cosa ha quedado tan sencilla que escama un poco... que seguro que se están dejando cabos sueltos, pero, la opción añadida actualmente está cumpliendo, y, al menos similares a esa, estamos ya seguros de poder añadir más si nos es preciso, y con relativa sencillez.

[roman]

La verdad que yo tampoco entendo el pero Emilio. Lo que ha hecho dec aquí es sencillo y servirá para guardar las opciones del usuario. Cierto que si sólo se tratase de una opción pues sería mucho hacer pero es claro que dec lo está pensando para más cosas.

Por otra parte, tanto puñetar empieza a mosquearme. No sé en España como sea la costumbre, pero llamarme puñetero tantas veces empieza a incomodarme. Confío en que sólo sea una diferencia de costumbres.

// Saludos

[*Emilio*]

Empezado por dec

Ahora bien, ¿dónde ves la complicación en todo esto Emilio? Estoy dispuesto a rectificar si encuentro que lo que hasta ahora hay hecho sirve, por supuesto.

Mi estimado dec, creo que en esta ocasión el que debe rectificar soy yo, después de atender con detalle al código, veo cuales son las intenciones que no he visto inicialmente y de ahí mi anterior opinión, lo cierto es que incluso debo decir que ahora hasta me gusta y posiblemente te lo pinche para alguna que otra cosa que tengo entre manos

Eso si, a ese código le falta la función resultados() que en ella debes hacer la consulta, pero bueno eso no es imprescindible, se sobreentiende.

[*Emilio*]

Empezado por roman

Por otra parte, tanto puñetar empieza a mosquearme. No sé en España como sea la costumbre, pero llamarme puñetero tantas veces empieza a incomodarme. Confío en que sólo sea una diferencia de costumbres.

Bueno aquí incluso se toma como alago que te llamen cabronazo, hijo de la gran pu... y cosas así ¿eso no se estila por ahí?

[dec]

Hola,

Román, lo cierto es que el diccionario no hace esta vez una correcta descripción de la que es al menos una de las acepciones de las palabra puñetero. En mi tierra se dice cariñosamente, claro que vuelve a pasar lo mismo otra vez: dicho, o sea, de viva voz, suena de distinto modo, porque ahí está el quid, en el tono que se le dé a la palabra. Pasa con otras como cabrón, que no es necesariamente un insulto, puede incluso ser todo lo contrario. Pero, supongo que el lenguaje escrito no permite todas las posibilidades del lenguaje hablado. Permite otras, claro.

Empezado por Emilio

Mi estimado dec, creo que en esta ocasión el que debe rectificar soy yo, después de atender con detalle al código, veo cuales son las intenciones que no he visto inicialmente y de ahí mi anterior opinión, lo cierto es que incluso debo decir que ahora hasta me gusta y posiblemente te lo pinche para alguna que otra cosa que tengo entre manos

Bueno. Desde luego la cosa es muy mejorable, de eso no me cabe duda. Por ejemplo, acabo de actualizar el código fuente de Loturak, porque estaba haciendo dos consultas a la base de datos para lo mismo. La clase Opciones ha cambiado también algo de lo que se puede ver arriba, aunque, básicamente, es lo que se ha comentado ya.

Empezado por Emilio

Eso si, a ese código le falta la función resultados() que en ella debes hacer la consulta, pero bueno eso no es imprescindible, se sobreentiende.

Bueno. Ahora mismo nos valemos de la clase "BDatos" de Loturak para traer las opciones de la base de datos, pero, muy probablemente termine escribiendo un método en la clase "BDatos" a partir del cual la clase "Opciones" pueda hacerse con estas.

En realidad el resultado sería el mismo: lo único que cambiaría (que se me ocurra, y que además pretendemos y tratamos de seguir como norma) es que se dejaría la consulta SQL en la clase BDatos, junto al resto de consultas que se hacen, de manera que en caso de necesitar modificar la misma se sabría de antemano a dónde acudir.

Al comenzar Loturak la clase BDatos era cierta clase que escribí (en realidad casi copié, pero, adrede, para tratar de comprender su funcionamiento) hace ya tiempo (con ayuda de no poca gente, Román, por ejemplo, colaboró en ello). Pero en Loturak contamos con una clase que extiende esta BDatos, y que es la que aporta métodos que, fundamentalmente, hacen consultas a la base de datos. Es por eso, por tenerlo ahí, a mano, como aquel que dice, y no una consulta aquí, otra allí, otra acullá, etc.

Pero, creo que me enrrollo... joroba... ¡sí, me estoy enrrollando! Me gustaría encontrar un fragmento de cierto capítulo de Don Quijote de la Mancha en donde se explica porqué utilizar el término hijo de puta y llamárselo a alguien no tiene que ser un insulto... no recuerdo exactamente qué capítulo era, pero, como todos los del Quijote, es estupendo.

Podría acaso buscarse por Internet, puesto que el Quijote está digitalizado y probablemente el término "hideputa" o "hijo de puta" no aparezca demasiado (eso creo recordar). En fin, lo dejo ya, que ya está bien, qué pesao.

[roman]

Ta bueno pues.

En cuanto a la clase bdatos, desconozco yo el uso exacto que le das, pero visto así desde lejos y a juzgar por su nombre, a mi me da que tal como tienes tu clase Opciones está muy bien. Esto es, tienes una clase bdatos que- estoy suponiendo-centraliza el acceso a la base de datos, lo cual está muy bien, pero no hagas de esta clase un dios que hace todo. Otras clases de tu aplicación, como Opciones hacen uso de ella en lugar de dejarle todo el trabajo a una sólo clase.

Vamos, en resumen, que a mi me parece bien tal como la tienes.

// Saludos puñetero

[dec]

Hola,

Capítulo XIII de la segunda parte del Quijote. Léase.

Y, por cierto,... ha sido leer un poco del texto para acordarme de que sí, en el Quijote se utiliza "hijo de puta" en más de una ocasión y más de dos...

[[seoane]]

Empezado por dec

Pero, creo que me enrrollo... joroba... ¡sí, me estoy enrrollando! Me gustaría encontrar un fragmento de cierto capítulo de Don Quijote de la Mancha en donde se explica porqué utilizar el término hijo de puta y llamárselo a alguien no tiene que ser un insulto... no recuerdo exactamente qué capítulo era, pero, como todos los del Quijote, es estupendo.

Podría acaso buscarse por Internet, puesto que el Quijote está digitalizado y probablemente el término "hideputa" o "hijo de puta" no aparezca demasiado (eso creo recordar). En fin, lo dejo ya, que ya está bien, qué pesao.

Ya te busco yo el fragmento:

A lo que respondió Sancho, algo mohíno:

-Ni ella es puta, ni lo fue su madre, ni lo será ninguna de las dos, Dios quiriendo, mientras yo viviere. Y háblese más comedidamente, que, para haberse criado vuesa merced entre caballeros andantes, que son la mesma cortesía, no me parecen muy concertadas esas palabras.

-¡Oh, qué mal se le entiende a vuesa merced -replicó el del Bosque- de achaque de alabanzas, señor escudero! ¿Cómo y no sabe que cuando algún caballero da una buena lanzada al toro en la plaza, o cuando alguna persona hace alguna cosa bien hecha, suele decir el vulgo: "¡Oh hideputa, puto, y qué bien que lo ha hecho!?" Y aquello que parece vituperio, en aquel término, es alabanza notable; y renegad vos, señor, de los hijos o hijas que no hacen obras que merezcan se les den a sus padres loores semejantes.

-Sí reniego -respondió Sancho-, y dese modo y por esa misma razón podía echar vuestra merced a mí y hijos y a mi mujer toda una putería encima [...]

[dec]

Hola,

Sí; de hecho dudo en añadir un método (y seguramente más de uno sería necesario) en la clase BDatos, puesto que la clase Opciones está ahora bastante clara y limpia, y tampco estorban ahí las consultas SQL.

Empero, los métodos principales relacionados con la base de datos de la aplicación: realizar la conexión, la selección de la base de datos, ejecutar consultas de varias maneras... todo eso lo hace la clase BDatos,... que en realidad no se ha tocado en Loturak, es decir, que puede usarse en otra aplicación sin problemas (en principio) y de hecho yo la he utilizado en alguna otra aplicación o pruebas.

Ahora, lo que existe en Loturak es una clase que extiende (que hereda) de la clase BDatos "principal". Es en esta clase hija en donde se acumulan métodos como "NumEnlacesPublicos", "NumEnlacesPrivados", "EnlaceUsuario", etc., etc., etc., que, básicamente, puede decirse que conforman las consultas SQL. No se ejecutan, sólo se conforman, porque de la ejecución de las consultas, entre otras cosas, se encarga la clase padre de esta.

¿Entonces cuál es la intención de extender la clase BDatos? Pues, básicamente (y es posible que de forma equivocada) se hace para tener en un solo lugar la conformación de consultas SQL. Esto no se consigue del todo, hay sitios en la aplicación en donde se hacen consultas SQL (siempre a través de la clase BDatos), pero, la gran mayoría (y como norma general) se hacen en la clase BDatos, no en "cualquier sitio".

Ocurre un poco lo mismo con la clase Xhtml, que "encapsula" (es mucho decir) la salida del código XHTML de la apliación. En algunos sitios se genera código de salida, pero, prácticamente todo el código XHTML de salida está en la clase Xhtml, de manera que es algo más sencillo de "localizar", editar, etc. Al menos así lo estoy viendo yo de momento... porque está el problema del tamaño de los archivos... la clase BDatos no me preocupa, pero, la clase Xhtml, incluso luego de varios repasos, ocupa ya unos 130 KB.

Sin embargo, no noto problemas en eso (de momento) y todavía es posible darle más de un repaso y más de dos...

[dec]

Hola,

Empezado por Seoane

Ya te busco yo el fragmento

Muchas gracias Seoane. Unos párrafos más adelante de lo que has referido Seaoane, viene a caer Sancho en la verdad de que hijo de puta no es siempre un término ofensivo:

(...)

-Por mi fe, hermano -replicó el del Bosque-, que yo no tengo hecho el estómago a tagarninas, ni a piruétanos, ni a raíces de los montes. Allá se lo hayan con sus opiniones y leyes caballerescas nuestros amos, y coman lo que ellos mandaren. Fiambreras traigo, y esta bota colgando del arzón de la silla, por sí o por no; y es tan devota mía y quiérola tanto, que pocos ratos se pasan sin que la dé mil besos y mil abrazos.

Y, diciendo esto, se la puso en las manos a Sancho, el cual, empinándola, puesta a la boca, estuvo mirando las estrellas un cuarto de hora, y, en acabando de beber, dejó caer la cabeza a un lado, y, dando un gran suspiro, dijo:

-¡Oh hideputa bellaco, y cómo es católico!

-¿Veis ahí -dijo el del Bosque, en oyendo el hideputa de Sancho-, cómo habéis alabado este vino llamándole hideputa?

-Digo -respondió Sancho-, que confieso que conozco que no es deshonra llamar hijo de puta a nadie, cuando cae debajo del entendimiento de alabarle. Pero dígame, señor, por el siglo de lo que más quiere: ¿este vino es de Ciudad Real?

-¡Bravo mojón! -respondió el del Bosque-. En verdad que no es de otra parte, y que tiene algunos años de ancianidad.

(...)

Véase el lenguaje de Cervantes (aunque traído al castellano "moderno"), pero, véase la maestría, la elegancia, la sencillez, la enjundia, el conocimiento, la cultura, lo que este hombre es capaz de decir en lo que escribe... ¡si no habéis leído el Quijote no dejéis de hacerlo cuando podáis, os aseguro risas, buenos ratos, sabiduría! ¡Y pongo las manos en el fuego por ello! No puede haber ser humano al que el Cervantes (no ya el Quijote) deje indiferente. Yo no sé cómo encarecerlo como se debe.

[roman]

Empezado por dec

Ocurre un poco lo mismo con la clase Xhtml, que "encapsula" (es mucho decir) la salida del código XHTML de la apliación. En algunos sitios se genera código de salida, pero, prácticamente todo el código XHTML de salida está en la clase Xhtml, de manera que es algo más sencillo de "localizar", editar, etc. Al menos así lo estoy viendo yo de momento... porque está el problema del tamaño de los archivos... la clase BDatos no me preocupa, pero, la clase Xhtml, incluso luego de varios repasos, ocupa ya unos 130 KB.

La clase BDatos no te preocupa ahora y posiblemente funcione bien en esta aplicación. Pero sí es de pensarse qué pasa cuando toda una clase muy grande debe cargarse para cualquier mínima cosa. Esto realmente es pregunta. Es que hasta para la página más pequeñita, tu clase xhtml carga todo. Y aunque en esta aplicación BDatos no tiene tanta demanda, la naturaleza de la cuestión es la misma que en la clase xhtml.

No sé, no sé. Sería bueno saber

// Saludos

[dec]

Hola,

Empezado por Román

Esto realmente es pregunta. Es que hasta para la página más pequeñita, tu clase xhtml carga todo (...)

Sobre eso diré que yo también me he preguntado algunas cosas y he estado a punto de comentarlo en los Foros, y, en fin, acaso ahora toca hacerlo.

En primer lugar no se me escapa que ciertas páginas, digamos, más o menos estáticas, podrían prescindir de la clase Xhtml, o, fuera como fuera, no necesitarían de métodos en esta clase, sino que, simplemente, cada página incluiría su código XHTML correspondiente (además del "general", que sí añadiría, por ejemplo, las cabeceras de las páginas, o el pie de estas). Puede hacerse, se ha pensado y no se descarta.

Peeeeeeeeeeeero... Lo cierto es que dudo que PHP carge los 130 KB del archivo de la clase Xhtml. Lo pongo en duda... ¡porque la carga de la página es bastante rápida, y, si tuviera que cargar los 130 de la clase Xhtml, los 30 de la clase BdatosEx, los 25 de la clase Login, los... tardaría mucho más de lo que tarda, fijo. Además nos hemos animado a echar para adelante (por lo menos hasta que no veamos que la cosa no escala, que no es posible seguir así) porque hemos visto clases en PHP de 300 KB...

Pero, sobre todo, porque los hechos contradicen a los números. Ya lo he dicho, si se "carga todo" la página tendría que ocupar unos 250 KB (no quiero exagerar) y, sin embargo, Loturak carga bastante rápido, desde luego, no cargaría así si tuviera que cargar con 250 KB... y lo dice alguien que cuenta con una conexión vía módem de 56 kbs y que notaría esos KB de qué manera...

¿Entonces? Pues no sé... no llego a tanto... es lo que quería preguntar, ¿cómo se las ingenia PHP? No lo sé, pero, desde luego, se las ingenia. No sé. Debe haber algo parecido al caché de los navegadores, o a lo que hace Apache (que no sirve páginas si no han cambiado desde la última vez), me parece, o MySQL, que no actualiza un registro (aunque se lo digas) si esto es innecesario, porque los datos del mismo son iguales... o al compilador JIT (Just in time) de .NET, que compila el código la primera vez que es necesario, pero, luego ya no hace sino ejecutar el código previamente compilado...

Mecanismos de optimización que van más allá de mi conocimiento, pero, que, deben existir, pues de lo contrario se vería enseguida, se notaría la diferencia y bastante además, ya digo.

Pensad en que la clase Xhtml no va sola... que se apoya en otra clases (de algún modo) y antes de su declaración puede verse:

Código PHP:

<?php

require(DIR_LIBS.'captcha.class.php');
require(DIR_LIBS.'filtros.class.php');
require(DIR_LIBS.'servidor.class.php');
require(DIR_LIBS.'etiquetas.class.php');
require(DIR_LIBS.'validarex.class.php');
require(DIR_LIBS.'compresion.class.php');
require(DIR_LIBS.'administrar.class.php');

class XHtml
{ 

  /* ... */

Estas clases son mucho menos pesadas (del orden de 10 KB ó menos), pero, lo cierto es que ahí están... y, como digo, Loturak no carga "lenta" ni noto "en local" un excesivo consumo de recursos o algo parecido... ¡qué sé yo! Alguien tiene que explicarnos esto.

Edito: Me doy cuenta ahora de que acaso he mezclado churras con merinas en parte de lo que he dicho, pero, no voy a buscarle las vueltas, porque, me parece que se entiende lo que más o menos quiero explicar. Ea. ¡Saludos!

[roman]

Claro que en mucho dependerá lo que se desee hacer. Ciertamente hay clases por ahí tremendamente grandes pero también sé de varias de ellas que a la larga han tenido que refactorizar y dividirse en partes. Ahora, ciertamente quizá me "asusto" sin razón pero el caso es que alguna vez pregunté algo relacionado con la velocidad en MaestrosDelWeb y nadie pareció saber la respuesta. No al menos para el ambiente que tenían en mente y que era uno de accesos de entre 600 y 800 personas simultaneas (real). En ese entonces quería probar con un sistema de plantillas, no smarty que me parece conceptualmente estúpido, sino con algún otro. Pero me entró el temor de que tantos accesos simultáneos cargando cada uno clases de cientos o miles de líneas, no dieran el ancho, y como no podía darme el lujo de experimentar y que fallara, pues aun no lo he probado.

En fin, claro que cabe la posibilidad de que esté mal informado y que php (y apache y el servidor) puedan manejar muchos elefantes simultáneos, pero la realidad es que no lo sé.

Ahora bien, dejando de lado las consideraciones de eficiencia, también me pregunto yo sí a la larga no resulta difícil de manejar y entender una clase tan amplia.

// Saludos

[dec]

Hola,

Empezado por Román

Ahora bien, dejando de lado las consideraciones de eficiencia, también me pregunto yo sí a la larga no resulta difícil de manejar y entender una clase tan amplia.

Bueno. Es probable que eso ocurra, pero, en el caso de las clases de Loturak de que venimos hablando, hay que tener en cuenta la idiosincracia de las mismas.

La clase Xhtml, que es la más "pesada", en realidad ni siquiera llega a instanciarse (lo que puede tener que ver con lo que estamos hablando: acaso de instanciarse otro gallo cantaría), pero, únicamente cuenta con métodos estáticos.

Es una manera de "encapsular", de "tener a buen recuado" las funciones que tratan con el código XHTML de la aplicación, es por comodidad, básicamente, pero, ya digo: no es compleja, porque no tiene más que métodos (funciones) listas para utilizar.

Estaría bien que alguien que supiera nos contara un tanto sobre todo esto. Resulta interesante.