Alors bien sûr, la solution radicale, c’est de réduire le nombre de colonnes, mais souvent le client, il les veut ses colonnes! La 2e solution est de supprimer ce bloc de filtre. On fait ça très simplement dans le generator.yml:

filter:
  class: false

Cependant, il arrive quand même que le filtrage soit nécessaire mais bien souvent, seulement 2 ou 3 valeurs. J’ai donc décidé de prendre le taureau par les cornes et faire la modification dont je rêve depuis longtemps, passer ce bloc de filtre, au dessus du tableau! Pour ce faire, j’ai modifié 2 fichiers. Tout d’abord, le fichier _filters.php qu’il faudra rajouter dans le dossier templates de vos modules visés:

<div class="sf_admin_filter">
 
	<div class="content_filter">
  <?php if ($form->hasGlobalErrors()): ?>
    <?php echo $form->renderGlobalErrors() ?>
  <?php endif; ?>
 
 
  <form action="<?php echo url_for('produits_collection', array('action' => 'filter')) ?>" method="post">
	  <?php foreach ($configuration->getFormFilterFields($form) as $name => $field): ?>
	  <div class="bloc_filter">
        <?php if ((isset($form[$name]) && $form[$name]->isHidden()) || (!isset($form[$name]) && $field->isReal())) continue ?>
          <?php include_partial('produits/filters_field', array(
            'name'       => $name,
            'attributes' => $field->getConfig('attributes', array()),
            'label'      => $field->getConfig('label'),
            'help'       => $field->getConfig('help'),
            'form'       => $form,
            'field'      => $field,
            'class'      => 'sf_admin_form_row sf_admin_'.strtolower($field->getType()).' sf_admin_filter_field_'.$name,
          )) ?>
    </div>
    <?php endforeach; ?>
 
     <?php echo $form->renderHiddenFields() ?>
     <?php echo link_to(__('Reset', array(), 'sf_admin'), 'produits_collection', array('action' => 'filter'), array('query_string' => '_reset', 'method' => 'post')) ?>
     <input type="submit" value="<?php echo __('Filter', array(), 'sf_admin') ?>" />
  </form>
  </div>
</div>

Au final, j’ai simplement supprimé le tableau, par défaut et mis chaque widget dans un div. On obtient donc quelque chose qui change pas vraiment la donne pour l’instant:

Mais en lui appliquant un peu de css:

div#sf_admin_bar {
	float:none;
	margin: 0;
}
 
#sf_admin_bar .sf_admin_filter form div.bloc_filter {
	display:inline;
	padding:0 20px 0 0;
}
 
div#sf_admin_container #sf_admin_bar label {
	display:inline;
	float:none;
	padding:0;
}

On commence à approcher de ce que l’on souhaite:

Maintenant, on habille un peu la chose, histoire de gagner en clarté:

#sf_admin_bar .sf_admin_filter {
	background-color:#FFF;
	margin:12px 0;
}
 
#sf_admin_bar .sf_admin_filter .content_filter {
	border:1px solid #DDDDDD;
	padding:5px;
}

Pour obtenir finalement:

Un dernier détail, le filtre « référence » avec sa colonne « is_empty » casse un peu notre rendu. Personnellement, je ne me sers pas de cette checkbox, on va donc redéfinir notre filtre pour la supprimer dans lib/filters/MonModuleFilters.class.php:

public function configure()
  {
    $this->widgetSchema['reference'] = new sfWidgetFormFilterInput(array(
      'template' => '%input%'
    ));
  }

Et voilà, une jolie barre de recherche beaucoup plus du goût des clients en général :)

Alors bien sûr, cette solution ne fonctionne qu’avec un nombre limité de filtre, sinon on aurait un rendu un peu moins visuel, mais je pense que ça reste toujours mieux que 2 blocs qui se chevauchent.

• la remise en état des liens modifier/supprimer
• l’ajout d’un lien pour ajouter un enfant à une catégorie
• la sauvegarde de l’ordre de l’arbre

Ya du boulot, alors on se lance.

Le seul problème à la remise des liens modifier/supprimer c’est leur structure HTML, en ul/li qui pose souci avec le plugin NestedSortable. On va donc revoir la chose en les mettant dans un « p » avec de simples liens. Pour cela on va éditer dans notre module le fichier lib/categoriesGeneratorHelper.class.php (qui doit être vierge pour l’instant) et on va surcharger les méthodes, linkToEdit et linkToDelete:

  public function linkToEdit($object, $params)
  {
    return '<span class="sf_admin_action_edit">'.link_to(__($params['label'], array(), 'sf_admin'), $this->getUrlForAction('edit'), $object).'</span>';
  }
 
public function linkToDelete($object, $params)
  {
    if ($object->isNew())
    {
      return '';
    }
 
    return '<span class="sf_admin_action_delete">'.link_to(__($params['label'], array(), 'sf_admin'), $this->getUrlForAction('delete'), $object, array('method' => 'delete', 'confirm' => !empty($params['confirm']) ? __($params['confirm'], array(), 'sf_admin') : $params['confirm'])).'</span>';
  }

Les seules modifications concernant le changement d’un li par un span.

Maintenant on va modifier le partial _list_td_actions.php et donc le rajouter dans notre répertoire templates de notre module:

<p class="sf_admin_td_actions list_action">
  <span class="sf_admin_action_new">
    <?php echo link_to(__('Ajout Enfant'), 'categories/addChild?id='.$categories->getId(), array(), 'messages') ?>
  </span>
  <?php echo $helper->linkToEdit($categories, array(  'params' =>   array(  ),  'class_suffix' => 'edit',  'label' => 'Edit',)) ?>
  <?php echo $helper->linkToDelete($categories, array(  'params' =>   array(  ),  'confirm' => 'Are you sure?',  'class_suffix' => 'delete',  'label' => 'Delete',)) ?>
</p>

A noter qu’on a ajouté au passage l’action Ajout d’enfant.
Il nous reste plus qu’à rajouter l’appel à ce partial dans notre _tree.php:

[...]
<div class="sort-handle">
   <?php echo $node->getTitre() ?>
</div>
<?php include_partial('categories/list_td_actions', array('categories' => $node, 'helper' => $helper)) ?>
[...]

Le résultat nous donne ceci:

Alors oui c’est moche, mais ca fonctionne! Maintenant, on passe un petit coup de CSS comme d’habitude:

.list_action {
	position: absolute;
	right: 0; top:0;
	width: 350px;
}
 
.list_action span {
	padding: 0 10px 0 0;
}
 
.current-nesting {
	background-color: #FFE;
}
 
#sf_admin_container #sf_admin_content p span.sf_admin_action_new a {
	background:transparent url(/sfPropelPlugin/images/new.png) no-repeat scroll 0 0;
}
#sf_admin_container #sf_admin_content p span.sf_admin_action_edit a {
	background:transparent url(/sfPropelPlugin/images/edit.png) no-repeat scroll 0 0;
}
#sf_admin_container #sf_admin_content p span.sf_admin_action_delete a,.link_delete {
	background:transparent url(/sfPropelPlugin/images/delete.png) no-repeat scroll 0 0;
}

Et la magie opère de nouveau:

On va maintenant créer les actions liées à cette nouvelle action dans notre fichier d’actions de notre module:

public function executeAddChild(sfWebRequest $request)
  {
    $this->categories = $this->getRoute()->getObject();
 
    // On récupère le parent pour insérer la nouvelle catégorie sous ce parent et on le fait transiter via session 
    $this->getUser()->setAttribute('categories.addChild',$this->categories->getPrimaryKey(), 'admin_module');
 
    $this->form = $this->configuration->getForm();
    $this->setTemplate('new');
  }
 
  /**
   * On surcharge le processForm pour récupérer le parent de la catégorie à ajouter s'il existe
   *
   * @param sfWebRequest $request
   * @param sfForm $form
   */
  protected function processForm(sfWebRequest $request, sfForm $form)
  {
    if ($parent = $this->getUser()->getAttribute('categories.addChild', null, 'admin_module'))
    {
      $this->getUser()->getAttributeHolder()->remove('categories.addChild', null, 'admin_module');
      $root = CategoriesPeer::retrieveByPk($parent);
      $form->getObject()->insertAsLastChildOf($root);
    }
 
    parent::processForm($request,$form);
  }

Si vous cliquez maintenant sur « Ajouter un enfant’ d’une des catégories déjà présente vous obtenez alors:

Vu que les tree left et tree right sont définis par Propel, on va les supprimer du formulaire.
Dans notre CategoriesForm.class.php on rajoute:

public function configure()
  {
    unset(
      $this['tree_left'],
      $this['tree_right']
    );
  }

Maintenant, il ne manque plus qu’à pouvoir sauvegarder les modifications d’ordre effectuées via javascript. Pour cela on va rajouter une batch actions (elles soumettent un formulaire, il sera ainsi plus facile de faire passer les modifications faites à l’arbre).
Dans notre generator.yml on rajoute dans l’entrée list:

  batch_actions:
    saveOrder:
      label: Sauvegarder ordre
      action: saveOrder

Et dans notre partial _list.php, juste avant le javascript:

<div>
	<input type="hidden" id="hashValue" name="hashValue" value="" />
	<input type="hidden" name="ids" value="<?php echo (!empty($item)?$item->getPrimaryKey():'1') ?>" />
</div>

Le premier pour récupérer la sérialisation de la nestedlist en javascript, le deuxième pour passer outre le système de batch qui demande de sélectionner au moins un ids pour lancer l’action ensuite.

On obtient donc:

Il ne reste plus qu’à faire l’action correspondante dans notre fichier d’actions:

public function executeBatchSaveOrder(sfWebRequest $request)
  {
    $hash = $request->getParameter('hashValue');
    parse_str($hash, $list);
    CategoriesPeer::saveOrder($list);
    $this->getUser()->setFlash('notice', 'Ordre mis à jour');
  }

Et les fonctions de sauvegarde dans notre modèle. La fonction mère dans le CategoriesPeer.php:

public static function saveOrder($hash)
  {
    $root = self::retrieveRoot();
 
    foreach ($hash['main_list'] as $categorie)
    { 
      $u = self::retrieveByPk($categorie['id']);
 
      if (!empty($categorie['children']))
      {
        $u->saveChildren($categorie['children']);
      }
 
      $u->moveToLastChildOf($root);
      $u->save();
    }
  }

Qui gère les « racines » et son équivalent récursif dans le model Categories.php:

       public function saveChildren($children)
	{
	  foreach($children as $child)
	  {
	    $item = CategoriesPeer::retrieveByPk($child['id']);
	    if (!empty($child['children']))
	    {
	      $item->saveChildren($child['children']);
	    }
	    $item->moveToLastChildOf($this);
            $item->save();
	  }
	}

Et voilà! Vous pouvez maintenant déplacer vos catégories et sauvegarder leur position dans l’arbre.

Evidemment toute question, suggestion sont bien sûr les bienvenues. Je pense mettre les source et une démo en ligne très bientôt, voir en faire un plugin si jamais je rencontre un réel intérêt pour ce genre de gadget.

En attendant, une petit illustration en vidéo:

Ici, le principe va être justement de gérer un arbre de catégories, un cas qui peut revenir assez régulièrement. A noter que le concept reprend la version doctrine de redotheoffice avec une modification quant au plugin jquery utilisé. En effet, on essaiera ici de gérer l’ordre des catégories également par drag and drop.

En général, quand on part la tête dans le guidon, on crée une table categories, et pour créer la notion de parent, on applique une clé étrangère sur cette même table. Oui mais voilà, autant pour les opérations de suppression et d’ajout, voir même de déplacement dans l’arbre cette démarche est très performante, autant quand il s’agit d’afficher l’arbre, la galère commence.
Et pourtant, c’est bien cette deuxième qu’on fait à chaque affichage de page!

Il existe pourtant une alternative à cette clé étrangère: les Nested Set. En français, les représentations intervallaires. Le but n’étant pas d’expliquer dans le détail ce que c’est, je vous invite à faire un tour sur développez.com où on retrouve un très bon article illustré à ce sujet.

Brièvement, cette méthode consiste à rajouter des champs en base, left, right et scope permettant de retrouver ses petits. Le diagramme de developpez.com résume bien:

Ok, c’est bien, mais appliquer tout ça à symfony ca doit être lourd! Et bien nan, Propel dans sa dernière version (1.3) intègre déjà cet algorithme en tant que behavior. (Cela sous entend qu’il faut utiliser symfony 1.2)

Pour se faire, on va donc créer un project vierge en 1.2 histoire d’éviter tout parasitage qu’on mènera en 2 parties. La première pour la partie visuel, la deuxième pour la partie code admin generator.

Voici le résultat attendu à la fin de cette première partie:

On se lance donc, notre beau projet est créé, on ouvre le schema.yml que l’on modifie comme ceci:

propel:
  categories:
    _attributes: { phpName: Categories, treeMode: NestedSet }
    id: ~
    titre: { type: VARCHAR, size: '50', required: true }
    tree_left: { type: INTEGER, size: '11', required: true, nestedSetLeftKey: true }
    tree_right: { type: INTEGER, size: '11', required: true, nestedSetRightKey: true }
    tree_parent: { type: INTEGER, size: '11', required: true }

Vous noterez donc l’ajout du treeMode et la définition des nesetSetLeftKey et nestedSetRightKey, le tree_parent, n’est là que pour un certain confort à l’affichage, mais pas indispensable.

Votre schema ainsi terminé (vous pouvez y rajouter d’autres tables, même pas peur), on construit la base correspondante (en ayant au préalable configuré notre database.yml évidemment:

php symfony propel:build-all

Et là on constate dans notre dossier lib, deux nouvelles classes que vous n’avez sans doute jamais vu:

- BaseCategoriesNestedSet
- BaseCategoriesNestedSetPeer
qui viennent se placer entre entre les classes classiques et les classes « Base »

Afin de jouer rapidement, on va ajouter quelques valeurs test dans data/fixtures/fixtures.yml comme suit:

Categories:
  cat_1:
    titre: root
    tree_left: 1
    tree_right: 10
  cat_2:
    titre: Hi-Tech
    tree_left: 2
    tree_right: 7
  cat_3:
    titre: Developpement
    tree_left: 3
    tree_right: 4
  cat_4:
    titre: Internet
    tree_left: 5
    tree_right: 6
  cat_5:
    titre: Culture
    tree_left: 8
    tree_right: 9

que l’on va charger dès à présent:

php symfony propel:data-load

A noter que la notion de root est ici très importante. En effet, j’ai choisi délibérément de travailler avec un seul scope (une seule racine) pour la simple et bonne raison que les manipulations entre scope sont très limitées et l’intérêt et de pouvoir y faire tout et n’importe quoi. Il nous faut donc un élément parent de tous, que l’on ne modifiera jamais, que l’on n’affichera jamais.

Maintenant, les choses sérieuses commencent. On va commencer par générer un module admin generator:

php symfony generate:app main
php symfony propel:generate-admin main Categories

Et vous devriez arriver via http://monlocal/categories sur quelque chose d’assez classique:

L’idée est maintenant d’inclure un plugin jquery qui va matérialiser notre arbre, propel ne s’occupant évidemment que de la logique métier.
J’ai choisi le très bon NestedSortable qui répond très bien en terme de performance et très flexible à configurer. Vous pouvez donc télécharger la dernière version. Seul bémol, il nécessite Interface, un équivalent à jquery UI, que l’on va donc télécharger également.
Pour jQuery, on laissera google faire.

On a donc nos js comme ceci:

et on les intègre à notre projet via notre view.yml (la notation en ligne étant plus claire à mon goût):

  javascripts: 
    - http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js
    - interface.js
    - inestedsortable-1.0.1.pack.js

On va devoir maintenant modifier un peu quelques partials car le plugin jquery nécessite une imbrication de tag html, ici on utilisera ce qui semble être le plus apte sémantiquement parlant, des couples ul/li.

L’idée est donc d’afficher tout l’arbre quelque soit le nombre d’élément et de n’afficher que l’info qui nous interesse, en l’occurrence le titre. Première chose, voici la modification sur le generator.yml:

      list:
        peer_method: retrieveTree
        max_per_page: 99999
        display: [titre]

Vous n’avez maintenant plus qu’un seul élément affiché dans votre tableau, l’élément root et c’est normal.

La suite se passe dans le partial _list.php. Rapide brief pour ceux qui n’ont jamais modifier un partial de l’admin generator. On récupère la version qui est dans le dossier cache/[APP]/[ENV]/modules/auto[MODULE]/templates et on la copie dans notre dossier templates de notre module généré.

Une fois cette opération effectuée, rien n’a du changer, mais maintenant on a la possibilité de modifier le partial, et voici un extrait de ce qu’il faut modifier dans la balise tbody:

     <tbody>
        <tr>
            <td class="container_main_list" colspan="3">
              <?php foreach ($pager->getResults() as $i => $item): ?>
                <?php include_partial('categories/tree',array('tree' => $item, 'i' => $i, 'helper' => $helper)) ?>
              <?php endforeach; ?>
            </td>
        </tr>
      </tbody>

Puis dans la partie script tout en base (vous pouvez retirer l’ancienne fonction checkAll, on ne pourra plus s’en servir:

<script type="text/javascript">
/* <![CDATA[ */
$(document).ready(function()  {
  $('#main_list').NestedSortable(
    {
      accept: 'item_list',
      opacity: 0.6,
      autoScroll: true,
      revert: true,
      nestingPxSpace: '15',
      handle: '.sort-handle',
      currentNestingClass: 'current-nesting',
      noNestingClass: 'sf_admin_td_actions',
      onChange: function(serialized) {
	$('#hashValue').val(serialized[0].hash);
      } 
    }
  );
});
/* ]]> */
</script>

Bon si vous avez suivi, vous vous doutez que si vous actualisez, symfony vous dira gentiment qu’il manque le partial _tree.php. Et bien créons le! C’est la base même du tuto, car c’est un partial récursif, qui va donc s’auto inclure:

<ul <?php echo (!empty($i)?'id="main_list" ':'')?>class="page-list">
  <?php foreach($tree->getChildren() as $node): ?>
    <li class="item_list clear-element" id="ele-<?php echo $node->getPrimaryKey() ?>">
      <div class="sort-handle">
        <?php echo $node->getTitre() ?>
			</div>
      <?php if ($node->hasChildren()): ?>
            <?php include_partial('categories/tree',array('tree' => $node, 'helper' => $helper)) ?>
      <?php endif; ?>
    </li>
  <?php endforeach; ?>
</ul>

Et là, un petit coup de F5 et la magie comment à opérer. Vous pouvez maintenant déplacer les éléments de branche en branche tel un hibou… bref, ca fonctionne!

Un petit coup de css s’impose pour que ca se rapproche le plus possible des autres modules classiques:

#sf_admin_container table tr:hover {
	background-color: #FFF;
}
 
ul#menu li{
	list-style: none;
	display: inline;
	padding: 0 10px 0 0 ;
}
 
#admin_content ul {
	margin: 0;
	list-style-position: inside;
}
 
#admin_content ul#list-container {
	margin-left: 1em;
	background-color: #FFF ;
	padding: 10px ;
}
 
#admin_content ul li {
	list-style-position: inside;
}
 
li img {
	vertical-align: text-bottom ;
}
 
#list-container li span {
	cursor: pointer;
}
 
#sortHelper {
	background: #FFE;
}
 
#dragHelper {
	background-color: #EEE;
}
 
div.wrap {
	border:1px solid #BBBBBB;
	padding: 1em 1em 1em 1em;
}
#main_list,#contenu_list {
	width: 700px;
}
 
#main_list li {
	list-style-type: none;
	list-style-position: none;
}
 
.page-list {
	list-style: none;
	margin: 0;
	padding: 0;
	display: block;
}
 
.clear-element {
	clear: both;
	position: relative;
}
 
.sort-handle {
	cursor:move;
	margin: 0.25em 0 0 0;
	padding: 2px 0 2px 18px;
	background: #f3F3F3 left center url(../images/toggleexpanddark.png) no-repeat;
}
 
div.item-title {
	background-color: #DDD;
	margin: 0.25em 0 0 0;
	padding: 2px 0 2px 18px;
}
 
.list-action {
	/*background-color: #f3F3F3;*/
	position: absolute;
	right: 0; top:0;
	width: 350px;
}

