|
Opciones personalizables para los usuarios de una aplicación Web: posibles soluciones
Hola,
¿Cómo va eso? ¿Y la vuelta al cole, bien? ¿Y el Madrid, otra vez campeón de Europa? ¿Eh? Bueno. Parabienes para todos. ;) A ver si podéis echarme una mano con mi "problema". Lo entrecomillo porque es más bien una duda, o varias, pero, ni corre prisa, ni es algo que esté causando ningún inconveniente. Veréis. En Loturak, ya sabéis, esa Web a la que un Spammer se está refiriendo descaradamente en estos Foros (como le descubramos se va a enterar el pendejo), en Loturak, digo, estamos tratando de desarrollar lo que haga falta para que los usuarios puedan establecer determinadas "opciones" para el uso del sitio Web. Ahora mismo el usuario ya puede cambiar una serie de datos, pero, el tema está en darle la posibilidad de establecer "verdaderas opciones" de la aplicación y no sólo sus propios datos de usuario. Por ejemplo, algunos ya sabéis que Loturak muestra listados de enlaces a páginas Web, básicamente. Estos enlaces cuentan con una descripción, aunque no es obligatoria. Y esta descripción, por defecto, no aparece en el listado de enlaces: hay que hacer clic en una "lupa" para mostrarla. Pues bien, de lo que se trataría es de dar la posibilidad al usuario de poder establecer si quiere que la descripción de los enlaces aparezca "visible" desde un principio o no, que aparezca como ahora, "oculta" hasta que se quiere echar un vistazo. Eso sería un ejemplo de "opción de usuario", obviamente habría más, y de ahí el comerse un poco el coco para montar algo que escale, esto es, que se puedan añadir tantas opciones como sea preciso sin problemas. Ahora bien, mi cabecita no da para mucho, como se podrá apreciar. He pensado en añadir una tabla a la base de datos de Loturak y ahí guardar las opciones de los usuarios, peeeeeeeeeeeeeeeeeero... siempre hay un pero, sobre todo si no se tiene mucha idea de lo que uno está haciendo, si se es un novato, prácticamente. La table que mi mente privilegiada es capaz de imaginar podría estar formada por los siguientes campos: Tabla Opciones. Campos: opciones_id opciones_id_usuario opciones_clave opciones_valor Creo que no es importante, para lo que nos ocupa, especificar el tipo de estos campos, etc. El inconveniente que le veo a la tabla anterior podría resumirse en que aunque por un lado le veo todo el sentido del mundo, por el otro intuyo que ni es la mejor solución, ni siquiera una solución mínimamente aceptable. Supongamos que el usuario tiene la posibilidad de escoger 20 opciones en la aplicación. Supongamos que hay 1000 usuarios registrados (que no llegará Loturak a eso, probablemente, pero, estamos suponiendo nada más). 20 opciones por 1000 usuarios son 20.000 mil registros en la tabla Opciones, tal y como yo soy capaz de plantearlo... y me parece que algo en mi planteamiento está rematadamente mal. Otra cosa que se me ocurre al Hilo de esto es si alguna vez se me ocurre que necesito guardar en la base de datos las opciones de la propia aplicación, no ya de los usuarios. Por ejemplo, ahora se establecen una serie de constantes que son las que determinan algunos aspectos de la aplicación, pero, si llegáramos a ampliar el pobre apartado de "administración" conque cuenta Loturak... una de las gracias estaría en poder establecer opciones de la propia aplicación... A mí se me mete en la cabeza que opciones son opciones, ora del usuario, ora de la aplicación, pero, que ambas cosas son opciones y deberían ir por tanto en la misma tabla Opciones... pero,... como que tampoco lo veo claro... Mi "modelo" para esto último, es decir, sólo para las opciones de la aplicación, podría ser el Gestor de contenidos WordPress que, efectivamente, cuenta con una tabla "Opciones" y no sólo guarda en ella las suyas, pero, permite a los desarrolladores de Plugins hacer lo propio: crear opciones, escribirlas, leerlas, en fin. O sea, de tratarse únicamente de guardar las opciones de la aplicación creo que más o menos estaría claro, podría seguirse el ejemplo de WordPress y la cosa mejor o peor funcionaría, pero, ¿qué pasa con las opciones de los usuarios? ¿Cómo se os ocurre a vosotros que podrían tratarse? ¿Acaso está demás utilizar la base de datos para esto y bastaría con "Cookies", por ejemplo? ¿Para veinte o más opciones? ¿Cómo lo véis vosotros? Cualquier cosa que se os ocurra será bienvenida y agradecida. Saludos para todos y perdonar el pedazo de rollo que os acabo de soltar, que podría haberse resumido en pocas líneas, estoy seguro, peeeeeeeeeeero... siempre hay un pero. :eek: Gracias de verdad a todos de antemano. :) |
Para las opciones de la aplicación si es bueno la tabla opciones, con los campos clave y valor.
Para las opciones de los usuarios, podrían darse dos situaciones... Una tabla parecida a la de opciones de la aplicación, con un identificador al usuario (siguiendo tu ejemplo id_usuario). Ahora, leo que tu preocupación aquí es el número de opciones que pueden existir para un usuario y el número de registros que podría haber por usuario. Una posible solución sería solo guardar las opciones que el usuario cambie, o sea, si el usuario sigue usando el valor predeterminado de determinada opción, que este no se guarde, que se tome directamente de algun otro lado. La ventaja aquí sería la facilidad de agregar opciones nuevas. La otra, una tabla con tantos campos como opciones tenga el usuario, la desventaja de esta posibilidad sería que al agregar una opcion nueva, tendrías que agregar un campo nuevo. La ventaja, cada usuario solo usaría solo un registro. Espero que te sirvan de algo mis comentarios... Saludos... |
¿Cuánto podría ocupar una opción? ¿1 byte? Digo, esto da opción a 256 valores para cada opción. Ok. Decíamos que había ¿cuantos? ¿mil usuarios por 20 opciones? En total 20,000 bytes. Guau, suena mucho. Pero, esperen un momento, eso son 20 kilobytes. En mi opinión eso no es nada.
// Saludos |
Tal vez no le preocupa el espacio que ocupen, si no el volumen de información... digo, tal vez... :p
Saludos... |
O quizá la cantidad de datos :p
|
Hola,
Gracias por vuestros comentarios. Por supuesto que son útiles. Sí; una posible solución podría estar en una tabla (para las opciones de los usuarios) que contuviese tantos campos como opciones, a costa de que añadir una opción significaría añadir un nuevo campo a dicha tabla. Bueno. Desde luego es algo que puede hacerse. Tampoco creo que las opciones crecieran como setas. Por otro lado, atendiendo a lo que dice Román, pues, hombre, ocupar, lo que se dice ocupar, la mayoría de las opciones serían "booleanas", aunque el campo de la base de datos podría consistir en una enumeración cuyo rango estuviera entre 0 y 1. Es cierto que no parecen exagerados 20 KB para 20.000 opciones, puesto que hablamos de 1000 usuarios y Loturak crece a usuario por semana y somos ahora 85.... Las opciones en WordPress, la tabla de opciones en este gestor de contenidos, y, más concretamente, el campo que almacena el valor de dichas opciones es de tipo "longtext"... quiere decirse que no se trata de guardar un valor booleano, sino que pueden ir y de hecho van más allá (yo mismo escribí un Plugin para este sistema que guardaba en una opción varias líneas de texto sin problema alguno). Tal vez una posible solución fuera considerar la posibilidad de separar las opciones de la aplicación y las opciones de los ususarios. Y que estas últimas fueran opciones "siempre" booleanas, de manera que el tamaño de la tabla de opciones no se fuera de madre. Podría ser, pero, no sé porqué (seguramente mi ignorancia y no otra cosa) no termino de verlo más o menos claro... |
Lo más sano, desde mi punto de vista, sería tener las opciones de la aplicación y las de los usuarios por separado...
Y podrías probar con solo guardar en la tabla las opciones que no contengan el valor predeterminado. Esto es, cuando un usuario hace login, se inicializan las opciones del usuario con los valores predeterminados, acto seguido, lees de la tabla de opciones del usuario las opciones que haya modificado y asignas sus valores a las opciones correspondientes... No se que te parezca... Saludos... |
Hola,
Lo que parece claro es que si se quiere conseguir algo que escale y merezca la pena no va a ser moco de pavo, puesto que, por ejemplo, está el tema de consultar las opciones de un usuario, leerlas, escribirlas, actualizarlas, añadirlas,... Se me ocurre emplear una clase Opciones que se encarge más o menos de todo esto, pero, desde luego, no creo que sea cuestión de ir añadiendo variables (propiedades) a esta clase por cada opción disponible, desde luego... Pienso en una clase opciones con un "Array asociativo" que guardara las claves y los valores de las opciones, las cuales podrían cargarse al inicio de la sesión del usuario, y no volver a consultarse en la base de datos nunca más, a lo menos para "leer" dichos valores. Esta clase habría de contar con métodos de escritura, lectura, actualización de opciones... ¡qué fregao, madre! Sin embargo, lo que más preocupa es el tema de la base de datos, de la posible tabla para las opciones... Bueno. Gracias otra vez por vuestros comentarios, ¿eh? Siempre es bueno conocer la opinión de otros, puesto que quedarse con la de uno es posiblemente la mejor manera de ejecutar el salto del ángel en el pozo del error. Así que gracias otra vez. :) |
Creo que estás invirtiendo algo, dices que si tienes 1.000 usuarios con 20 opciones por usuario serán 20.000 registros, cosa que no me cuadra, entiendo que tendrás 1.000 registros en una tabla de 20 campos, por otra parte no veo problema en el tamaño incluso hablando de muchos miles de registros, si quieres ahorrar espacio en tus tablas no olvides hacer uso de VARCHAR en lugar de CHAR para tus campos string.
En cuanto al tema de guardar las opciones del usuario, ya sabes, se trata de hacer una combinación entre cookies, session y los datos guardados en tu base de datos, creo que no tienes dudas sobre esto, si las tienes dilo y le pegamos un repaso a ver que sacamos en limpio. PD: Por supuesto la sesión en una clase, me gusta más así, pero para gustos.... |
Hola,
Cita:
Cita:
De este modo, al crearse el objeto Usuario (que se crea al comienzo de la aplicación) podría aprovecharse para crear a su vez la instancia de la clase Opciones, y que esta se encargara ya de cargar las opciones del usuario en cuestión. Ahora bien, tener opciones por defecto implica tener una lista de opciones predeterminada (¿O me equivoco?). Pero, ahora que lo pienso... tal vez es que no haya otra... no sé... la verdad es que contra más lo pienso me aparecen como posibles caminos a seguir, pero, enseguida encuentro algún obstáculo que me dice párate, no sigas por aquí, párate y mira esto... Por ejemplo, ¿cómo se llevaría a cabo la inicialización de opciones? ¿Qué haría la clase Opcinoes en su inicialización? ¿Consultar la base de datos en busca de posibles opciones y guardarlas en el Array asociativo correspondiente para luego poder trabajar con estas? ¿Acaso debería la misma clase Opciones establecer una serie de opciones por defecto, de entrada, sin ni siquiera consultar a la base de datos? ¿Pero entonces para qué el Array asociativo? ¿Para otras opciones que no fueran las predeterminadas? Pero he ahí otro problema (creo) y es que todas las opciones necesitan ser inicializadas al menos la primera vez que se piensen utilizar... digo yo, vamos... y me temo que al cabo habría que ir añadiendo y añadiendo opciones en la inicialización de la clase ídem... No sé... disculpad que discurra de esta manera,... es lo que digo, habrá que darle vueltas a esto para no estar horas en realidad perdiendo el tiempo... no es que me importe, pero, tal vez sea bueno darle vueltas antes de escribir siquiera la primera línea de código. |
En lo de separar las opciones de la aplicación de las de los usuarios, quizá sea útil revisar qué hace vBulletin. Hay opciones como el número de mensajes por página que pueden establecerse a "Predeterminado del foro". Supongo entonces que cada foro puede asignársele un valor y esto se guardará en la base de datos, supongo. Esta es una opción de la aplicación pero que también puede ser del usuario. En fin, quizá pueda dar alguna idea.
// Saludos |
Hola,
Cita:
Pero, lo de tener 20.000 registros en una tabla no es que me pánico ni nada de eso; lo que ma un poco de mal rollo es que esos 20.000 registros sean... cómo decirlo... ¿tan iguales? Lo explicaré con un ejemplo. Loturak cuenta con una tabla de nombre "Enlaces" en donde se guardan los que los usuarios quieren. Esta tabla puede crecer y crecer, pero, al fin y al cabo hablamos de enlaces, puede haber un millón (y puede haberlos repetidos, en algunos de sus datos), pero, todos tiene su URL, su título, su descripción,... no sé... lo veo como algo razonable, porque me digo, hay un millón de registros, que se corresponden a un millón de enlaces: el asunto cuadra, no puede ser de otro modo, no caben en 100 registros un millón de enlaces. Pero con las opciones no ocurriría eso, puesto que habría, digamos que veinte opciones distintas y miles y miles de registros... ¿No hay algo aquí que no está bien? Claro, por otro lado, ¿puede ser esto de otro modo? Es lo de antes, 20 opciones, 1000 usuarios: 20.000 registros... ¿pero puede ser de otro modo? Me parece que no, que si se plantea una tabla de opciones que contenga en realidad pares de claves y valores... no puede ser de otro modo... En fin. Reconozco que todo esto es demasiado nuevo para mí, y que no me he documentado (no he leído) lo suficiente sobre el tema, ¡ni muchísimo menos! Vuelvo a agradecer vuestros comentarios. Ahora mismo cada vez veo más la posibilidad de una tabla con tantos campos como opciones (claudicando un tanto en mis ambiciones de lograr algo más "abstracto") pero, básicamente, por la otra forma: los 20.000 registros de antes, no lo termino de ver nada claro... :D Cita:
|
Hola,
A ver si lo que se me acaba de ocurrir suena descabellado o no... ¿Qué tal si utilizamos la magnífica serialización de objetos que ofrece PHP? ¿Porqué no guardar, en un sólo campo de tipo "LongText" la instancia de la clase Opciones de los usuarios "serializada"? Podrían guardarse muchos pares de claves/valor. Pienso en un "Array asociativo", como antes, al que podrían añadirse tantos elementos como fuera preciso, y que podría terminar guardado en la base de datos como digo: en un solo campo, junto al resto de la clase Opciones, previamente "serializada". Rizando un poco el rizo ni siquiera haría falta tabla de opciones (para usuarios), podría añadirse a la tabla Usuarios un campo "Opciones", precisamente. (*) ¿Qué os parece? :) (*) Seguramente no; seguramente no estaría mal una tabla Opciones, salvo que, esta vez, contaría con un campo "LongText", como digo, que las almacenaría todas juntas. |
A mi me parece muy buena idea a menos que quisieras hacer búsquedas sobre las opciones de usuario, por ejemplo, ¿cuántos usuarios usan morado como color de texto sobre fonde verde? Tu clase OpcionesUsuario simplemente tendría que tener cuidado en dar valores por defecto cuando aumente opciones. Yo creo que es bastante buena la idea.
// Saludos |
1 Archivos Adjunto(s)
Hola,
Como que no la he inventado yo... je, je, je. No; quiero decir, que, recuerdo que WordPress guarda objetos serializados como opciones... claro que no hace esto únicamente, pero, a veces utiliza esta forma de guardar datos y, me he acordado de ello, seguramente. Adjunto un sencillo ejemplo... |
Cita:
1.- Comprueba si hay cookies. 2.- Comprueba que hay sesión iniciada. 2.- Si no hay ni sesión ni cookies (puede haber cookies sin sesión), entonces carga los valores por defecto. 3.- El usuario inicia session, carga datos de la BBDD a sesión y carga datos en las cookies. Y ese es básicamente el funcionamiento del que antes te hablé. |
Cita:
Cita:
Representado sería algo como esto: Código:
Id_Usuario Clave ValueCita:
Saludos... |
Hola,
Cita:
Evidentemente, a la que se añadiera el nuevo elemento habría que actualizar todas (si no se encuentra la forma de hacerlo de otro modo), digo, habría que actualizar todas las opciones, pero, en realidad hablamos de actualizar UN campo de la base de datos... Cuando el usuario iniciara de nuevo sesión, la opción añadida antes no se habría perdido, sino que se recuperaría con el resto de opciones al "deserializar" el objeto. Además pienso en la cantidad de funciones conque cuenta PHP para trabajar con Arrays... no conozco la mayoría, pero, sé que están ahí... :D |
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.
// Saludos |
Cita:
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). 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? Saludos... |
Hola,
Cita:
Cita:
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. Cita:
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:
|
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... |
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. :eek: :eek: :D :D :D |
Hay de todo en la viña del señor... :D
Pues también mucho de esto me servirá para cuando me adentre más en esto del PHP... jejeje Saludos y suerte... |
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:
|
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. |
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:
Pero, ¿Y qué hacemos para actualizar las opciones? Veámoslo: Código PHP:
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. |
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 |
Cita:
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. |
Cita:
|
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. :D Cita:
Cita:
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. :eek: :eek: :) :D |
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 |
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... :D |
Cita:
Cita:
|
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... :eek: :eek: :D :D |
Hola,
Cita:
Cita:
|
Cita:
No sé, no sé. Sería bueno saber :) // Saludos |
Hola,
Cita:
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:
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! :D |
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 |
Hola,
Cita:
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. :) |
| La franja horaria es GMT +2. Ahora son las 02:54:21. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi