Création de nouveau formulaire facilement avec Zend Form Maker

La création de formulaire avec zend framework peut être facilitée grâce à un petit développement : Zend Form Maker. Projet disponible sur github. À la base créer pour des besoins scolaires, sarlak a eu la bonne idée de rendre le dev open source sous licence GPL 3.0.

Le but du logiciel est de permettre via une interface très simple d’accès, de créer des formulaires et ensuite de forger une classe PHP, basé sur zend framework afin d’obtenir un formulaire tout frais moulu. Ultra pratique, et ultra simple, et surtout cela fait gagner un temps de dingue!

Pour l’installer, il vous faut de quoi faire fonctionner zend framework (celui-ci doit être installé). Sous Unix cela donnera ceci :

git clone https://github.com/sarlak/Zend-Form-Maker.git
ln -s pathToYourZFLibrary
chmod 0777 Zend-Form-Maker/public/resources/xml
chmod 0777 Zend-Form-Maker/public/resources/form_made

Bien entendu, à peu de choses près ceci est adaptable sous MS-Windows

Pour créer votre premier formulaire, il vous suffit de vous rendre sur l’URL adéquate, aller sur « form list » et « Bazinga! ». Une démo existe en ligne!

Une petite capture d’écran :

À noter que j’ai corrigé un ou deux petits trucs qui me dérangeaient, il y a un bout de temps.

Git, gitolite et mutualisé OVH

/!\ pour la version 3 pensez à lire ceci.

Hello,
Sur les mutualisés OVH, la version fournie de git est plus qu’out-of-date : version 1.4.4. Ceci signifie impossibilité d’installé des outils tels que gitolite ou inferno. Ce billet est l’occasion d’un guide pour installer gitolite.

Le guide suivant a été rédigé sur un compte OVH pro, donc avec accès un ssh. En utilisant git 1.7.6 et gitolite 2.0.3. L’ensemble exécuter sur une machine Linux.

Téléchargement

La première étape, consiste a récupérer les différentes archives nécessaires, a savoir git et gitolite.

Pour git, il vous suffit de prendre la dernière version http://git-scm.com/download.

Pour gitolite, il suffit d’utiliser git!

git clone https://github.com/sitaramc/gitolite.git

Préparation de l’environnement

Nous allons installer les exécutables de git dans ~/opt/bin. De ce fait ajoutons le path a l’utilisateur ssh.
Ouvrir ~/.bash_profile et modifier le path. Pour ce faire ajouter, avant le export :

PATH=$HOME/opt/bin:$PATH

Installation de git

Uploader votre archive dans un dossier (ici ~/opt/src/). En mode console par ssh, donc sur le serveur, ouvrir l’archive et compiler les sources.

tar -xvzf git-1.7.6.tar.gz
cd git-1.7.6
./configure --prefix=$HOME/opt --without-tcltk
make
make install

Une fois compilé, les exécutables seront présents dans ~/opt/bin. Pour vérifier, que tout est bien en place :

git --version

Gitolite

Il faut se rendre dans le répertoire du clone du repository. Tout s’exécute uniquement sur la machine cliente (donc pas chez ovh). Si l’utilisateur est « toto », l’host « tata.com » et le futur administrateur « moiadmin »

./src/gl-easy-install toto tata.com moiadmin

Il suffit de faire enter. Dans tous les cas (mise à jour du script compris!), le fait de réexecuter la commande permet de rectifier les erreurs éventuelles. À l’étape de l’édition du fichier de configuration, il faut modifier la variable $GIT_PATH pour quelle pointe vers le répertoire contenant notre git. Dans notre cas :

$GIT_PATH = $ENV{HOME} . "/opt/bin/";

Configuration de Gitolite

La configuration de gitolite est simple et s’exécute avec … git! En principe, un répertoire reprenant la config a été créé sur votre home dans ~/gitolite-admin, dans le cas contraire, il vous suffit de faire

git clone gitolite:gitolite-admin.git

Pour ajouter des clefs ssh, il suffit de les mettre dans le dossier keys. Pour ce qui est de la config, il vous suffit d’éditer le fichier gitolite.conf et puis de faire

git add conf/gitolite.conf
git commit -m 'update config'
git push

Et c’est tout!

Sources :
http://forum.ovh.com/showthread.php?t=71543
http://blog.lyrixx.info/admin-sys/installer-gitolite-sur-une-machine-debian-5/
http://sitaramc.github.com/gitolite/doc/gitolite.rc.html
http://sitaramc.github.com/gitolite/doc/gitolite.conf.html#_groups

Pour vos interfaces web, trois solutions correctes :
CGit
View Git
Indefero

SQL : différences entre LEFT JOIN, RIGHT JOIN, etc

J’ai toujours eu quelques diffuculté a bien visualisé les différence qu’il y avait entre left join, right join, join, etc lorsque je fait des requêtes SQL. Aujourd’hui je suis tombé sur un exemple frappant, et je me suis dit que cela pouvait en aider plus d’un! Comme une image vaux mieux qu’un long discours, en voici l’essence.

L’exemple suivant se base sur une base de donnée mysql :

