¿Dónde debo de poner la información de un dropdownlist?

Hola, de antemano muchas gracias por su ayuda. me gustaría si es posible que me ayuden con lo siguiente:

Tengo una tabla llamada usuarios, y está tiene el ID_estado del usuario. Se que debería tener una tabla para almacenar los estados, pero la verdad me parece innecesario saturar la base de datos para consultar solo dos estados que nunca van a cambiar, por ello pensé simplemente hacerlo en el código.

Para ello cree el siguiente método dentro del modelo Usuarios:


public function getEstado($estado = null)

    {

        $opciones[] = 'Inactivo';

        $opciones[] = 'Activo';

        if(!is_null($estado))

        {

            if(isset($opciones[$estado]))

            {

                return $opciones[$estado];

            }

            else

            {

                return false;

            }

            

        }

        else

        {

            return $opciones;   

        }        

    }

Mi pregunta luego en la vista pongo:


use app\models\Usuarios;

<?php echo $form->field($model,'usua_estado')->dropDownList($model->getEstado()); ?>



MI pregunta es: en el MVC es correcto que ponga esa funcion dentro del modelo, o en realidad debería de ponerlo en el controlador. ¿que problemas podría tener al usarlo así? se me hace que debería crear un método en el controlador, y luego pasarle el vector de estados cuando renderice la vista. ¿sería mejor así o simplemente es igual?

Saludos

Buenas tardes.

Lo q a ti te parece innecesario es absolutamente necesario, y además tu razonamiento no tiene ni piés ni cabeza.

Una base de datos debe de seguir una estructura marcada por las reglas de diseño, como por ejemplo la integridad referencial. Si creases esa tabla d estados, ya no tendrias q codificar nada a mayores, ya q los propios modelos de yii tienen un findAll.

Por otro lado, dices q vas a sobrecargar la base de datos por una tabla de 2 columnas y 2 registros?!?!?? Déjate de historias y diseña bien tu base de datos, te ahorrarás qiebraderos de cabeza en el futuro.

Y si mañana decides meter otro estado? Tendrías q modificar el método y volver a desplegar…lo dicho, diseña bien tu db.

Si aún así deseas realizarlo como indicas, lo tienes bien codificado en el modelo de datos. Es una operación sobre el modelo por lo que debe de ir en él.

Un saludo.

Hola, gracias por tu respuesta. Vamos por partes.

  1. Está bien usarlo en el modelo y que la vista acceda directamente al modelo? pensé que para ello eran los controladores. Es decir se me hace extraño tener que llamar al modelo desde la vista para luego generar el dropdownlist. Pensé que en patrón de diseño MVC la vista nunca accedía directamente al modelo. Por eso pregunté si quizás tenía que generar la lista desde el controlador y pasarlo en un vector a la vista.(cómo una buena práctica pues haciendolo desde el modelo está calro que funciona)

2)La base de datos está bien diseñada, no siempre todo tiene que ir en tablas separadas. Sino piensa por ejemplo para que servirían los campos tipo ENUM? Has de cuenta que mi campo estado es un tipo ENUM. Si fuere cierto que siempre tenemos que usar una tabla adicional entonces ¿para que existen los campos tipo ENUM?. En cuanto a la integridad referencial creo que tienes equivocado el concepto. La integridad referencial solo se trata de que los indices, calves foráneas, y demás apunten a registros válidos, y para ello se definen las reglas relacionales. Por lo que dices creo que te estabas refiriendo a las reglas de normalización en un modelo E-R (entidad relación), y esas están bien claras… y en ninguna de ellas habla de tener que separar la información en tablas cuando no es necesario.

  1. Has trabajado en una base de datos Mysql con más de un millón de registros? yo si, y aun completamente normalizada se vuelve muyyyyy lenta sin importar en que servidor esté. Que si bien adoro MYSQL por su simplicidad y "gratuidad" nunca será tan potente como otras bases de datos. Por ello para proyectos medianos siempre suelo tratar de mitigar carga operacional de la base de datos.

Espero no me lo tomes a mal, solo soy un usuario haciendo una pregunta sobre este framework y el uso del MVC

Saludos,

Buenas de nuevo.

Para nada te lo tomo a mal, faltaría más.

1- Entonces como imprimes los datos de un CGridView o asignas los controles de un formulario a un modelo? Otra cosa es que modifiques el modelo desde la vista (ni se te ocurra, lo que harás será lanzar una acción para trabajar con los datos del modelo y te lo devolverá actualizado). De hecho, cuando haces un render por ejemplo desde la acción create le pasas la variable $model…para qué si en una vista no se puede acceder al modelo?

Sacado de la wikipedia:

"…

De manera genérica, los componentes de MVC se podrían definir como sigue:

El Modelo: Es la representación de la información con la cual el sistema opera, por lo tanto gestiona todos los accesos a dicha información, tanto consultas como actualizaciones, implementando también los privilegios de acceso que se hayan descrito en las especificaciones de la aplicación (lógica de negocio). Envía a la 'vista' aquella parte de la información que en cada momento se le solicita para que sea mostrada (típicamente a un usuario). Las peticiones de acceso o manipulación de información llegan al 'modelo' a través del 'controlador'.12


El Controlador: Responde a eventos (usualmente acciones del usuario) e invoca peticiones al 'modelo' cuando se hace alguna solicitud sobre la información (por ejemplo, editar un documento o un registro en una base de datos). También puede enviar comandos a su 'vista' asociada si se solicita un cambio en la forma en que se presenta el 'modelo' (por ejemplo, desplazamiento o scroll por un documento o por los diferentes registros de una base de datos), por tanto se podría decir que el 'controlador' hace de intermediario entre la 'vista' y el 'modelo' (véase Middleware).


La Vista: Presenta el 'modelo' (información y lógica de negocio) en un formato adecuado para interactuar (usualmente la interfaz de usuario) por tanto requiere de dicho 'modelo' la información que debe representar como salida.

"

2- Lo que me comentas de integridad referencial es exactamente lo que yo pienso que es, igual me expliqué mal. Lo que quise decir es que se deberían cumplir cos aspectos de diseño tales como Diseño DB. Accesibilidad a datos, normalización, etc… Aunque igual no es el caso de este POST.

Este enlace sobre el tipo ENUM podría darnos la razón a los 2, jeje: ENUM. De todas formas y, en mi opinión, el tipo de dato enum no debería de ser utilizado para guardar datos que en sí pueden ser consideradas como entidades propias.

Por ponerte un ejemplo:

  • El estado de un usuario puede ser perfectamente considerado una entidad propia.

  • Por otro lado, imagina que tienes un campo "observaciones" y quieres que tenga sólo 3 posibles valores. Pues le metes un ENUM.

3- La verdad es que no he utilizado bases de datos con tantos registros por lo que no he probado si tener el campo ENUM o tener una tabla aparte dá más rendimiento. Podría ser. Pero me sigue pareciendo que una tabla de este tipo no debería ser problema. Igual el rendimiento deberías buscarlo en otras entidades más complejas.

Un saludo.

En primer lugar me disucpo por mi tardanza, estuve unas semanas aprendiendo sobre el graph api de facebook y ha desviado mi atención.

En segundo lugar me alegra saber que lo has tomado muy bien. Aplaudo eso.

  1. No sé como se accede desde el gridview, de echo apenas lo estoy entendiendo porque apenas estoy aprendiendo el framework, pero segun entiendo desde el gridview también puedo llamar al modelo.

  2. Jeje si, ahí si hablamos de lo mismo

  3. Estoy de acuerdo, normalmente este tipo de campos como tipo o estado representan una entidad por si sola, y lo normal es que con el tiempo los usuarios van a querer añadir más opciones.El Enum como bien dices debería ser usado quizás para cosas que no cambien por nada, por ejemplo genero (Hombre o Mujer) y por si solo no sería una entidad

4.Para concluir, entiendo en que no hay ninguna mala practica si uso la vista para consultar información del modelo (sin pasar por el controlador).

De nuevo agradezco mucho tu ayuda y también por tomarte el tiempo por responder y buscar hasta en la Wiki para sacarnos de dudas.

Buenas de nuevo.

Todos estamos hasta arriba, o sea q de tardanza nada. Primero lo importante.

Respecto a tu punto 4, efectivamente no hay ninguna mala práctica en que consultes un objeto de un modelo en tu vista. De hecho, ése es el objetivo.Pero siempre pasando por el controlador.

Siempre tienes que pasar por el controlador ya que para cargar una vista lo haces mediante alguna acción del controlador.

Por ejemplo la acción "index" del controlador cargará la vista "index", y cuando haces el render debería pasarle el modelo con el que quieras y trabajar.

No cargues directamente tu modelo en la vista.

Sin pasar por el controlador

views/yourView.php




$model = YourModel::findOne($condition);


echo($model->yourAttribute);



Pasando por el controlador:

controllers/yourController.php




public function actionYourAction()

{

     return $this->render('yourView', [

            'model' => YourModel::findOne($condition),

        ]);

}



views/yourView.php




echo($model->yourAttribute);



Ambas opciones son válidas, pero la segunda es la correcta en cuanto a buenas prácticas se refiere. Además, cumple con el patrón MVC. La primera no cumple con el patrón MVC ya que no entra en juego ningún controlador.

Un saludo.

Hola compañeros, estoy de acuerdo en que para estas pequeñas listas no es necesario usar una tabla de la BD, aunque en "teoría pura" creo que no llevamos razón (son datos ;-), aunque seguro que es bastante más eficiente.

Yo lo que estoy usando es un helper en components que las almacena todas (estados del usuario, países (unos 20), zonas horarias, formas de pago…). La tabla solo almacena el código y el helper devuelve el texto o el array completo:


public static function status($clave=NULL) {

	$listado = array(

		-2 => 'cancelado',

		-1 => 'bloqueado',

		0 => 'pendiente',

		1 => 'confirmado',

		);

	// Si recibe clave, devuelve texto estado (ojo: 0 es valor válido):

	if ( isset($clave) ):

		return empty($listado[$clave]) ? '' : $listado[$clave]; 

	endif;

	// Si clave null devuelve array:

	return $listado;	

} // :Fin status()


Y obviamente accedo al helper directamente desde la vista, para asignar a los select.

En puridad estas listas son modelos de datos y por tanto les correspondería un modelo propio, aunque no tengan tabla.

¿Poner este método en concreto en el modelo Usuarios? Pues una solución si solo lo usa la tabla usuarios, pero creo que de la forma que yo digo se encapsulan mejor los componentes y se hacen más versátiles, para usarlos por otros modelos y otras aplicaciones. Y de paso se descongestionan de código los modelos AR.

Acceder a modelos desde la vista: no es que sea adecuado o no, es que muchas veces no hay más remedio. Ejemplo: un enlace que muestre información adicional de un registro guardado en otra tabla, no puedes tener guardada en memoria toda la tabla. Para mostrar ese registro en concreto desde la vista se accede directamente al modelo con find/findByPk y punto, lo de que pasar todas las consultas al modelo desde el controlador me parece una burrada, con perdón.

Creo que una cosa es la teoría y otra la práctica, en la que influyen muchos factores y surgen continuos dilemas y problemas, lo importante es dar con buenas soluciones en su conjunto, más o menos siguiendo los principios, pero no solo de Yii, también está el diseño, la usabilidad, funcionalidad, marketing y otras cosas.

Suelo decir que la programación web es lo más difícil que he estudiado, porque hay que tocar muchos palillos (PHP, Yii, Mysql, HTML, CSS, Bootstrap, Javascript, JQuery, Ajax, usabilidad, marketing, ufff). Con Yii solo llevo unos meses y me está gustando.

Es mi humilde opinión, espero os sirva.

Buenas Fernando.

[i]"

Acceder a modelos desde la vista: no es que sea adecuado o no, es que muchas veces no hay más remedio. Ejemplo: un enlace que muestre información adicional de un registro guardado en otra tabla, no puedes tener guardada en memoria toda la tabla. Para mostrar ese registro en concreto desde la vista se accede directamente al modelo con find/findByPk y punto, lo de que pasar todas las consultas al modelo desde el controlador me parece una burrada, con perdón.

"[/i]

Creo que no se ha comentado nada sobre esto. De hecho, no sé ni lo que significa (enviar todas las consultas???), jejejeje. Supongo que te referirás a lo que comenté sorbe pasar el modelo a la vista desde el controlador. Si te refieres a eso, la burrada es lo que dices tú ya que te estás cargando el MVC. Fíjate que en mi anterior mensaje escribo 2 ejemplos en los cuáles explico la forma de hacerlo. Y fíjate sobre todo en que no se envían todos los registros de un modelo, sino que sólo se envía 1, debido a que se está utilizando el método findOne.

