#7230 Utilizaba helpers en codeigniter, pero en mis vistazos a la documentación de symfony no habia visto nada similar. Busco por ahi entonces, thanks!
http://symfony.com/doc/current/templating/embedding_controllers.html
Esto te permite llamar a un controlador desde Twig, el ejemplo de hecho es una lista de artículos recientes (muy parecido a lo que pides).
#7229 Lo que yo hago, que a lo mejor es un poco "brutete", es que tengo un controlador principal que carga todo el contenido necesario en la petición, y luego cada vista coge los datos que necesita haciendo uso de "$this->response_data", es decir, primero proceso la petición y obtengo todos los datos para procesarla, después genero la vista, y dentro de cada vista, se acceden a los datos que se han obtenido en el controlador principal.
Esto tiene una ventaja, y es que, si detecto que es una petición en AJAX, en lugar de renderizar la vista devuelvo los datos en JSON y a tomar por culo, así tengo la API hecha sin hacer nada xD.
Si en symfony puedes acceder desde las vistas a alguna propiedad del controlador que procesa la petición, puede ser una opción.
Y con lo que dices de "modificar unos archivos del core", en Codeigniter puedes sobreescribir funciones del núcleo de los controladores haciendo uso de clases específicas, estoy seguro de que en symfony se puede hacer, pero no lo manejo, así que ahora mismo no se me ocurre la forma... Pero no te recomiendo modificar archivos del core si no quieres tener un infierno más adelante xD.
Edito: Lo que dice #7232 parece lo más sencillo y rápido para symfony.
#7229 Annotations o Yml?
Respecto a las noticias o un controlador incrustado o un plugin de twig (que es un service)
#7236 si mal no recuerdo con YAML tienes la propiedad template en el routing para definir el que te salga del pito.
Con annotations (a mi me gustan mas, cada controller tiene todo en el mismo sitio) es asi:
/***
* @Template("AppBundle:Foo:Bar.html.twig")
*/
public function fizzAction()
{
return array();
}#7237 Si pero, lo que quería hacer es cargar una template (en tu caso AppBundle:Foo:Bar.html.twig), pero en caso de que existiera app/resources/views/Bar.html.twig enseñar esa.
El objetivo es el de tener un bundle que pueda incrustar en multiples proyectos con una vista base, pero que si ese proyecto necesita una template diferente se pueda reemplazar facilmente. De la misma manera que funcionan los bundles de vendor.
#7238 Esonpuedes hacerlo en el response, en vez de utilizar el annotation, hacer:
return $this->render('foo/bar.html.twig', array());Pero de todas formas, ese comportamiento te cargas MVC, las vistas contenidas en app/Resources/views ee supone que son partes globales o overrides a vistas del vendor.
Cuando creas una accion, has de crear au vista asociada y si quieres tener mas de un tipo de vista en un controller siempre puedes hacerlo con twig y parametros.
Edit--->
Las vistas de src/ tambien se pueden overridear, pero la idea es como he dicho en app/resources te montas base.htm.twig y luego estructuras dentro.
Dame 5 mins que pillo el portatil y te pego ejemplos.
#7238 Veamos, lo de reutilizar templates como dices yo normalmente lo hago asi (y si mal no recuerdo es lo recomendado)
Esta es la estructura de app/Resources/view:
Aqui el template base:
<!DOCTYPE html>
<html lang="en-us" id="">
<head>
<meta charset="utf-8">
<title>Base</title>
<meta name="description" content="">
<meta name="author" content="">
<meta name="viewport"
content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
<link href="{{ asset('css/bootstrap.min.css') }}" rel="stylesheet"/>
<link href="{{ asset('css/font-awesome.min.css') }}" rel="stylesheet"/>
<link href="{{ asset('css/custom.css') }}" rel="stylesheet"/>
<link rel="icon" type="image/x-icon" href="{{ asset('favicon.ico') }}"/>
</head>
<body>
{{ include ('::header.html.twig' ) }}
{{ include ('::nav.html.twig') }}
<div id="main" role="main">
{{ include ('::breadcrumbs.html.twig') }}
<div id="content">
{% for flashMessage in app.session.flashbag.get('msg') %}
<div class="row">
<div class="col-xs-12">
<div class="alert alert-warning">{{ flashMessage }}</div>
</div>
</div>
{% endfor %}
{% for flashMessage in app.session.flashbag.get('err') %}
<div class="row">
<div class="col-xs-12">
<div class="alert alert-danger">{{ flashMessage }}</div>
</div>
</div>
{% endfor %}
{% for flashMessage in app.session.flashbag.get('err_c') %}
<div class="row">
<div class="col-xs-12">
<div class="alert alert-danger">{{ flashMessage }}</div>
</div>
</div>
{% endfor %}
{% for flashMessage in app.session.flashbag.get('scc') %}
<div class="row">
<div class="col-xs-12">
<div class="alert alert-success">{{ flashMessage }}</div>
</div>
</div>
{% endfor %}
<div class="row">
<div class="col-xs-12 col-sm-7 col-md-7 col-lg-4">
<h1 style="font-size:25px; margin-bottom:10px; class="
page-title txt-color-blueDark"><i
class="fa-fw fa fa-home"></i>
{% if is_granted('IS_AUTHENTICATED_FULLY') %}
Welcome {{ app.user.username|upper }}
{% endif %}
</span></span></h1>
</div>
</div>
{% block body %}{% endblock %}
{% block footerjs %}
{% endblock %}
{% block extrabottomjs %}{% endblock %}
</body>
</html>Aqui el nav.html.twig que va incluido en la base:
<!-- Left panel : Navigation area -->
<aside id="left-panel">
<!-- User info -->
<div class="login-info">
</div>
{% if is_granted('ROLE_ADMIN') %}
<h2 class="txt-color-white">Nav</h2>
<nav>
<ul style="">
<li>
<span class="menu-item-parent">
<a href="{{ path(foo_bar') }}">Fizz</a>
</span>
</li>
</ul>
</nav>
{% endif %}
</aside>
<!-- END NAVIGATION -->Y lo mismo con el footer y tal:
Una vez construyes estos archivos basicos, tu template esta listo para usarse en cualquier proyecto y las vistas de las acciones son algo asi:
{% extends '::base.html.twig' %}
{% block body -%}
<section id="widget-grid" class="">
<div class="row">
<article class="col-xs-12 col-sm-12 col-md-12 col-lg-12">
</article>
</div>
</section>
{% endblock %}Simplemente llenas los bloques que has definido en el base.html.twig.
#7234 Tiro todo con la misma URL, la petición es la misma, simplemente diferencio el tipo de petición y proceso la petición en consecuencia, puedo renderizar el bloque de contenido de la plantilla (carga parcial de la vista), renderizar la página completa, o renderizar el JSON, creo que es bastante útil xD.
Para crear backends dinámicos me viene de perlas.
¿Os imagináis que todas estas preguntas y respuestas estuviesen en temas separados que se pudieran buscar fácilmente? Menudo placer sería.
c a . 1.
c b . . c.1. d. 2..
f someFunction.name.age. .
c.l.b.c..
.
"It's so readable"
Edit: vale, he caído. 01/04
#7242 Ni SOLID ni LIQUID, yo estoy gestionando la salida de la petición desde el core, las funciones de cada controlador son las que se encargan de definir el resultado, no genero esas múltiples salidas (view completa, view parcial, o json) individualmente en cada función, me facilita bastante el trabajo y funciona muy bien xD. Si quieres te paso un poco de códifo para que veas como funciona <3.
Es más, así es como gestiono también los permisos de cada página, si necesitas un usuario logueado, si necesitas un usuario logueado y administrador, etc...
#7252 yo para controlar los permisos tiro de:
switch(json_decode($this->get('security.context')->getToken()->getUser()->getRoles(), true)[0]) {
case "ROLE_USER":
...
break;
}La verdad es que es lo mas efectivo ahi lo primero en la accion.
#7252 pues yo sigo sin verle ninguna ventaja (no se si son las horas, que soy retrasado o ke...), puedes pasar un poco de codifo para ilustrarme/nos?
Yo intento que todos mis metodos en mis controladores sean de 3 lineas y aun asi me parecen muchas...
#7254 No eres el unico eh...
Por cierto tres lineas... vaya overkill, yo si es mas de tres caracteres lo hago con Haskell
#7255 ok.. pues ni pa ti ni pa mi, 2 lineas de 2 caracteres es lo ideal contando cachear cosas y todo
