[SOLUCIONADO] ¿Cómo construir un front-end correctamente?

[guardarmicorreo]

Esa es mi pregunta. A la hora de construir un front-end no termino de aclararme cómo hay que construirlo correctamente utilizando solamente PHP, HTML y CSS.

Creo que he entendido muy bien los modelos de arquitectura, en especial el MVC. Pero cómo mostrar la información correctamente sin que PHP y HTML terminen en una maraña de código no lo tengo del todo claro, y cómo controlar adecuadamente las acciones del usuario mediante botones, enlaces, etc. tampoco lo tengo claro. Veo muchas posibilidades, pero no termino de decantarme por una en especial.

Por ejemplo, trabajando con MVC tengo clara la parte del modelo y el controlador, pero en la vista me pierdo por no saber cómo administrar bien las acciones del usuario.

He buscado pero no he encontrado nada al respecto. Solamente algún que otro tutorial pero muy básico que no me aporta nada de lo que busco, un front-end con consistencia y fácil de mantener.

¿Alguien puede ayudarme?

[Cuervoo]

Para no mezclar código html y php tenés que usar algún motor de plantillas, o crearte uno vos. Podés usar Smarty, Twig, Haanga, hay varios.

Lo que no entiendo bien es la parte de administrar las acciones de los usuarios a que te referís.

[guardarmicorreo]

Iniciado por Cuervoo

Para no mezclar código html y php tenés que usar algún motor de plantillas, o crearte uno vos. Podés usar Smarty, Twig, Haanga, hay varios.

Lo que no entiendo bien es la parte de administrar las acciones de los usuarios a que te referís.

Muchas gracias Cuervoo! :)

Me refiero a cómo administrar correctamente las acciones del usuario mediante $_GET y $_POST.

[marlanga]

Te recomiendo que uses un MVC sencillo, para aprender, como KissMVC, TinyMVC, TinyPHP o DooPHP. Sirven para practicar el patrón MVC, e incluso son suficientes para hacer ciertas páginas que no tengan complicaciones.
Cuando necesites algo más, pásate a laravel, por ejemplo, que es un MVC de peso medio (aunque muy utilizado).
Y en el top de los MVC's pesados tenemos a symfony 2, que es el que más me gusta, y zend framework, de los creadores de PHP, codeigniter, phpcake, yii, etc... El que mejor documentación en español tiene creo que es symfony, aunque la verdad, con los otros no he gastado mucho tiempo en buscar.

Los patrones MVC suelen tener un objeto REQUEST, que hace el trabajo duro de extraer y analizar, para capturar todos los datos que pueda mandar el usuario al interactuar con la página. Y ese objeto REQUEST sólo debe usarse en el controlador.

[guardarmicorreo]

Iniciado por marlanga

Te recomiendo que uses un MVC sencillo, para aprender, como KissMVC, TinyMVC, TinyPHP o DooPHP. Sirven para practicar el patrón MVC, e incluso son suficientes para hacer ciertas páginas que no tengan complicaciones.
Cuando necesites algo más, pásate a laravel, por ejemplo, que es un MVC de peso medio (aunque muy utilizado).
Y en el top de los MVC's pesados tenemos a symfony 2, que es el que más me gusta, y zend framework, de los creadores de PHP, codeigniter, phpcake, yii, etc... El que mejor documentación en español tiene creo que es symfony, aunque la verdad, con los otros no he gastado mucho tiempo en buscar.

Los patrones MVC suelen tener un objeto REQUEST, que hace el trabajo duro de extraer y analizar, para capturar todos los datos que pueda mandar el usuario al interactuar con la página. Y ese objeto REQUEST sólo debe usarse en el controlador.

Gracias marlanga :)

De acuerdo en que utilizar MVC es correcto. Pero en mi caso no lo necesito. Solo necesito saber cómo construir correctamente la vista. Si alguien puede pasarme documentación al respecto.

Quiero hacerlo por mi mismo para aprender. Delegar en un framework sin saber hacerlo por mi mismo no lo veo una buena manera de aprender los detalles de las cosas.

[Cuervoo]

Como construir el html o como es la relación lógica entre el controlador y la vista?

[guardarmicorreo]

Iniciado por Cuervoo

Como construir el html o como es la relación lógica entre el controlador y la vista?

Cómo construir la relación lógica entre el controlador y la vista, tú lo has expresado mejor que yo :D

[marlanga]

Hasta que no sepas cómo funciona un MVC y las posibilidades que te ofrece, no podrás crear tu propio MVC. Y conocerlo sólo es posible a través de la práctica, usándo alguno. Además correrás el peligro de que durante el proceso de apredizaje, te guste, y decidas utilizar siempre ese framework. Y si no te gusta, sabrás la causa y cuando pruebes otro, o intentes programar uno, actuarás en consecuencia. Son todo ventajas.

Empezaste preguntando cómo se hace un front-end correctamente, no cómo programar tu propio framework MVC. Programar tu propio framework MVC no es hacer correctamente las cosas, porque cometerás errores intentando reinventar la rueda cien veces. Gastarás tiempo en un proyecto que puede que al final no cuaje. Sin embargo, dedicar tiempo a aprender un framework MVC te permitirá hacer cualquier tipo de página o aplicación web a un nivel decente de calidad, que es tu objetivo.

Es sólo mi consejo.

[guardarmicorreo]

Iniciado por marlanga

Hasta que no sepas cómo funciona un MVC y las posibilidades que te ofrece, no podrás crear tu propio MVC. Y conocerlo sólo es posible a través de la práctica, usándo alguno. Además correrás el peligro de que durante el proceso de apredizaje, te guste, y decidas utilizar siempre ese framework. Y si no te gusta, sabrás la causa y cuando pruebes otro, o intentes programar uno, actuarás en consecuencia. Son todo ventajas.

Empezaste preguntando cómo se hace un front-end correctamente, no cómo programar tu propio framework MVC. Programar tu propio framework MVC no es hacer correctamente las cosas, porque cometerás errores intentando reinventar la rueda cien veces. Gastarás tiempo en un proyecto que puede que al final no cuaje. Sin embargo, dedicar tiempo a aprender un framework MVC te permitirá hacer cualquier tipo de página o aplicación web a un nivel decente de calidad, que es tu objetivo.

Es sólo mi consejo.

No quiero crear mi propio MVC, quiero saber cómo se hace esa relación correctamente. No quiero crear mi propia herramienta, quiero lograr una técnica, una generalidad, una metodología para saber cómo se hace.

[marlanga]

Y quieres aprender cómo trabajan los MVC, sin usar ninguno. No entiendo.
KissMVC son prácticamente 3 ficheros, y se aprende rápido. Úsalo. Verás como en dos días, no tendrás más dudas de cómo usar el modelo, la vista y el controlador.

[guardarmicorreo]

Iniciado por marlanga

Y quieres aprender cómo trabajan los MVC, sin usar ninguno. No entiendo.

Supongo que antes de que se inventaran los frameworks MVC para PHP y HTML había alguna manera de hacer esto de manera correcta ¿no? Eso es lo que quiero aprender. Un framework no deja de ser una herramienta, detrás de esa herramienta hay una manera de organizar el código y relacionarlo que sigue una técnica o características de programación ¿cierto?, eso es lo que quiero saber.

Por que si para poder utilizar MVC con PHP y HTML siempre se remite a un framework entonces ¿Es que no hay manera de salirse de los frameworks y saber cómo funcionan las cosas y poder adquirir esa metodología para uso propio? Quiero lograr algo "casero", sencillo.

[marlanga]

¿Y qué haces aquí preguntando? Te dije que si quieres aprender, lo mejor es usar uno ligero. Pero has optado por preguntar en un foro y que sea alguien que ya conoce los frameworks mvc, el que te resuelva las dudas.
No quiero que te molestes. Te estoy haciendo un favor en insistir en que uses un MVC ligero, que además puedes ver cómo está programado. Aprenderás la filosofía de trabajo e intuirás cómo están programdos. Te darás cuenta con el paso del tiempo.

[Cuervoo]

Ah bien, ahí tenés dos formas. Una es llamar a una clase vista propia del controlador, y otra llamar directamente a la vista. Yo uso esta segunda forma. Creás un array con las variables que va a usar y se las pasás.

Un ejemplo rápido.

Código PHP:

<?php
 
