Mirmo Dynamics - Tag - plugin

sfConsolePlugin, a console plugin for symfony

Geoffrey — Wed, 17 Dec 2008 23:30:00 +0100

I've just release the first beta of my first symfony plugin: sfConsolePlugin. This plugins provides a PHP shell, with tab-completion, history support, and symfony capabilities. To install and use it, you need symfony 1.2 and the readline extension. From your project root:

$ ./symfony plugin:install sfConsolePlugin --release=0.0.2
$ ./symfony console:run

see the README file for more info.

Plugin "related by tags" pour dotclear 2, deuxième

Geoffrey — Mon, 10 Mar 2008 21:48:00 +0100

Après de longs mois d'attente, le related by tags nouveau arrive enfin ! Au menu des réjouissances, une interface de configuration, ainsi qu'un widget font leur apparition. Vous disposez donc désormais de deux manières d'afficher les billets liés, directement en modifiant le template comme avant:

{{tpl:include src="_related_by_tags.html"}}

ou tout simplement en activant le widget correspondant, que vous pouvez configurer comme vous l'entendez. Bien sur, ce widget ne s'affichera que lors de la visualisation d'un billet.

Au chapitre des fonctionnalités / bugfix manquant(e)s, on notera le bug lié à l'utilisation de postgresql, ainsi que la traduction française, qui sera pour plus tard.

Encore une fois, n'hésitez pas à poster tous vos commentaires ici même.

my first rails plugin: named_resources

Geoffrey — Wed, 28 Nov 2007 13:00:00 +0100

It's a simple plugin (2 lines of code beside class and modules declarations) which allows routes created via the map.resources mechanism to be customized. Say you have the following map:

[ruby]
map.resources :members

It will generate routes like:

/members
/members/:id
/members/new

No say you want to i18n your app, in french for example, what do you do ? You just can't out of the box. This is where my plugin enters into action, just add a :route_name parameter to the map.resources call and you're set:

[ruby]
map.resources :members, :route_name => 'utilisateurs'

will generate routes like:

/utilisateurs
/utilisateurs/:id
/utilisateurs/new

It shall also work for nested resources, although I did not test that.

The code is actually pretty simple:

[ruby]
module ActionController
  module Resources
    class Resource
      def path
        route_name = @options.include?(:route_name) ? @options[:route_name] : @plural
        @path ||= "#{path_prefix}/#{route_name}"
      end 
    end 
  end 
end

To install just use script/plugin:

script/plugin install http://tools.assembla.com/svn/riskle/rails/plugins/named_resources

or to install as an svn:external resource:

script/plugin install -x http://tools.assembla.com/svn/riskle/rails/plugins/named_resources

Plugin "related by tags" pour dotclear 2

Geoffrey — Thu, 04 Oct 2007 20:50:00 +0200

update: nouvelle version disponible

Allez hop, j'ai codouillé rapidement aujourd'hui un plugin dotclear 2 pour afficher une liste des billets ayant le ou les mêmes tags que le billet en cours de lecture par l'internaute. Il est téléchargeable dès maintenant sous forme d'archive tar gzipée ou directement de package dotclear. Pour l'utiliser, rien de plus simple, il suffit d'ajouter le tag suivant dans votre template, à l'endroit où vous souhaitez afficher la liste des billets:

{{tpl:include src="_related_by_tags.html"}}

Et voilà c'est tout :-)

Bon par contre, il faut faire gaffe a comment on tag ses billets (genre pour celui là j'ai preferré ne pas le taguer php histoire d'avoir des résultats plus pertinents).

ps: si quelqu'un connait un moyen d'éviter d'avoir a rajouter un bout de code au template je suis preneur (mais j'ai la flemme de chercher là tout de suite).

A Zend controller plugin to enable RESTful behaviour

Geoffrey — Sat, 14 Jul 2007 13:33:00 +0200

This is a simple controller plugin for the Zend Framework which enable RESTful behaviour. It basically adds the HTTP method name to the action name, so that the URL http://example.com/foo/bar will be dispatched to FooController::barGetAction on a GET, FooController::barPostAction on a POST, etc.

Here is the actual code:

<?php

class My_Controller_Plugin_Rest extends Zend_Controller_Plugin_Abstract {

        /**
         * Defines the format of the REST action name
         * Quite useless atm as the dispatcher will strip
         * any non alpha character
         */

        protected $_nameFormat = ':action:method';

        /**
         * Rewrites the action according to the http method
         */

        public function preDispatch() {
                $request = $this->getRequest();
                $restActionName = $this->_translateSpec($this->_nameFormat, array(
                        'action' => $request->getActionName(),
                        'method' => $request->getMethod(),
                ));
                $request->setActionName($restActionName);
        }