[i]"…

¿Poner este método en concreto en el modelo Usuarios? Pues una solución si solo lo usa la tabla usuarios, pero creo que de la forma que yo digo se encapsulan mejor los componentes y se hacen más versátiles, para usarlos por otros modelos y otras aplicaciones. Y de paso se descongestionan de código los modelos AR.

"[/i]

Te vuelves a cargar el MVC! Si tienes un método que utilicen varios de tus modelos (o uno sólo) pero no todos, lo mejor sería crear unha clase que extienda de CActiveRecord (si sólo lo utiliza un modelo lo creas directamente en él, no necesitas otra clase), implementar el método y hacer que los modelos que necesites extiendan de esa nueva clase. De esa forma todos los modelos seguirán "extendiendo" de CActiveRecord(la clase creada tendrá todos los métodos de CActiveRecord pq extiende de ella). La idea del MVC es colocar cada cosa en su sitio (modelos, vistas y controladores). Si tienes un método que va a utilizar un modelo, lo correcto sería crearlo en el propio modelo. Esto no quiere decir que no puedan existir clases independientes, no me malinterpretes.

[i]"

Creo que una cosa es la teoría y otra la práctica, en la que influyen muchos factores y surgen continuos dilemas y problemas, lo importante es dar con buenas soluciones en su conjunto, más o menos siguiendo los principios, pero no solo de Yii, también está el diseño, la usabilidad, funcionalidad, marketing y otras cosas.

"[/i]

Totalmente de acuerdo contigo, pero la mayoría de las veces la teoría tiene razón, jejejeje.

Esto ya empieza a ser un verdadero debate teórico, jajajajaja. MOLA!!!!!!

Un saludo.

Hola compañeros!

Yo no digo que la teoría no lleve razón, digo que la práctica es muy distinta. Es considerar el modelo MVC como recomendaciones, las mejores prácticas a seguir, pero no al pie de la letra.

"Las vistas no deben acceder directamente a los modelos", es lo que defiendes y lo que dice la teoría, pero aquí un ejemplo sencillo de lo que yo digo. Por ejemplo supongamos un listado de usuarios:

1.- El controlador crea el criterio de la consulta, hace la paginación, ejecuta la consulta y se pasa a la vista, hasta aquí estaremos de acuerdo.

2.- Pero aquí la cuestión: la vista puede hacer uso de otros modelos. Imagina que tienes que rellenar 1,2,3 select (países, estados del usuario, formas de pago o lo que sea). Aquí es donde yo veo mucho más práctico que la vista acceda directamente a esos modelos, igual que la vista accede a otros componentes, widgets, helpers y demás.

O información adicional relacionada de otra tabla: yo la consulto en el bucle de impresión para el usuario en cuestión (pues en el controlador no has leído la consulta). Como es lógico no paso toda la otra tabla (a eso me refería con la burrada). Esto quizás lo solucionéis con relaciones, yo aún no he llegado ahí (estoy cambiando a tablas Innodb para eso).

¿Esto es cargarse la teoría de "las vistas no deben acceder a los modelos", o es interpretarla de manera razonable? ¿Estoy muy equivocado?

Extender un modelo porque compartan un método… no lo veo muy razonable, y no entiendo que problema hay en crear un helper independiente que rellene todas estas pequeñas listas (sin tablas) y puedan ser usados desde cualquier parte y cualquier aplicación, o si lo prefieres configúralos como modelos (en definitiva son datos).

Colocar cada cosa en su sitio… ya!!! No has dicho nada, jajaja.

Salu2.

Jeje si un buen post teórico, pero ese era el objeto. Como bien dice lagogz, las dos formas que ilustra funcionan pero solo hay una que es la correcta de acuerdo al padron MVC. (Estoy de acuerdo con tigo en que es la segunda)

No me gusta mucha la idea de usar los helpers (aunque funciona) porque deja de ser MVC, el patrón también hace que al trabajar en equipo o al momento de que otro programador retome nuestro código pueda encontrar las cosas fácilmente. y para mi si estoy hablando por ejemplo de estados de un usuario, lo mas intuitivo es buscarlo en los modelos del usuario.