//Método del controlador, esto está dentro de la clase
//Va a mostrar una lista de alumnos
function alumnos()
{
    //Este es el array que va a tener todas las variables
    //que la vista necesite
    $datos = array();
 
    //Trae una array con una lista de alumnos
    //
    //El nombre del índice "alumnos" es el nombre
    //de la variable que va a recibir la plantilla
    $datos['alumnos'] = $helper->traemeAlumnos();
 
    //Le pasamos el título que va a tener el H1,
    //solo para que quede más claro
    $datos['titulo'] = 'Lista de alumnos';
 
    //Llama a la vista
    //
    //Dentro del directorio de templates, tenemos el directorio 
    //alumnos, que tiene todos los templates
    //de la sección alumnos. Y alumnos_listar.tpl es lo que
    //vamos a mostrar ahora
    View::load('alumnos/alumnos_listar.tpl', $datos);
}
 
//Ahora el método load de la clase View, resumido
static public function load($view, $vars = false)
{
    $tpl = self::path_tpl.'/'.$view;
    
    //Si trae el array con variables las cargamos
    if (is_array($vars))
    {
        foreach ($vars as $k => $v)
        {
            //Esto es del objeto Smarty,
            //Le asigna la variable $k (alumnos, titulo) 
            //con el valor $v (el array como los alumnos, y el titulo "Lista de alumnos")
            self::plantilla->assign($k, $v);
        }
    }
 
    //La muestra, también método de la clase smarty
    self::plantilla->display($view);
}
 

Y ahora la vista, alumnos_listar.tpl, con la sintaxis de smarty

Código HTML:

<!DOCTYPE html>
<html>
<head>
    <title>Mi Web</title>
</head>
 
<body>
    <h1>{{$titulo}}</h1>
 
    <ul>
    {{foreach $alumnos as $a}}
        <li>{{$a}}</li>
    {{/foreach}}
    </ul>
</body>
 
</html>
 

Así sería muy por arriba como funciona, a eso andá agregándole todas las necesidades que tengas. Cargale layouts y que en listar_alumnos.tpl solo quede el h1 y el ul, que te retorne el tpl en caso de necesitarlo, algún booleano para tener la opción de no usar plantillas si es que no querés en algún caso específico. De ahí en adelante desarrollá a gusto.

Capaz me falta alguna cosa porque lo puse de la forma más clara posible pero, se entiende.

[guardarmicorreo]

Muchas gracias Cuervoo :D

Tengo una duda. En el último documento, donde dices "con sintaxis de smarty" utilizas {{$variable}}. Eso ¿Qué es? nunca lo había visto, ¿es propio de HTML de PHP o de qué?

[dashtrash]

Te doy mi opinión , aunque me voy a salir de MVC. Lo primero, es que una petición GET y una petición POST son cosas absolutamente distintas, cuando se usan de la forma "estandar".Una petición GET significa obtener datos del servidor. Una petición POST significa enviar datos al servidor.Eso ya te divide en 2 partes la gestión de las peticiones.

Para mí, POST significa crear un objeto "Action", que se encarga de recoger los parámetros enviados, filtrarlos, validarlos, y ejecutar la acción en el modelo, y recoger las excepciones (errores) que se hayan producido en todo el proceso. Obviamente, todo esto no lo hace 1 solo objeto, son varias capas las que hacen esto.
Los objetivos de la gestión de una petición POST son, normalmente,validación de campos a nivel sintáctico y semántico (que tengan sentido dentro de la web que estás construyendo).POST, en un alto porcentaje de los casos, se debe preocupar de gestionar 1 cierta instancia de un modelo, que es la que se está editando / ejecutando una acción sobre él.

GET, por otro lado, tiene otros objetivos completamente distintos.Normalmente, velocidad, generación de salida,cacheo...En un porcentaje bastante más alto, las peticiones GET tratan conjuntos de modelos (listados), e incluso cuando tratan a 1 solo (página de "ver"), normalmente requieren de bastantes modelos relacionados con el primero.
Ejemplo: si quieres ver 1 articulo de un foro, no necesitas solo el modelo del articulo, sino el del autor, el del foro donde se publicó, etc,etc.

No es lo mismo procesar una petición GET que una POST.Incluso si usas MVC, no es para nada lo mismo un controlador POST.

Una acción POST puede indicar que, dependiendo del resultado de su ejecución (correcto o no-correcto), debe renderizar también una petición GET (o realizar una redireccion).Pero son 2 procesos completamente distintos.

Te digo lo que yo uso, y como yo lo uso.No es MVC, porque MVC me parece bueno como "iniciación" a POO en PHP, pero no como arquitectura web.

Por cierto, cualquiera que te diga que para no llenar tu HTML de PHP, uses sistemas de plantillas como "Smarty", te está sólo cambiando el problema: ahora vas a tener tu HTML lleno de un pseudolenguaje capado, críptico, y que no aporta nada.

