joder cago en dios menos mal que era una broma lo de #7247 ya me lo estaba creyendo omg
#7270 yo te digo que cuando empecé a usar este versión de hoy no me acostumbraba y que necesitaba la otra y ahora me pones la otra y como puffff
#7272 Así que tu mudanza a Barcelona, no era por trabajo externo, si no que has ayudado a crear esto eh! de ahí la defensa integra
A ver si puedo ilustrar un poco xD. No es ni de coña el controlador completo, he recortado mucho código y lo que quiero ilustrar es el cómo distribuyo la funcionalidad en mi aplicación y no cómo funciona a nivel de código.
Y un par de ejemplos rápidos:
Cada función del controlador no son tres líneas, pero podrían ser dos xD. Obviamente en cosas más complejas hay que tirar más líneas, pero vamos, creo que el concepto se ve medianamente bien.
ha sido leer php y dejar de leer.
No sé es como más mainstream todo esto, además los smileys no funcionan correctamente
Hablando del diseño nuevo de MV, hay ciertas cosas que atentan contra el principio de mínima sorpresa (es el único que conozco xD). No se, igual soy yo pero eso de que una marca de tiempo pueda ser clickable y me lleve a un post es raro RARO
#7277 Yo estaba trolleando bastante.
Pero vamos el tener algo asi bajo el capo, no me parece nada beneficioso, siempre tienes que ir a mirar el tipo de request, cuando tener una API en su sitio es posiblemente lo mejor.
Acciones de la API en un controlador y la logica de negocio en un servicio claro y ese servicio es usado por la API y los Controladores normales si han de compartir.
El identificar el tipo de contenido basado en la peticion, no se eh... como configuras un endpoint sabiendo seguro que te va a funcionar? Como son las rutas? etc.
#7283 en el SPY por ejemplo, para ir al último post puedes hacer click en la columna de "Actividad" (donde sale un avatar y el tiempo que ha pasado desde el ultimo post) y lo mismo para ir a la última página. Es lo menos intuitivo del mundo xd
#7277 Personalmente no me gusta, no sigue los standards de PSR2, me parece una clase monolitica y por lo que veo tus clases Admin_Controller tienen mas padres que una familia africana.
#7285 Más que de disenyo general es un problema de UX, además con lo que acabas de decir si ya hay una forma de realizar dicha función implementarla en varios lugares o en lugares donde no debería de estar es una mala implementación.
#7282 Ya me parecía a mí xD. A ver, siempre puedes tener una API aparte y más específica, eso está claro, pero el manejo de la petición a ese nivel (identificar el tipo de petición) no se hace en el controlador, sino en el core (MY_Controller), de manera que en un principio todas las peticiones son estáticas pero luego tengo la opción de agregar con JS la carga dinámica de vistas parciales, y luego si quiero de montar la interfaz con JS.
Las rutas son exactamente las mismas que si haces la petición a golpe de ratón como un user normal.
if($this->input->is_ajax_request()){
$render_partial = FALSE;
if(
isset($this->request_data['render_partial']) &&
$this->request_data['render_partial'] == 1
){
$render_partial = TRUE;
unset($this->request_data['render_partial']);
}
if($render_partial){
/**
* Devuelve vista parcial
*/
}else{
/**
* Devuelve JSON
*/
}
}
/**
* Devuelve vista completa
*/#7286 La verdad es que nunca me he guiado por PSR, dado que lo que hago por el momento no tiene como objetivo formar parte de proyectos colaborativos ni open-source, el día que tenga tiempo me pondré a estandarizar mi forma de picar, pero de momento, pagar facturas es la mayor de mis preocupaciones xD.
#7288 A ver no lo haces en el Controller hijo, pero lo haces en el padre no? Porque tus controllers extienden el core.
Lo de mezclar acciones que pueden devolver ajax y contenido estatico, me da urticaria.
Si tengo una vista parcial que ha de funcionar con AJAX, tiene su propia Accion en el controlador y si por una casualidad comparte logica, extraigo la parte compartida y la abstraigo para usarla en un servicio/helper