Et l’image qui va bien (récupéré de redotheoffice):

Et voilà, la première étape s’achève ici, on peut s’amuser à déplacer ces éléments. La suite très prochainement, pour remettre les actions et ajouter une action pour sauvegarder l’arbre.

A noter que je ne détaille pas forcément toutes les étapes de création d’un projet symfony, Jobeet le fais si bien.

Évidemment, toutes remarques, questions, propositions, meilleurs solutions sont les bienvenues! Je suis aussi là pour apprendre : )

Là où la virtualisation se banalise grâce à des logiciels comme VirtualBox, certains utilisent encore des émulateurs dont le célèbre ie4linux.

Et bien, l’alternative pour Mac OS X existe, preuve que la pomme a quand même bien fait les choses. Et pour l’installer rien de plus simple.

Commençons par s’assurer que nous disposons de X11 qui sera utilisé pour afficher la fenêtre de notre futur IE6. Si vous ne l’avez pas spécifié à l’installation de Léopard, il faudra l’installer via Xcode, mais que tout bon développeur sous Mac aura déjà installé. L’application X11 devrait donc se situer dans Applications > Utilitaires

Ensuite, installer Darwine (via un joli .dmg et un simple glissez/déposer à la mac), qui n’est d’autre qu’un portage de Wine sur Mac OS X.

Maintenant tous les exe seront ouvert via Darwine. Il ne vous reste plus qu’à installer ie4osx et voilà le travail:

Alors ça reste moche hein, Mac ne fait pas de miracle, mais ca permet de dépanner rapidement pour des tests bateau, quand vous ne faites qu’assurer le service minimum pour ce navigateur ;)

Mais ce n’est pas toujours simple. Voici un petit exemple qui concerne un passage obscur de la documentation officielle des formulaires dans symfony, l’upload de fichier.

Pour commencer, il faut souvent définir dans la définition de notre formulaire le widget et le validator correspondant. Dans notre exemple, on prendra un champ nommé avatar, imaginons un classe Profil:

public function configure()
{
    $this->widgetSchema['avatar'] = new sfWidgetFormInputFile();
    // Un upload étant rarement obligatoire, 
   // le cas de l'avatar est un bon exemple, on le rend facultatif ici
    $this->validatorSchema['avatar'] = new sfValidatorFile(array('required' => false)) ; 
}

Maintenant on a bien notre formulaire qui s’affiche correctement. Le problème, si on n’upload pas de nouvel avatar, à la prochaine sauvegarde, le champ avatar sera remis à sa valeur par défaut, fonctionnement tout à fait normal en l’état.
Pour éviter ceci, voici la fonction à rajouter, toujours dans notre classe de notre formulaire Profil, c’est en fait une surcharge de la méthode save:

public function save($con = null)
{
    // On test si le champ avatar a été renseigné dans le formulaire
    if ($file = $this->getValue('avatar'))
    {
      // Si oui, on sauvegarde le fichier
      $filename = 'nomDuFichier';
      $extension = $file->getExtension($file->getOriginalExtension());
      $file->save(sfConfig::get('sf_upload_dir').$filename.$extension);
    }
    else
    {
      // Si non, on récupère la version actuelle dans l'objet Père (ici profil), 
      // que l'on insère dans le tableau de valeur du formulaire
      $this->values['avatar'] = $this->getObject()->getAvatar();
    }
 
    // Puis on lance la sauvegarde normal de la classe mère
    return parent::save($con);
}

Et voilà, nous sommes restés dans la logique métier de symfony, en surchargeant l’existant et surtout en permettant de garder notre action identique, les modifications ayant été apportées dans le modèle.

Mais quel choc quand on a le malheur de lancer le terminal mac dans sa configuration de base:

Assez tristounet, aucune couleur et le panel de configuration est peu enclin à nous aider efficacement. Et pourtant, quand on sait que mac os x est construit sur une base unix, il serait dommage de se priver d’un terminal qui pourrait se révéler très utile, surtout pour un développeur comme moi.

On va donc se lancer dans un petit tuning de terminal.