        /**
         * Inject values into a spec strings
         *
         * Allowed values are:
         *      :action => the action name
         *      :method => the http method
         *
         * @param string $spec
         * @param array $vars
         * @return string
         */

        protected function _translateSpec($spec, $vars = array()) {
                foreach($vars as $key => $value) {
                        switch($key) {
                                case 'action':
                                case 'method':
                                        $$key = $value;
                                break;
                                default:
                                break;
                        }
                }

                $replacements = array(
                        ':action' => $action,
                        ':method' => $method,
                );

                $value = str_replace(array_keys($replacements), array_values($replacements),$spec);
                return $value;
        }
}

Still, i'm not completly satisfied with this plugin. Plugins certainly allows for powerful control over what's going up in the dispatch process, but the dispatcher itself enforces a set of rules on actions naming (eg, you can't have a _ in it, it is stripped at dispatch time). Thus, I'm wondering on the pertinence of writting a custom dispatcher (read My_Controller_Dispatcher_Rest) instead of just a plugin, which would enable far more possibilities.

Btw, in case you're wondering, the plugins is used like this;

$frontController = Zend_Controller_Front::getInstance();
$frontController->registerPlugin(new My_Controller_Plugin_Rest);

Easy heh ?

Also, I'm not convinced that this plugin is the way to go in matter of RESTful functionnality. I'm still wondering if it would not be better to have urls mapped to a single controller, replacing actions with http methods (that is, http://example.com/foo/bar would map to FooController::getAction, etc).

Any opinions around ?

Zend Framework: Un plugin simple pour le Front Controller

Geoffrey — Sun, 19 Nov 2006 21:30:00 +0100

L'implémentation du Front Controller du Zend Framework inclue un système bien pratique de plugins, qui va nous permettre de réaliser plus simplement et proprement l'automatisation des vues, initialement embarquée dans une extension de Zend_Controller_Action (ce qui pose quelques problèmes, nottament au lors de l'utilisation de __forward() et _redirect()).

Techniquement, un plugin est une classe qui implémente l'interface des plugins (Zend_Controller_Plugin_Interface). Dans la pratique, une classe abstraite est fournie pour simplifier la tache (Zend_Controller_Plugin_Abstract). Notre premier plugin s'appellera AutoView (My_Controller_Plugin_AutoView, stocké dans My/Controller/Plugin/AutoView.php).

Un plugin est donc une classe dont les méthodes seront appelées a différents moments de la dispatch loop du controlleur frontal, comme on peut le voir dans Zend_Controller_Front::dispatch():

routeStartup(), à la mise en route du routeur
routeShutdown($action), à l'arrêt du routeur
dispatchLoopStartup($action), avant la dispatch loop
preDispatch($action), avant d'executer une action
postDispatch($action), après avoir executé une action
dispatchLoopShutdown(), pour finir.

A chaud, on pourrait se dire que postDispatch est exactement ce dont on n'a besoin, et on se tromperait. Ce qu'il faut savoir, c'est que l'argument $action passé à postDispatch contient l'action qui suit celle qui vient d'être executé. Dans la majorité des cas, n'ayant qu'une seule action à executer, $action sera vide, et on se retrouve l'air un peu con.

Bon donc, on va user d'un stratagème: notre plugin va stocker les actions qui passent dans preDispatch, pour s'occuper de la dernière à être passée dans dispatchLoopShutdown. Dernier détail, notre plugin s'occupera lui même de gérer son instance de Zend_View. Et sans plus attendre, le code, qui n'a finalement rien de compliqué:

<?php

require_once 'Zend/Controller/Plugin/Abstract.php';

class My_Controller_Plugin_AutoView extends Zend_Controller_Plugin_Abstract {

	private $_lastAction;

	public function __construct() {
		$view = new Zend_View;
		$view->setScriptPath(APP_ROOT.'/views/');
		Zend::register('view', $view);
	}

	public function preDispatch($action) {
		$this->_lastAction = clone($action);
		return $action;
	}

	public function dispatchLoopShutdown() {
		if (!is_null($this->_lastAction)) {
			$viewPath = sprintf('%s/%s.php', $this->_lastAction->getControllerName(), $this->_lastAction->getActionName());
			echo Zend::registry('view')->render($viewPath);
		}
	}
}

?>

Bien, notre plugin vaillament codé, il nous faut désormais expliquer au controlleur frontal qu'on aimerai bien qu'il en tienne compte. Cela se passe fort logiquement dans le bootstrap, via la méthode registerPlugin du sus-cité controlleur frontal, qui prend en argument une instance d'un objet implémentant Zend_Controller_Plugin_Interface:

$controller = Zend_Controller_Front::getInstance();
$controller->registerPlugin(new My_Controller_Plugin_AutoView);

And viola !