En el ejemplo que ha puesto Fernando me pierdo un poco, pero es más porque no conozco muy bien el framework o el patron mvc. pero me parece bien planteada tu duda. y si al entiendo bien la pregunta concreta sería ¿que pasa con una vista que usa información de varios modelos?

No conozco la respuesta real pero supongo que tendría que pasarle todos los modelos desde el contralador que renderiza la vista, en lugar de acceder directamente a cada modelo desde cada vista. pero insisto es solo una suposición.

Por cierto lagogz, gracias por tus dos ejemplos, me han resuleto mil dudas… mil gracias.

Saludos,

Hola Luís, sí has entendido bien, es una divagación teórica sobre si todas las consultas/acceso a los modelos deben hacerse desde el controlador y pasar los datos a la vista, o si puede haber excepciones sin por eso cargarte la filosofía MVC.

Yo planteo esas dos excepciones que he mencionado:

  • Consultas desde la vista a modelos auxiliares en modo solo lectura, que solo usamos para leer, rellenar un select o un texto informativo. Con estos modelos no opera la acción, por tanto en el controlador no pintan nada, en mi opinión, solo entorpecen y ensucian el código.

  • Consultas a otras tablas que necesariamente debes hacer desde la vista, pues depende de los resultados de la consulta principal, dado que el controlador no lee la consulta, se lee en la vista para imprimirla, vamos así es como yo lo he hecho siempre, jeje. Ya sé que esto se puede solucionar con consultas más complejas y relaciones, pero no he llegado ahí.

También estaba el otro tema que planteastes: donde poner los distintos estados de un usuario o si se deben crear tablas para esos dos registros, en mi opinión ya dije que lo soluciono con un helper que recoge todo ese tipo de pequeñas listas, aunque teóricamente son modelos porque son datos.

Salu2.

Buenas de nuevo!

Yo nunca dije "Las vistas no deben acceder directamente a los modelos". De hecho, dije todo lo contrario!!!!!!!!! Y además no sé en qué documentación has leído eso. Como puse en un mensaje anterior:

"…

La Vista: Presenta el ‘modelo’ (información y lógica de negocio) en un formato adecuado para interactuar (usualmente la interfaz de usuario) por tanto requiere de dicho ‘modelo’ la información que debe representar como salida.

"

No dice nada de que no se pueda acceder al modelo, sino todo lo contario, que debe acceder al modelo.

Y efectivamente, no tiene sentido pasar un modelo de carga para una lista desplegable en una vista. Se utilizan las clases estáticas del modelo y listo. Pero sí se deben de pasar los modelos con los que se trabaja en el controlador. Eso es lo que estoy planteando.

En tu vista puedes tener una lista desplegable relacionada con un campo de tu modelo y cargarla perfectamente con los métodos estáticos del modelo que representen. Pero lo que envías mediante POST (por ejemplo) no va a ser ese modelo, sino el que tú pasas desde el controlador. Y ése sí debe ser pasado a la vista desde el controlador.

Respecto a "O información adicional relacionada de otra tabla", toda la información relacionada se puede sacar del propio modelo. Pero como comentas, si aún no has llegado al tema de relaciones… Te recomiendo que llegues cuánto antes!!!

Y respecto a "Extender un modelo porque compartan un método… no lo veo muy razonable,", se llama "herencia" y es básica en la programación orientada a objetos Concepto de herencia. En este enlace te lo explica y pq se debe utilizar. Uno de los motivos es la reutilización de código.

Si tienes bien planteado tu proyecto, no deberías de tener que añadir ninguna excepción a tu patrón MVC, a mi modo de ver vamos.

Luis, a mucha gente le cuesta coger el sistema MVC por lo q los ejemplos la verdad sí son útiles. De nada.

Un saludo.

Hola lagosz, es lo que pareces decir en estas lineas:

O sea que sí lo has escrito, y no me extrañó, porque algo así he leído en la guía de Yii, y es la filosofía del MVC, pero supongo que según el papel que hace el modelo.

Extender una clase ya se que se llama herencia, lo que digo es que no me parece correcto extender un modelo para compartir un método, sería cuestión de cada ejemplo en concreto, porque si una clase se extiende es porque comparte todas las propiedades y métodos del padre, no porque comparte un método. Ejemplo: no vas a extender la clase usuarios de la clase vehículos porque ambos puedan estar activos o inactivos o compartan una propiedad llamada país, esto es llevándolo al absurdo.