Première étape, si vous ne l’avez pas déjà fait, il va falloir installer MacPort, pour ceux qui ne connaissent pas, c’est un gestionnaire de paquet un peu comme l’est APT pour debian/ubuntu.

Une fois MacPort dans la place, on va justement se servir de notre cher terminal et installer le paquet coreutils grâce à la ligne suivante:

sudo port install coreutils +with_default_names

Une fois l’installation complète (attention elle peut prendre un peu de temps), on va pouvoir commencer le tuning.

Première chose, le fond blanc n’est pas l’idéal surtout que les autres couleurs à notre disposition seront aussi assez claires. Il suffit pour ça d’aller dans les préférences du Terminal > Réglages > Fenêtre et changer la couleur d’arrière plan. Personnellement j’ai mis noir avec une transparence à 60%, moins flashy pour les yeux.
Voici un petit récap de mes autres paramètres à affiner selon vos souhaits:

On continue en éditant le profil de notre terminal grâce au fichier ~/.bash_profile. L’idéal serait de se faire la main avec VIM mais n’importe quelle éditeur ira très bien. A noter que si vous n’aviez jamais mis le nez dans le terminal, il est probable que le fichier n’existe pas. Aucun souci pour le créer.

Je vous met ici mon fichier, rien d’énorme juste des couleurs que je trouve agréables, le listing des couleurs disponibles est plus bas:

export PATH=/usr/local/mysql/bin:/sw/bin:/sw/sbin:/opt/local/bin:/opt/local/sbin:$PATH
export MANPATH=/opt/local/share/man:$MANPATH
 
# Couleurs du préfix du terminal
NM="\[\033[0;38m\]" 
HI="\[\033[0;37m\]" 
HII="\[\033[0;36m\]" 
SI="\[\033[0;33m\]"
IN="\[\033[0m\]"
 
export PS1="$NM[ $HI\u $HII\h $SI\w$NM ] $IN"
 
if [ "$TERM" != "dumb" ]; then
    export LS_OPTIONS='--color=auto'
    eval `dircolors ~/.dir_colors`
fi
 
# alias
alias ls='ls $LS_OPTIONS -hF'
alias ll='ls $LS_OPTIONS -lAhF'
alias cd..="cd .."
alias c="clear"

Puis le fichier ~/.dir_colors

# Below, there should be one TERM entry for each termtype that is colorizable
TERM linux
TERM linux-c
TERM mach-color
TERM console
TERM con132x25
TERM con132x30
TERM con132x43
TERM con132x60
TERM con80x25
TERM con80x28
TERM con80x30
TERM con80x43
TERM con80x50
TERM con80x60
TERM xterm
TERM xterm-color
TERM xterm-debian      
 
# Below are the color init strings for the basic file types. A color init
# string consists of one or more of the following numeric codes:
# Attribute codes:
# 00=none 01=bold 04=underscore 05=blink 07=reverse 08=concealed
# Text color codes:
# 30=black 31=red 32=green 33=yellow 34=blue 35=magenta 36=cyan 37=white
# Background color codes:
# 40=black 41=red 42=green 43=yellow 44=blue 45=magenta 46=cyan 47=white
NORMAL 00	# global default, although everything should be something.
FILE 00 	# normal file
DIR 01;36 	# directory
LINK 01;37 	# symbolic link.  (If you set this to 'target' instead of a
           	# numerical value, the color is as for the file pointed to.)
FIFO 40;33	# pipe
SOCK 01;35	# socket
DOOR 01;35	# door
BLK 40;33;01	# block device driver
CHR 40;33;01 	# character device driver
ORPHAN 40;31;01 # symlink to nonexistent file
 
# This is for files with execute permission:
EXEC 01;35
 
# List any file extensions like '.gz' or '.tar' that you would like ls
# to colorize below. Put the extension, a space, and the color init string.
# (and any comments you want to add after a '#')
 
# If you use DOS-style suffixes, you may want to uncomment the following:
#.cmd 01;32 # executables (bright green)
#.exe 01;32
#.com 01;32
#.btm 01;32
#.bat 01;32
 