[Cuervoo]

Eso es lo que usa smarty para saber que estás metiéndo código. Es igual que <?php echo $titulo ?> En realidad es {$var} (una sola llave) pero es preferible cambiarlo porque sino te va a joder si metés javascript.

Leete sobre motores de plantillas, cada uno tiene su sintaxis, en una vistazo rápido a los ejemplos sin siquiera leer la documentación ya lo aprendés.

[guardarmicorreo]

Muchas gracias Cuervoo! :) miraré sobre Smarty.

dashtrash ¿qué utilizas si no es MVC?

Te explico. Yo ya tengo todas mis clases, el motor que hace todo el trabajo de manipulación de datos en una carpeta. Ahora quiero graficar, pero encuentro que no se cómo hacerlo correctamente. Se hacerlo, pero es una manera muy pobre de hacerlo, con un mantenimiento cara al futuro muy dificultoso. Así que ¿Cómo hacerlo?

Estoy viendo tu sistema de plantillas pero no termino de ver cómo funciona. Si quieres podemos contactar por MP, mail o Skype para que me des una descripción general de tu sistema de plantillas.

Gracias a todos por ayudarme! :D

[marlanga]

Iniciado por dashtrash

Por cierto, cualquiera que te diga que para no llenar tu HTML de PHP, uses sistemas de plantillas como "Smarty", te está sólo cambiando el problema: ahora vas a tener tu HTML lleno de un pseudolenguaje capado, críptico, y que no aporta nada.

Hombre, las plantillas con sistema de herencia y bloques como smarty (auqnue prefiero twig) ahorran trabajo. Claro, puedes programar el mismo sistema con PHP, pero entonces lo que estás haciendo es crear tu propio sistema de plantillas.
Además, no sirven para separar el HTML del PHP, si no para separar la lógica de negocio de la lógica de presentación.

[dashtrash]

Iniciado por marlanga

Hombre, las plantillas con sistema de herencia y bloques como smarty (auqnue prefiero twig) ahorran trabajo. Claro, puedes programar el mismo sistema con PHP, pero entonces lo que estás haciendo es crear tu propio sistema de plantillas.
Además, no sirven para separar el HTML del PHP, si no para separar la lógica de negocio de la lógica de presentación.

Exacto.Y para separar la lógica de negocio de la lógica de presentación, no necesito cambiar de lenguaje.Significa que el php que está generando HTML, no hace lógica de negocio.Hace sólo y exclusivamente lógica de presentación.
Si uso PHP para generar html no estoy creando "mi propio sistema de plantillas".Es que PHP es un lenguaje diseñado para crear plantillas.POO vino mucho después.

[marlanga]

Aprender la sintaxis es el pequeño precio que hay que pagar por usar un sistema de plantillas. Pero las ventajas que te ofrecen superan con creces ese inconveniente, por eso tienen tanto éxito y prácticamente todos los frameworks las usan. Un buen MVC parsea la plantilla a PHP y la guarda en la caché del proyecto, así que para el rendimiento del usuario final apenas tiene coste.

Es una elección personal, los frameworks permiten que sigas programando la vista con PHP a pelo, aunque pocos osan a ello.

[dashtrash]

Iniciado por guardarmicorreo

Muchas gracias Cuervoo! :) miraré sobre Smarty.

dashtrash ¿qué utilizas si no es MVC?

Pues no es algo que se cuente rápido...Pero, en general, para mí MVC (que es una filosofía no diseñada para web), tiene bastantes problemas.
Como te digo, en mi opinión, las peticiones POST y GET no tienen demasiado que ver las unas con las otras.Procesarlas bajo la misma estructura, es un problema.
Hay conceptos como "página" (una página es más que una "vista"...de hecho, no es una "vista"), enrutado, petición, etc, que son vitales en programación web, que no existen en el paradigma original MVC.Y, como no existen, cada framework implementa a su forma (y, en mi opinión, usualmente bastante discutiblemente).

Pero, lo que sí te puedo decir, es que para una petición GET, la prioridad es la página, y la composición de páginas como vistas.Las vistas obtienen los datos que necesitan sin necesidad de controlador.
Esta última frase puede poner los pelos de punta....Pero el secreto está en el sistema de plantillas.
Esto es código que está en producción:
Con mi sistema de plantillas, defino una página entera así:

Código HTML:

[*PAGE]
    [_CONTENT]
        [*/ps_customer/html/forms/EditAction][#]
    [#]
[#]
 

Eso es una *pagina*, mientras EditAction es una *vista*, ya que está asociada a un objeto, en este caso, ps_customer.
Esa vista se define como:

Código PHP:

<?php
            global $SERIALIZERS;
            $formKeys=array("id_customer"=>Registry::$registry["params"]["id_customer"]);;
            $serializer=\lib\storage\StorageFactory::getSerializerByName('backoffice');
            $serializer->useDataSpace($SERIALIZERS["backoffice"]["ADDRESS"]["database"]["NAME"]);
?>
 
 
                [*/FORMS/form({"object":"ps_customer","layer":"backoffice","name":"EditAction","form":"&$form"})]        
                [_TITLE]EditAction ps_customer[#]
                [_DESCRIPTION]Form Description[#]
                [_MODEL({"keys":"$formKeys","serializer":"$serializer","model":"&$currentModel"})][#]                           
                [_FORMGROUP]
                        [_TITLE]Form Group Title[#]
                        [_DESCRIPTION]Form Group Description[#]
                        [_FORMERRORS]
 
                        [#]
                        [_FIELDS]
 
 
                [*/FORMS/inputContainer({"name":"date_add"})]
                    [_LABEL]date_add[#]
                    [_HELP]**Insert Field Help**[#]
                    [_INPUT]
                        [*:/types/inputs/DateTime({"model":"$currentModel","name":"date_add","form":"$form"})][#]
                    [#]
                    [_ERRORS]
                        [_ERROR({"type":"INVALID","code":"2"})][@L]ps_customer__date_add_INVALID[#][#]
                        [_ERROR({"type":"UNSET","code":"1"})][@L]ps_customer__date_add_UNSET[#][#]
                    [#]
                [#]
 
 
                [*/FORMS/inputContainer({"name":"optin"})]
                    [_LABEL]optin[#]
                    [_HELP]**Insert Field Help**[#]
                    [_INPUT]
                        [*:/types/inputs/Integer({"model":"$currentModel","name":"optin","form":"$form"})][#]
                    [#]
                    [_ERRORS]
                        [_ERROR({"type":"INVALID","code":"2"})][@L]ps_customer__optin_INVALID[#][#]
                        [_ERROR({"type":"UNSET","code":"1"})][@L]ps_customer__optin_UNSET[#][#]
                    [#]
                [#]
 
 
                [*/FORMS/inputContainer({"name":"id_gender"})]
                    [_LABEL]id_gender[#]
                    [_HELP]**Insert Field Help**[#]
                    [_INPUT]
                        [*:/types/inputs/Integer({"model":"$currentModel","name":"id_gender","form":"$form"})][#]
                    [#]
                    [_ERRORS]
                        [_ERROR({"type":"INVALID","code":"2"})][@L]ps_customer__id_gender_INVALID[#][#]
                        [_ERROR({"type":"UNSET","code":"1"})][@L]ps_customer__id_gender_UNSET[#][#]
                    [#]
                [#]
       .......
 

Y esa plantilla a su vez usa otras plantillas que usan otras plantillas...Y sólo las de ultimo nivel contienen HTML.
Cosas como listar elementos se hacen asi:

Código PHP:

<?php
            global $SERIALIZERS;
            $params=Registry::$registry["PAGE"];
            $serializer=\lib\storage\StorageFactory::getSerializerByName('backoffice');
            $serializer->useDataSpace($SERIALIZERS["backoffice"]["ADDRESS"]["database"]["NAME"]);
?>
 
 
 
[*LIST_DS({"currentPage":"$currentPage","object":"ps_customer","dsName":"FullListDs","serializer":"$serializer","params":"$params","iterator":"&$iterator"})]
                [_HEADER]
                    [_TITLE]Titulo de la lista[#]
                    [_DESCRIPTION]Descripcion de la lista[#]
                [#]
                [_LISTING]
                    [_COLUMNHEADERS]
                        [_COLUMN][_LABEL]date_add[#][#]
                        [_COLUMN][_LABEL]optin[#][#]
                        [_COLUMN][_LABEL]id_gender[#][#]
                        [_COLUMN][_LABEL]id_default_group[#][#]
                        [_COLUMN][_LABEL]firstname[#][#]
                        [_COLUMN][_LABEL]id_customer[#][#]
                        [_COLUMN][_LABEL]date_upd[#][#]
                        [_COLUMN][_LABEL]lastname[#][#]
                        [_COLUMN][_LABEL]ip_registration_newsletter[#][#]
                        [_COLUMN][_LABEL]newsletter_date_add[#][#]
                        [_COLUMN][_LABEL]note[#][#]
                        [_COLUMN][_LABEL]deleted[#][#]
                        [_COLUMN][_LABEL]birthday[#][#]
                        [_COLUMN][_LABEL]passwd[#][#]
                        [_COLUMN][_LABEL]secure_key[#][#]
                        [_COLUMN][_LABEL]active[#][#]
                        [_COLUMN][_LABEL]is_guest[#][#]
                        [_COLUMN][_LABEL]newsletter[#][#]
                        [_COLUMN][_LABEL]email[#][#]
        
                    [#]
                    [_ROWS]
                        [_ROW][_VALUE][*:/types/DateTime({"name":"date_add","model":"$iterator"})][#][#][#]
                        [_ROW][_VALUE][*:/types/Integer({"name":"optin","model":"$iterator"})][#][#][#]
                        [_ROW][_VALUE][*:/types/Integer({"name":"id_gender","model":"$iterator"})][#][#][#]
                        [_ROW][_VALUE][*:/types/Integer({"name":"id_default_group","model":"$iterator"})][#][#][#]
                        [_ROW][_VALUE][*:/types/String({"name":"firstname","model":"$iterator"})][#][#][#]
                        [_ROW][_VALUE][*:/types/AutoIncrement({"name":"id_customer","model":"$iterator"})][#][#][#]
                        [_ROW][_VALUE][*:/types/DateTime({"name":"date_upd","model":"$iterator"})][#][#][#]
                        [_ROW][_VALUE][*:/types/String({"name":"lastname","model":"$iterator"})][#][#][#]
                        [_ROW][_VALUE][*:/types/String({"name":"ip_registration_newsletter","model":"$iterator"})][#][#][#]
                        [_ROW][_VALUE][*:/types/DateTime({"name":"newsletter_date_add","model":"$iterator"})][#][#][#]
                        [_ROW][_VALUE][*:/types/Text({"name":"note","model":"$iterator"})][#][#][#]
                        [_ROW][_VALUE][*:/types/Integer({"name":"deleted","model":"$iterator"})][#][#][#]
                        [_ROW][_VALUE][*:/types/DateTime({"name":"birthday","model":"$iterator"})][#][#][#]
                        [_ROW][_VALUE][*:/types/String({"name":"passwd","model":"$iterator"})][#][#][#]
                        [_ROW][_VALUE][*:/types/String({"name":"secure_key","model":"$iterator"})][#][#][#]
                        [_ROW][_VALUE][*:/types/Integer({"name":"active","model":"$iterator"})][#][#][#]
                        [_ROW][_VALUE][*:/types/Integer({"name":"is_guest","model":"$iterator"})][#][#][#]
                        [_ROW][_VALUE][*:/types/Integer({"name":"newsletter","model":"$iterator"})][#][#][#]
                        [_ROW][_VALUE][*:/types/String({"name":"email","model":"$iterator"})][#][#][#]
 
                    [#]
                    [_LISTINGFOOTER]
                    [#]
                [#]     
           [#]
 

En la línea:

Código HTML:

[*LIST_DS({"currentPage":"$currentPage","object":"ps_customer","dsName":"FullListDs","serializer":"$serializer","params":"$params","iterator":"&$iterator"})]
 

Le estoy diciendo que para dibujar ese listado, quiero usar la fuente de datos "FullListDs" del objeto "ps_customer", parametrizada por "$params".
Eso es lo que MVC "estándar" haría en el controlador.*instanciar* esa fuente de datos.Lógicamente, la composición de la query, chequeo de parámetros, etc,etc, no se hace en la plantilla.Existen clases que hacen eso, y que son invocadas por plantillas de más bajo nivel.
A mí no me molesta en absoluto que la instanciación de la fuente de datos (repito, instanciación, no "implementación") esté en mi plantilla, ya que es lo suficientemente clara (una vez que la entiendes) como para cambiarla en cualquier momento (incluso desde un editor).

Leyendo esa plantilla, sabes qué quiere hacer.Claramente, es un listado, con unas cabeceras, y unas rows.Si te pusiera el equivalente en html con smarty, no verías nada.

Para terminar, esas plantillas son código generado...como te digo, no es para nada MVC.Para mí, resolver GET se hace desde las plantillas, ya que con este tipo de plantillas, basado en capas, me es *muy* sencillo y claro hacerlo todo desde ellas.

[dashtrash]

Iniciado por marlanga

Aprender la sintaxis es el pequeño precio que hay que pagar por usar un sistema de plantillas. Pero las ventajas que te ofrecen superan con creces ese inconveniente,

Qué ventaja, exactamente?
Qué puedes hacer con Smarty, que no hagas con PHP?
Es más claro un "for" hecho con Smarty, que con PHP?
Como tú has dicho, lo importante es mantener la lógica de negocio independiente de la lógica de aplicación.
Por qué eso requiere un lenguaje distinto, que cambia cómo se escribe un "if", es algo que no acabo de entender.
Que eso lo usen los frameworks MVC, si lo entiendo..Muchos programadores PHP no sabrían juzgar bien qué es qué, así que se les "joroba" metiéndoles otro lenguaje, desde el cual no pueden hacer queries en medio de una tabla...
Pero eso no dice nada de que sea necesario Smarty.Sino de los programadores que lo hacen.

[Cuervoo]

Y usar Smarty es complicado? Estamos todos locos.

Se ve bueno eso, después le voy a pegar una revisada. Tenés algún lugar con ejemplos dashtrash?

[guardarmicorreo]

dashtrash, he leído y releído tu ejemplo aquí y la verdad es que es impresionante, al principio impresiona al ver una sintaxis totalmente desconocida, por lo menos para mi, pero una vez que comienzas a interpretar su lógica es realmente sencillo. la semana que viene me pondré a trabajar sobre tu sistema de plantillas, me gustaría muchísimo poder hacerlo. Pero la documentación que hay en el .zip para descargar el sistema de plantillas me tiene confundido.

Al entrar en la carpeta Manual, veo que hay varios más carpetas y archivos. La mayoría son javascript y css, pero hay dos de ellos (html y php) que contienen lo mismo que en el espacio de la documentación desde donde descargarlo :S

He leído en inglés los ejemplos pero no me ha quedado muy claro. Me gustaría poder utilizarlo pero ahora mismo me veo incapaz porque se inglés, pero no tanto como tú.

Como petición personal estaría bien poder disponer de un sistema de plantillas como el tuyo con una explicación en español :D

Por lo demás me quito el sombrero, buen trabajo y lección sobre plantillas. La semana que viene le daré duro a este tema porque es algo vital y técnicas como la tuya, que utilizan PHP y no otro pseudolenguaje, era lo que estaba buscando y ya encontré.

Gracias!!! :D

[marlanga]

Yo no uso smarty. Me gusta mucho más twig. Las ventajas son muchas, ya he nombrado algunas. Hace trabajo por tí, es más corto, es fácilmente mantenible, tiene sistema de herencia, tiene sistema de bloques, no se necesita saber programar para crear vistas (sobre todo cuando trabajas con diseñadores). Por ejemplo:

Código PHP:

<ul>
    {%foreach libros as libro%}
    <li><{libro.titulo} - {libro.autor}</li>
    {%end%}
</ul>
 

Es más cómodo de mantener y modificar que:

Código PHP:

<ul>
    <?php foreach ($libros as $libro): ?>
    <li><?= htmlspecialchars($libro->titulo) ?> - <?= htmlspecialchars($libro->titulo) ?></li>
    <?php endforeach; ?>
</ul>
 

¿No te gusta twig porque usa etiquetas propias? Perfecto, hay sistemas de plantillas que usan PHP estándar, como el módulo VIEW de zend framework: http://framework.zend.com/manual/1.12/en/zend.view.html

PD. Hacer un query en mitad del dibujado de una tabla, es algo que yo jamás haría.

[xSkArx]

Hay un ebook de una tal eugenia, que enseña como crear la vista de una manera sencilla
http://www.etnassoft.com/biblioteca/poo-y-mvc-en-php/

[marlanga]

Iniciado por guardarmicorreo

Por lo demás me quito el sombrero, buen trabajo y lección sobre plantillas. La semana que viene le daré duro a este tema porque es algo vital y técnicas como la tuya, que utilizan PHP y no otro pseudolenguaje, era lo que estaba buscando y ya encontré.
Gracias!!! :D

No es por nada, pero sí utiliza su propio pseudo-lenguaje para manejar los bloques, por medio de símbolos. Como todos los sistemas de plantillas, aunque éste es menos legible.

[dashtrash]

Iniciado por guardarmicorreo

Como petición personal estaría bien poder disponer de un sistema de plantillas como el tuyo con una explicación en español :D

La documentación está en Manual.html.
El resto de las cosas es porque Manual.html.. fue renderizado como una plantilla, usando el propio sistema.

A ver si tengo tiempo esta noche para hacer una traducción al castellano, y lo resubo.

Entiendo que al principio parezca todo un poco raro.Es un sistema de plantillas que hace justo lo contrario que el resto.Lo que quiero evitar no es php, sino HTML.
Mi forma de pensar en plantillas, no es "meter un lenguaje nuevo que no tiene mysql_query, asi que no puedes meter una query enmedio de un <table>".
La idea es:
Si yo te digo que estoy viendo una página con un formulario de login, tú puedes fácilmente saber que estaré viendo 1 campo de texto, 1 campo password, y 1 botón .Lo que no sabes es *nada* de cómo, visualmente, están dispuestos, qué colores tienen, qué tamaño, etc, etc.
Si yo te digo que en una página hay un menú, y en la opción "Secciones", pinches en "Principal", tú sabes que va a haber algún sitio donde hay una serie de etiquetas (una de ellas es "Seccion"), que contiene otras etiquetas ("Principal"), que son links.
Tú no sabes si el menú es horizontal, vertical, de un color o de otro.

Con lo cual, en un interfaz de usuario existen abstracciones
("menu", "listado", "cabecera", "caja") que son manejables independientemente de su formato.Incluso del dispositivo de salida.Un menú en un navegador se va a pintar distinto que un menú en un móvil.Pero sigue siendo conceptualmente la misma cosa.Lo que cambia es el cómo se pinta.
Y es por eso que mi sistema de plantillas intenta manejar "conceptos" ("Pagina","Form","Listado"), que se renderizan según otras plantillas, que usan otras...hasta que sólo al final, en las plantillas base, se convierten a html.

El asunto es que las plantillas de más alto nivel, son tan simples, que una persona no técnica las maneja desde un editor de texto:

Código HTML:

[*PAGE]
         [_CONTENT]
                  [*CARROUSEL]
                            [_ITEM]
                                 [_IMAGE]myimage.jpg[#]
                                 [_LINK]/home[#]
                            [#]
                            [_ITEM]
                                 [_IMAGE]myimage2.jpg[#]
                                 [_LINK]/offers[#]
                            [#]
                  [#]
                  [*VIDEO]http://www.youtube.com....[#]
         [#]
[#]
 

Mirando rápidamente , ves que es una página que tiene un carrousel de imágenes, y un vídeo.Cómo se pinta el carrousel, con qué librerías js, cómo se renderiza el video, etc,etc, se resuelve con componentes más pequeños y reutilizables.Pero lo importante es que expresa "qué" quiero, y no "cómo" pintarlo.
Esa plantilla no cambia si lo voy a renderizar para web o para móvil, por poner un ejemplo.
Un rediseño entero de la web, no modifica estas plantillas, tampoco.

Lo que quiero decir es que, a mí, me parece interesante dividir un interfaz de usuario en capas "lógicas" y capas "físicas" (html).

Otros sistemas de plantillas, lo que me dan son sintaxis que no necesito para evitar que meta queries enmedio de html...Eso ya lo aprendí hace tiempo..

[dashtrash]

Iniciado por marlanga

No es por nada, pero sí utiliza su propio pseudo-lenguaje para manejar los bloques, por medio de símbolos. Como todos los sistemas de plantillas, aunque éste es menos legible.

No tiene nada que ver con otro sistema de plantillas...Y no sé cuánto has trabajado con mi sistema de plantillas, pero he trabajado mucho con Smarty...No sé qué consideras legible.
La filosofía no tiene nada que ver.Ves algo de html? La plantilla de listado anterior no te parece legible?Es más legible el equivalente usando smarty?Puedes poner un ejemplo de una plantilla para hacer un listado, hecha con smarty, y que quede más claro que la anterior?

[guardarmicorreo]

Creeme que esta noche si lo actualizas me quedaré hasta bien tarde para ir trabajando con tu sistema de plantillas. Su sencillez me ha dejado =O a mi no se me habría ocurrido nunca hacer algo así. Muchas gracias!!!!