Dans le cadre du projet Fire Soft Board il a été décidé de créer un dépôts git dédié aux traductions. Pour ce faire il a fallut reprendre els fichiers mais aussi les placer dans des sous répertoires spécifiques. Voici la démarche effectuée.
Continue reading
Tag Archives: trucs et astuces
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!
À 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 :
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.