.tar 01;31 # archives or compressed (bright red)
.tgz 01;31
.arj 01;31
.taz 01;31
.lzh 01;31
.zip 01;31
.z   01;31
.Z   01;31
.gz  01;31
.bz2 01;31
.deb 01;31
.rpm 01;31
.jar 01;31
.dmg 01;31
 
# image formats
.jpg 01;34
.png 01;34
.gif 01;34
.bmp 01;34
.ppm 01;34
.tga 01;34
.xbm 01;34
.xpm 01;34
.tif 01;34
.png 01;34
.mpg 01;34
.avi 01;34
.fli 01;34
.gl 01;35
.dl 01;35
 
# source code files
.pl 00;33
.PL 00;33
.pm 00;33
.tt 00;33
.yml 00;33
.sql 00;33
.html 00;33
.css 00;33
.js 00;33

On obtient alors ceci:

C’est déjà plus agréable mais il manque la geek touch. Pour arranger ça, on va rendre notre terminal accessible tout le temps, avec un style quake like.

Pour ce faire, première chose, installer SIMBL. Une application, qui permet ensuite de faire des plugins pour des applications cocoas (comme notre terminal). Une fois installé, téléchargez visor, un plugin SIMBL.

Voilà, killez votre terminal s’il est encore ouvert et quand vous le relancez, celui-ci ne s’ouvre pas mais un petit icone est apparu dans votre menubar:

Choisissez « Visor Preferences… », définissez le raccourci que vous souhaitez et testez! Voilà, plus besoin de fermer votre terminal, celui-ci se range dans votre menubar. Pour les sceptiques, une petite vidéo du résultat:

Attention, un petit bonus s’est caché dans ce billet.

Il vous suffit d’activer le partage web pour lancer l’apache et une ligne à décommenter dans le php.ini pour bénéficier du support de PHP5 et ce sans rien faire de plus.

Cette combinaison suffit la plupart du temps, mais dès qu’il faut rajouter un module, librairie, PHP, ca devient vite compliqué. Que se soit GD ou ZIP, il est rarement simple, sans aucune recompilation d’installer ces librairies, pourtant assez classiques sur votre mac.

Et bien, un monsieur l’a compris, Marc Liyanage, qui maintient des versions de PHP5 recompilées pour mac avec toutes les options.

Pour l’installer, rien de compliqué, lancer un terminal puis si vous souhaitez faire un backup de votre version actuelle de PHP.

sudo mv /usr/local/php5 ~/Desktop/php5.old

Puis placez vous dans votre dossier de téléchargement habituel et télécharger la dernière version et dézippez là là où se trouvait l’ancienne.

wget http://www2.entropy.ch/download/php5-5.2.5-6-beta.tar.gz
tar -xzf php5-*-beta.tar.gz
sudo mv php5 /usr/local/

Il faut ensuite changer rajouter la conf de cette nouvelle version à notre apache

sudo ln -sf /usr/local/php5/entropy-php.conf /etc/apache2/other/+entropy-php.conf

Et on redémarre apache

sudo apachectl restart

Voilà, vous pouvez jeter un oeil à un phpinfo(), vous disposez maintenant de toutes les options pour votre PHP5.

Cependant il n’est pas rare qu’elles gâchent la lisibilité d’un code quand elles s’imbriquent ou quand les différents états sont à plusieurs dizaines de lignes d’écart.

Un moyen simple d’y voir plus clair et de tourner vos conditions différemment.

Par exemple, on a souvent tendance à écrire:

<?php
if ($condition) {
    /* Tout mon traitement qui peut faire plusieurs dizaines de ligne */
} else {
    /* Traitement de l'erreur, par exemple */
    return false ;
}
?>

Au final, la condition n’est utilisée que pour gérer le cas d’erreur, mais celui-ci se retrouve retranché en bas de script.

Pour gagner en lisibilité, on pourrait donc écrire:

<?php
if (!$condition) {
    /* Traitement de l'erreur, par exemple */
    return false ;
}
/* Tout mon traitement qui peut faire plusieurs dizaines de ligne */
?>

La gestion de notre erreur, est maintenant dans la continuité de notre script et se révèle beaucoup plus confortable à lire. Attention toutefois, ce genre de pratique demande à ce que votre gestion d’erreur coupe l’exécution du script avec en général l’utilisation de return.