En Symfony2, lorsqu’on fait un formulaire que l’on veut ensuite manipuler avec du JQuery par exemple, il est utile de faire le rendu du data-prototype que l’on a au préalable paramétré dans le Formbuilder.

Donc, soit on utilise

{{ form_widget(form) }}

Soit, pour faire un rendu manuel (par exemple lorsqu’on manipule une collection que l’on veut afficher à sa manière), il faut utiliser le bout de code suivant :

{{ form_row(form.addresses.get('prototype'))|e }}

Exemple:

<form action="" method="post" {{ form_enctype(form) }}>
   <!-- form_widget(form) -->

<div id="tabs">
<ul>
        <li><a href="#fragment-1"><span>Main informations</span></a></li>
        <li><a href="#fragment-2"><span>Addresses</span></a></li>
        <li><a href="#fragment-3"><span>Misc.</span></a></li>
</ul>
<div id="fragment-1">
   <h3>Main informations</h3>
    {{ form_row(form.name) }}
    {{ form_row(form.type) }}
    {{ form_row(form.customer_code) }}
    {{ form_row(form.provider_code) }}
</div>
<div id="fragment-2">
  <h3>Addresses</h3>
  <div id="thirdparty_addresses" data-prototype="{{ form_row(form.addresses.get('prototype'))|e }}"/>
   {% set i = 0 %}
   {% for child in form.addresses %}
  {{    form_row(child.address, {'label': 'Address: '}) }}
  {{    form_row(child.zipcode, {'label': 'Zip: '}) }}
  {{    form_row(child.town, {'label': 'City: '}) }}
  {{    form_row(child.country, {'label': 'Country: '}) }}
  {{    form_row(child.department, {'label': 'Province: '}) }}
  {{    form_rest(child) }}
   {%   set i = loop.index %}
   {% endfor %}
<a href="#" class="jslink"> Add an address </a>
</div>
<div id="fragment-3">
    {{ form_rest(form) }}
</div>
    <input type="submit" />
</form>

C’est (mieux) expliqué ici :

https://github.com/symfony/symfony/pull/1724

Avec un gist ici : https://gist.github.com/1151134

 

Ce site/blog est “propulsé” par wordpress. La configuration est la suivante :

haproxy en front qui redispatch sur Varnish ou directement sur Apache si varnish est down. Apache et Varnish sont lancés sur le même serveur (d’où la règle de vérification de la purge basée sur 127.0.0.1… A modifier / améliorer pour plus de sécurité).

Le VCL utilisé pour cacher wordpress est celui trouvé par ailleurs pour la version 2.0 de Varnish mais adapté à la Varnish 3.0 (sans quoi il y avait quelques problèmes de compilation du VCL au démarrage). NOTA : le remplacement du purge par un ban qui permet de faire une purge wildcard (si on enlève le ban, la purge n’a lieu que sur l’URL elle même et du coup les changements de thème et autres subtilités de ce genre ne sont plus effective même après une purge via wp-varnish).

Le VCL complet figure ci-dessous :

backend default {
	.host = "127.0.0.1";
	.port = "80"; 	// Apache is listening on port 80
}

acl purge {
  "localhost";
  "127.0.0.1";
}

sub vcl_recv {
  if (req.request == "PURGE") {
    	if(!client.ip ~ purge) {
      		error 405 "Not allowed.";
    	}
    	//purge("req.url ~ ^" req.url "$ &amp;&amp; req.http.host == "req.http.host);
        //error 200 "Purged.";
        ban("req.url ~ ^" req.url "$ &amp;&amp; req.http.host == "req.http.host);
	return (lookup);
  }

  if (req.request != "GET" &amp;&amp;
      req.request != "HEAD" &amp;&amp;
      req.request != "PUT" &amp;&amp;
      req.request != "POST" &amp;&amp;
      req.request != "TRACE" &amp;&amp;
      req.request != "OPTIONS" &amp;&amp;
      req.request != "DELETE") {
    return (pipe);
  }

  if (req.request != "GET" &amp;&amp; req.request != "HEAD") {
    return (pass);
  }

  if (req.url ~ "wp-(login|admin)" || req.url ~ "preview=true") {
    return (pass);
  }

  remove req.http.cookie;
  return (lookup);
}

sub vcl_hit {
        if (req.request == "PURGE") {
                purge;
                error 200 "Purged.";
        }
}

sub vcl_miss {
        if (req.request == "PURGE") {
                purge;
                error 200 "Purged.";
        }
}

sub vcl_fetch {
  if (req.url ~ "wp-(login|admin)" || req.url ~ "preview=true") {
    //return (pass);
    return (hit_for_pass);
  }

  set beresp.ttl = 72h;
  return (deliver);
}

Bon reverse proxy cache à tous…

HTH.

Références:
[1] à renseigner : le post d’origine sur le VCL pour la V2… Je ne le trouve plus :)
[2] https://www.varnish-cache.org/docs/trunk/tutorial/purging.html

 

 

 

Geo DNS:

 

 

 

Livre(s) en ligne :

 

 

 

http://wiki.openstack.org/NovaDeploymentManual

http://www.xen.org/download/xcp/index.html

http://wiki.xen.org/xenwiki/XCP_Docs?highlight=%28XenCenter%20Compatibility%29

http://wiki.openstack.org/XenServerDevelopment#Prepare_XenServer

 

Pour mémoire :

  • UCK et surtout UCK-Flow
  • UCK-Flow permet entre autre de gérer tout le workflow d’édition (extraction du squashfs par exemple)
  • Les personnalisations du comportement de boot par défaut du livecd se font dans isolinux à la racine de l’ISO (voir aussi le label par défaut appelé dans l’autorun.inf)
  • Côté personnalisation graphique : sans doute des choses à voir côté isolinux, le slideshow qui défile pendant le boot est dans le paquet ubiquity-slideshow. HTML livrés dans /usr/share/ubiquity-slideshow, éditer l’index.html pour modifier l’ordre
  • Paramètre de boot à auto et notamment paramètre ubiquity à voir sur ce point.

 

Documentations en ligne :

 

 

 

Rainbird : l’analytics par tweeter

Références :

 
A voir et à revoir :

Langages et frameworks :

 

Le petit typographe rationnel par Eddie Saudrais est une mine d’informations à la portée de tous…

© 2012 enrici.com (carnet de note(s)) Suffusion theme by Sayontan Sinha