También hay otro concepto que se llama encapsular, y otro que se llama reutilización del código, para lo que están las funciones independientes, widgets, vistas auxiliares y otros componentes. En Yii soy nuevo, pero en PHP y POO no.

"Hay muchos caminos que llevan a Roma, pero solo hay uno que es el más corto".

Salu2.

Buenas de nuevo.

Esto:

No tiene nada que ver con esto (que yo nunca he escrito):

Lo que quiere decir es que el modelo de TRABAJO debe crearse/cargarse (puede ser confusión de palabras?) en el controlador y pasarse a la vista, pero de mi afirmación no sé de donde sacas que he dicho que no se puede acceder al modelo desde una vista. De hecho, ese objeto de modelo que creas en tu controlador lo utilizas en tu vista (accediendo a él por supuesto). Y para cargar una vista SIEMPRE se debe pasar por un controlador. La verdad no entiendo la confusión.

Otra cosa es cargar una lista desplegable con un modelo que no sea el de trabajo sin pasárselos desde el controlador.

No dudo de que seas un buen programador. Si esa es la impresión que te dejó mi comentario decirte que no era esa mi intención. Posiblemente sepas más que yo. Y sin problema. Pero no entiendo que tiene que ver la encapsulación aquí!!! Y la reutilización de código…es una de las razones que comento en el mensaje anterior por las que se debe utlizar la herencia. La reutilización de código no siempre está ligada a la herencia, de acuerdo, pero en este caso que estamos tratando si.

Por ponerte otro ejemplo:

  • Tenemos 3 modelos de tablas maestras, por ejemplo colores, categorías y zonas. Que no tienen nada que ver entre ellos!!!

  • Estos 3 modelos heredan de ActiveRecord (clase del núcleo de Yii). Esta clase padre tiene por ejemplo métodos tales como findOne().

  • Y por supuesto estos métodos están implementados tanto en colores, como en categorías, como en zonas.

Esto lo hace Yii, es decir, los desarrolladores de Yii han utilizado la herencia tal y como yo os comento que se debería hacer.

Según tu razonamiento esto es absurdo pq colores no tiene nada que ver con categorías?!?!?!?!?!?! No lo veo :huh:

Y para ser más claro:

  • Clase Vehículo, con la propiedad matrícula.

  • Clases Coche y Motocicleta.

  • Coche y Motocicleta van a tener matrícula, por lo que lo normal es que hereden de Vehículo.

  • Pero deben ser clases independientes porque un coche tendrá puertas pero una moto no.

Te parece absurdo que exista la clase Vehículo?!?!?!?!?!!?!?

No es que te estés cargando el MVC, te cargas directamente la POO!!!!! ;D

Y otra cosa importante sobre tu cita sobre Roma, no siempre el camino más corto es el mejor. Y sobre todo en desarollo de aplicaciones.

Un saludo.

Hola lagogz, mira, para zanjar un tema:

Tu has escrito: "No cargues directamente tu modelo en la vista. Sin pasar por el controlador".

Y yo he entendido: "No cargues directamente tu modelo en la vista. Sin pasar por el controlador".

O sea he entendido lo mismo, pero es que además no te equivocas, es lo que dice el MVC!!!

Solo es cosa de interpretarlo bien: las vistas no deben trabajar con los datos.

En conclusión: la acción actúa, opera con los datos, y la vista muestra los datos; y los datos sobre los que no se actúa se cargan directamente en la vista. La vista puede leer los datos pero nunca modificarlos (no sé si estarás de acuerdo o hay excepciones).

Sobre el tema de la herencia:

Lo que en principio parecistes plantear es que si dos modelos compartían un método uno se podía extender del otro, y yo no lo entiendo así, entiendo por herencia otra cosa, como bien expones en tus ejemplos.

Entiendo que CModel de lo que provee es de métodos de trabajo con datos, acceso a BDs y validaciones, no de los datos en sí mismos. Colores y categorias comparten que son modelos de datos, pero no tienen porqué compartir nada más, salvo que las categorías estén basadas en colores y algo más, y ya tendría sentido extenderla de colores.

Y puedes extender los modelos así en cascada, y en ese caso te felicito por tal nivel de sofisticación y por el pedazo de proyecto que te han encargado. XD.