CREATE TABLE IF NOT EXISTS `acl_roles` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(30) CHARACTER SET utf8 NOT NULL,
`build_on` int(11) unsigned DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `build_on` (`build_on`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

INSERT INTO `acl_roles` (`id`, `name`, `build_on`) VALUES
(1, 'guest', NULL),
(2, 'normal', 1),
(3, 'modo', 2),
(4, 'admin', 3);

ALTER TABLE `acl_roles` ADD CONSTRAINT FOREIGN KEY (`build_on`) REFERENCES `acl_roles` (`id`) ON DELETE CASCADE ON UPDATE CASCADE;

Nous avons donc une table avec des clefs de référence pour marquer les dépendance entre les roles. En images cela donne ceci :

id name build_on
1 guest NULL
2 normal 1
3 modo 2
4 admin 3

Maintenant regardons le résultats de divers SELECT, le résultat parle de lui-même.

SELECT ar.*, arp.name AS parent_name FROM acl_roles ar, acl_roles arp WHERE arp.id = ar.build_on

id name build_on parent_name
2 normal 1 guest
3 modo 2 normal
4 admin 3 modo

SELECT ar.*, arp.name AS parent_name FROM acl_roles ar LEFT JOIN acl_roles arp ON arp.id = ar.build_on

id name build_on parent_name
1 guest NULL NULL
2 normal 1 guest
3 modo 2 normal
4 admin 3 modo

SELECT ar.*, arp.name AS parent_name FROM acl_roles ar JOIN acl_roles arp ON arp.id = ar.build_on

id name build_on parent_name
2 normal 1 guest
3 modo 2 normal
4 admin 3 modo

SELECT ar.*, arp.name AS parent_name FROM acl_roles ar RIGHT JOIN acl_roles arp ON arp.id = ar.build_on

id name build_on parent_name
2 normal 1 guest
3 modo 2 normal
4 admin 3 modo
NULL NULL NULL admin

J’espère que l’exemple servira a certain et que cela en aidera plus d’un!

ZF : ACL et ressources multiple

Lorsque l’on utilise des ACL dans Zend Framework, une chose assez embêtante est de devoir tout mettre en place1. Pour ma part, j’ai par facilité voulu ajouté le support de ressource multiple.

Avant de commencer, il convient de contextualisé les choses, les ACL de ZF pouvant être utilisé de bien des manière.

Dans le cas qui nous intéresse, j’ai simplement défini ceci :

  • les ressources2 = module.controller
  • les privilèges3 = action

Ce que je voulait c’est pouvoir définir une ressource pour tous les contrôleurs. La syntaxe évidente qu’il m’est venu est la suivante : module.*

Dans ma classe qui étend Zend_ACL j’ai simplement fait ceci :

    public function isAllowed($role = null, $resource = null, $privilege = null)
    {
    	if (null === $resource)
    		return parent::isAllowed($role, $resource, $privilege);
 
    	$resources = $this->getResourcesPossibility($resource);
    	foreach($resources as $resource)
    	{
    		if ($this->has($resource) && parent::isAllowed($role, $resource, $privilege))
    		{
    			return true;
    		}
    	}
    	return false;
    }
 
    public function getResourcesPossibility($resource = null)
    {
    	$ret = array($resource);
    	if (null !== $resource)
    	{
    		$resources = explode('.', $resource);
    		$cptRessources = count($resources);
    		if ($cptRessources >= 2)
    		{
    			$resources[ $cptRessources - 1 ] = '*';
    		}
    		$ret[] = implode('.', $resources);
    	}
    	return $ret;
    }

Ceci peut bien entendu être enrichi mais permet au moins de profiter de l’utilisation des ACL dans le menu et sur des aides de vue qui serait éventuellement définie comme expliqué dans la plupart des tutoriaux.

Pour en savoir plus sur les ACL et Zend Framework, je vous renvoi a un très bon article.

  1. surtout si on utilise l’aide de vue pour généré un menu (Zend_navigation)
  2. resource
  3. privilege

ZF : module et autoloader

Avec Zend Framework, lorsque l’on travail un projet conséquent il devient vite utile de travailler avec le mécanisme des modules. Celui-ci permet d’étendre pas mal de chose et surtout une séparation poussée en … module.

Le problème de ce mécanisme1 est qu’il faut définir le chemin pour le chargement automatique à l’aide de ceci :

$autoloader = new Zend_Application_Module_Autoloader(array(
	'namespace' => 'SuperModule',
	'basePath'  => 'path to super module',
));

Je vous propose donc de faire une petite amélioration afin que ce chargement soit fait automatiquement.

Avant tout, dans votre configuration (ici en .ini) vous devez au moins avoir ceci de présent :

resources.frontController.moduleDirectory = APPLICATION_PATH "/modules"
resources.modules =

Ensuite, à la base de chaque dossier module créer un fichier Bootstrap.php2 :

<?php
class SuperModule_Bootstrap extends Grummfy_Bootstrap{}
# EOF

Et pour finir créer le fichier3 library/Grummfy/Bootstrap.php

<?php
 
abstract class Grummfy_Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{
	protected function _initAutoload()
	{
		$className = get_class($this);
		$zf_namespace = explode('_', $className);
		$reflector = new ReflectionClass($className);
		$autoloader = new Zend_Application_Module_Autoloader(array(
			'namespace' => $zf_namespace[0],
			'basePath'  => dirname($reflector->getFileName()),
		));
		return $autoloader;
	}
}
 
# EOF
  1. sauf si j’ai loupé un truc…
  2. ne pas oublier de changer le nom du module …
  3. n’oubliez pas de déclarer le « namespace » Grummfy ou bien d’inclure le fichier