Sinceramente estoy segurísimo de que sabes más teoría y práctica que yo. Yo soy muy artesano.

El método findOne() no lo conozco, no será find() a secas, o es de Yii 2?

Por cierto me aconsejas pasarme a Yii2? Es complicado pasar una aplicación de Yii1 a Yii2?

Sobre la cita también llevas razón: el camino más corto no tiene porqué ser el mejor, aquí sí que me he cargado todo!!!

Salu2.

Fher, no me zanjes el tema que estoy on fire!!!!!! :)

A ver, yo por "cargar" entiendo esto:




$model = new model();



Y por "acceder" esto:




echo($model->attribute1);



Por eso no entiendo la confusión. Igual me expresé mal.

Sobre esto:

Creo que queda explicado bien con el ejemplo de vehículos. Aunque por supuesto cada uno en la práctica no tiene por que seguir a rajatabla las normas de la POO, bien sea por necesidad (no se me viene a la cabeza ningún ejemplo) o por temas de trabajo personales (como que te guste esa organización o métodos de trabajo). La herencia es la herencia, no cabe lugar a interpretaciones!!!!!

Respecto a esto otro:

Gracias…supongo…es que no sé a que te refieres… :) Yo en casi todos mis proyectos creo una clase que extiende de CActiveRecord (Yii 1.x), ya que quiero que todos mis modelos realicen ciertas acciones en el envento afterSave() y afteDelete(). Por ejemplo guardar los cambios realizados en un log. De esta forma, sólo programo estos eventos una vez (herencia bendita, jajajajaja).

Sobre esto otro:

Estoy seguro de que no. Me queda mucho pero muchoooooooooooo por aprender. De hecho, lo que más me gusta de mi trabajo es que cada día aprendo algo nuevo.

Sobre esto otro:

Efectivamente es un método de los modelos de Yii2. Luis se refiere a Yii2, por eso puse ese método, pero efectivamente, el razonamiento es el mismo para Yii 1.x con por ejemplo el método find() de CActiveRecord.

Y por último:

jajajaja, estás fatal!!!!

Y a todo esto, llevamos más de 300 visitas!!!!!! Yuhuuuuu!

Un saludo.

Hola Lagosz, tranquilo que se nota que a los dos nos gusta el tema.

Lo que estás haciendo es extender un método genérico de trabajo con datos, que es de lo que proveen las clases cmodel y derivadas. Otra cosa es extender las propiedades de los objetos, con lo que creo que hay que tener más cuidado.

Solo una puntualización (y no porque hayas dicho otra cosa, eh? ;-): es correcto extender una clase B de otra A si la clase B es de la misma naturaleza y tiene las mismas propiedades que la clase A. Es decir, no porque B tenga propiedades comunes con A, sino porque las tiene todas (A es subconjunto 100% de B ), y el motivo de extenderla es para incorporarle nuevas propiedades de las que carece A. No sé si estarás 100% de acuerdo en esto.

De nuevo, lo dice la misma palabra reservada de PHP: extends, extiende, amplía.

Yo en ese tema a lo que he llegado es a extender los widgets CMenu y CLinkPager, para personalizar las propiedades y los estilos de Bootstrap y mantener más limpio el código de las vistas, y también he creado varios widgets propios, muy sencillos.

Y para llevar pocos meses con Yii creo que no ando mal, lo que más me gusta es el trabajo con modelos, la facilidad con que se validan y se accede a los datos, en lugar de las engorrosas funciones mysql_* de php. En cambio en temas de vistas no estoy usando algunos helpers como CHtml y CActiveForm.

También estudié CodeIgniter, empecé a ver Laravel… pero me planto con Yii.

Y bueno, hay tantas cosas que a mi me da la impresión de que cuanto más sabes, más te queda por saber. Aunque afortunadamente la programación web ha avanzado mucho con HTML5, estandarizando CSS y javascript, y con frameworks como Yii, JQuery, Bootstrap… Ah, y dándole matarile a Internet Explorer, auténtica pesadilla de diseñadores XXXDDD.

Venga visitas!

Un afectuoso salu2.

Buenas de nuevo.

De acuerdo. Pero es que el caso que comentamos es éste.

+1x10^1000000000000000000

Un saludo.