Configuration d'un module

Publié par Jonathan Demoutiez Jeu 26 juil 2007 08:32:00 GMT

Comme expliqué précédemment, une application va permettre de distinguer divers grand point de notre projet (Back/Front/...). Un module lui va définir les diverses actions (Accueil/Inscription/...).

Remarque : L’action par défaut d’un module est ‘index’.

Un module contient également un dossier ‘config’ (vide par défaut), on peut y ajouter les mêmes scripts de configuration que contient une application et ainsi définir des spécificités propres à un module qui peuvent différer de l’application. (Exemple : dire qu’un module ne doit pas utiliser le layout; sécuriser le module; utiliser des filtres différents; ...). La configuration de l’application est donc la configuration par défaut de chacun des modules.

Publié sous  | Mots clés  | aucun commentaires

Le principe M.V.C.

Publié par Jonathan Demoutiez Jeu 26 juil 2007 08:22:00 GMT

Modèle – Vue – Controleur

A l’exécution d’une requête, le Controleur est appelé et pourra intéragir avec le Modèle, il envoie ensuite les données à la Vue correspondante qui n’aura plus qu’à structurer la page à afficher.

Symfony M.V.C.

Publié sous  | Mots clés  | aucun commentaires

RJS introduction

Publié par Nico Mar 24 juil 2007 12:05:00 GMT

RJS is a powerful type of template used in Rails to generate Javascript code from the server-side. This code will be sent to and executed by the browser.

This generated Javascript code is written in Ruby and allows you to update multiple elements in the page very easily without reloading it.

In this article I’m going to show you how RJS works using a concrete example.

Real-world application

Let’s say that you have a TODO-list with a form that can be used to add a new task. When you add a new task you want to append this task to your existing list, use a visual effect to show that a task has been added and reset the form.

RJS is perfect for this kind of task, you just have to create a file named after your action name that is adding your task to the database. For example, if my action is add_task, I’m going to create a file named add_task.rjs.

My add_task action is creating an instance variable @task, so my RJS file should be something like :

page.insert_html :bottom, 'tasks_div', :partial => 'task'
page.visual_effect :highlight, 'tasks_div'
page.form.reset 'add_task_form'

The page object is actually generated by Rails and is an instance of the Rails JavaScriptGenerator. This page object translates your Ruby code to Javascript.

First, we ask Rails to insert the resulting content into the bottom of the tasks_div <div>. So the first parameter is the position where the new content will be inserted.

The second parameter is the id of the element that will be modified.

The third parameter can either be a string literal or hash that corresponds to the options you can pass to render method. In this exemple we’re asking Rails to render the partial _task.rhtml.

After that we are applying a visual effect to the <div> that has been modified. To do this, we’re using visual_effect. The first parameter is the name of the effect to use, the second one is the id of the element on which we want to apply this effect.

The last line is used to reset the form with the id add_task_form so all the fields of this form are cleared.

Using these basics and reading the Rails API, you can start doing AJAX / RJS.

What can I do with RJS?

Anything! or almost anything you want to be dynamic

The Page object provides many methods to manipulate Javascript using simple and clear Ruby code.

These helpers are :
  • << : writes raw JavaScript to the page
  • alert : displays an alert dialog
  • assign : assigns a value to a JavaScript variable
  • call : calls a JavaScript function
  • delay : executes the content of the given block after a delay
  • draggable : creates a script.aculo.us draggable element
  • drop_receiving : creates a script.aculo.us drop receiving element
  • hide : hides the given DOM elements
  • insert_html : inserts HTML at the specified position for the given DOM element
  • redirect_to : redirects the browser to the given location
  • remove : removes the given DOM elements from the page
  • replace : replaces the outer HTML of the given DOM element
  • replace_html : replaces the inner HTML of the given DOM element
  • select : returns a collection reference by finding it through a CSS pattern in the DOM
  • show : shows the given DOM elements
  • sortable : creates a script.aculo.us sortable element
  • toggle : toggles the visibility of the given DOM elements
  • visual_effect : starts a script.aculo.us visual effect
  • [] : returns an element reference by finding it through id in the DOM

Debugging RJS

When you’ll come to using RJS (and Javascript) a lot, you’ll definitely have to debug it. There are some powerful tools that can help you out and save you a lot of time (and headaches).

First of all, Rails provides a few built in tools to get your bugs resolved quickly. In development mode you have access to a lot of information in the log file.

If an unhandled exception is raised, you’ll get an error page rather than the expected one. This error page gives you information about the file that has raised the exception, on which line, etc.

Alert boxes will popup too.The first one tells you what is the exception and the second one shows you the generated javascript code that raised the exception.

The last tool to debug your RJS / Javascript code is Firebug. Firebug is a plugin for firefox which include a DOM inspector, a Javascript console, an XMLHttpRequest logger and a command-line javascript interpreter.

Conclusion

As you can see it’s very easy to implement Ajax features with Rails and RJS templates. You can really do a lot of things using RJS, this article only scratch the surface of RJS capabilities. Be sure that if you try it, you’ll implement some AJAX functionnalities in all your future projects.

Have fun!

Publié sous  | Mots clés ,  | aucun commentaires

Configuration générale d'une application

Publié par Jonathan Demoutiez Mar 24 juil 2007 08:47:00 GMT

Le dossier config de l’application contient les fichiers suivants :

app.yml
cache.yml
config.php
factories.yml
filters.yml
il8n.yml
logging.yml
routing.yml
security.yml
settings.yml
view.yml

Détaillons rapidement les fichiers view.yml et routing.yml pour bien débuter le projet :

view.yml

Ce fichier permet de configurer la vue générale (charte graphique) de l’application :

  • balises metas;
  • les fichiers CSS à inclure;
  • les fichiers JS à inclure;
  • le layout.

Exemple :

default:
http_metas: 
 content-type: text/html

metas:
 title: symfony project
 description: symfony project
 keywords: symfony, project
 language: fr

stylesheets: [main, feuille2]
javascripts: [javascript]
has_layout: on
layout: charte_1

Ici on a défini :

  • les balises « meta » que l’on souhaite;
  • les feuilles de style à utiliser (web/css/main.css, web/css/style.css);
  • les fichiers «javascript» à appeler (web/js/javascript.js);
  • l’utilisation d’un layout « charte_1 » : (apps/NOM_APPLICATION/templates/charte_1.php).

Le layout est ce qui englobe le corps de la page qui sera généré par les modules.

Nous verrons plus tard avec l’utilisation de components comment intégrer des menus dynamiques ou autres…

Voici comment se présente le script du layout :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
  <?php include_http_metas() ?>
  <?php include_metas() ?>
  <?php include_title() ?>

  <link rel="shortcut icon" href="/favicon.ico" />
 </head>

 <body>
  <!-- Code du haut de la page -->
  <!-- Code de l'eventuel menu -->

  <!-- Le corps de la page -->
  <!-- Inclusion du contenu généré par le module d'une action -->

  <?= $sf_data->getRaw('sf_content') ?>

  <!-- ... -->
  <!-- Code du bas de la page -->
 </body>
</html>

routing.yml

Ce fichier va permettre de gérer simplement l’url rewriting. Pour l’instant voyons juste comment modifier le module et l’action par défaut de l’application :

homepage:
 url: /
 param: { module: MODULE_PAR_DEFAUT, action: ACTION_PAR_DEFAUT }

ATTENTION :

Une fois que vous avez modifié la configuration de votre projet, il est indispensable de vider le cache pour que les modifications soient prises en compte.

Vider le cache

  >symfony cc

Publié sous  | Mots clés  | 1 commentaire

Fichier de configuration, Applications & modules

Publié par Jonathan Demoutiez Lun 23 juil 2007 08:05:00 GMT

Le fichier de configuration config/config.php est à modifier selon vos besoins (inclusion de librairies, déclaration de globals, ...) :

// Répertoire de Symfony : "OBLIGATOIRES"
$sf_symfony_lib_dir = '/usr/share/php/symfony';
$sf_symfony_data_dir = '/usr/share/php/data/symfony';

// Définir vos constantes
define ('URL', 'http://domaine');
define ('LIB_DIR', SF_ROOT_DIR . '/lib/');
define ('CGI_BIN', LIB_DIR . '/lib/cgi-bin/');

// Inclure vos librairies
require_once(LIB_DIR . 'functions.inc.php');
require_once(LIB_DIR . 'Email.class.php');

// ...

Génération d’une application et d’un module

Symfony fonctionne avec un système d’applications / modules.

Générer une application

  $>symfony init-app NOM_APPLICATION

Voici l’architecture d’une application générée :

apps/NOM_APPLICATION/config/
apps/NOM_APPLICATION/il8n/
apps/NOM_APPLICATION/lib/
apps/NOM_APPLICATION/modules/
apps/NOM_APPLICATION/templates/

Générer un module

  $>symfony init-module NOM_APPLICATION NOM_MODULE

Voici l’architecture d’un module généré :

apps/NOM_APPLICATION/modules/NOM_MODULE/actions/
apps/NOM_APPLICATION/modules/NOM_MODULE/config/
apps/NOM_APPLICATION/modules/NOM_MODULE/lib/
apps/NOM_APPLICATION/modules/NOM_MODULE/templates/
apps/NOM_APPLICATION/modules/NOM_MODULE/validate/

Lors de la génération de la première application du projet, le fichier index.php (dans le dossier web) va être généré « pointant » par défaut vers cette première application. L’application renvoie alors dans un premier temps vers le module par défaut de symfony.

Remarque : Lors de la génération d’une autre application, un fichier NOM_APP.php sera généré (dans le dossier web). Il faudra donc préciser dans l’URL l’appel d’autres applications : 
  http://domaine/NOM_APP.php/

Aussi il existe un mode développement (debug) que l’on peut atteindre en passant par le fichier “NOM_APPLICATION_dev.php”

en mode prod 
  define('SF_ENVIRONMENT', 'prod');
  define('SF_DEBUG',       false);
en mode dev 
  define('SF_ENVIRONMENT', 'dev');
  define('SF_DEBUG',       true);

Publié sous  | Mots clés  | aucun commentaires

Démarrer un projet Symfony

Publié par Jonathan Demoutiez Ven 20 juil 2007 14:10:00 GMT

Symfony nous offre donc la possibilité de créer rapidement un projet via la commande `symfony` :

$> symfony init-project NOM_PROJET

Ceci va permettre de générer l’architecture de dossier vu précédemment ainsi que les fichiers de configurations et de bases du projet.

Configurer l’accès à la base de données

Il y a deux fichiers à modifier pour cela :

  • config/propel.ini
propel.targetPackage = lib.model
propel.packageObjectModel = true
propel.project = ##NOM_PROJET##
propel.database = mysql
propel.database.createUrl = mysql://HOTE/
propel.database.url = mysql://##USER##:##PASS##@##HOTE##/##NOM_BASE##
  • config/database.yml
all:
  propel:
    class:          sfPropelDatabase
    param:
      dsn: mysql://##USER##:##PASS##@##HOTE##/##NOM_BASE##

Configuration d’apache

Il est nécessaire que la configuration d’apache pointe directement vers le dossier web du projet via un ‘VirtualHost’.

01:<VirtualHost *>
02: DocumentRoot /var/www/##NOM_PROJET##/web
03:
04: <Directory />
05:  AllowOverride All
06: </Directory>
07:
08:# Alias /sf /usr/share/php/data/symfony/web/sf
09:
10:# ScriptAlias /cgi-bin/ /var/www/NOM_PROJET/lib/cgi-bin/
11:</VirtualHost>

Il est aussi indispensable d’avoir accès au dossier `sf` (contenu dans Symfony) à la racine du site. Il y a pour cela plusieurs solutions :

  • Créer un Alias dans la configuration d’apache (décommenter la ligne 8 du script ci-dessus).
  • Créer un lien symbolique dans le dossier web vers le dossier sf du projet.
$/web> ln -s /usr/share/php/data/symfony/web/sf
  • Copier le dossier sf dans le dossier web
$/web> cp -R /usr/share/php/data/symfony/web/sf .

Publié sous  | Mots clés  | 4 commentaires

Installation de Symfony

Publié par Jonathan Demoutiez Jeu 19 juil 2007 10:03:00 GMT

Il y a plusieurs solutions pour installer Symfony :

  • Le plus simple est de passer par la bibliothèque PEAR :
  $> pear channel-discover pear.symfony-project.com
  $> pear install symfony/symfony
  • Sinon, les sources sont également disponibles à l’adresse suivante : 
      symfony-project.com

Utiliser la commande `symfony`

Nous aurons régulièrement besoin d’utiliser cette commande pour “diverses générations”; vider le cache; vider les logs; ... .

En passant par PEAR la commande `symfony` sera directement accessible, sinon vous devrez soit :

  • compléter votre variable PATH;
  • créer un lien symbolique dans un de vos dossiers de scripts (à l’installation le script est placé dans `/usr/bin/`);
  • utiliser ”./symfony” (généré à la racine de votre projet).

Bash auto-completion

Il vous suffit de créer un fichier symfony dans :
  • /etc/bash_completion.d/ pour les Debian
  • /etc/profile.d/ pour les RedHat

et d’y mettre le contenu suivant :

_symfony()
{            
  local cur prev action
  COMREPLY=()   
  cur=${COMP_WORDS[COMP_CWORD]}
  prev=${COMP_WORDS[COMP_CWORD-1]}
  action=${COMP_WORDS[1]}

  case "$prev" in
    init-module|propel-generate-crud|propel-init-crud|propel-init-admin)
      COMPREPLY=( $( compgen -W "$( ls -1 apps 2>/dev/null| sed -e 's/ /\\ /g' )" -- $cur ))
      return 0
    ;;
    init-project)
      COMPREPLY=( $( compgen -W "$(  pwd |perl -pe "s/^.*?([^\/]+)$/\$1/g"  )" -- $cur ))
      return 0
    ;;
    init-app)
      COMPREPLY=( $( compgen -W "frontend backend" -- $cur))
      return 0
    ;;    
    symfony)
      COMPREPLY=( $( compgen -W "$( symfony -T | awk '/^  /' | cut -d' ' -f3 )" -- $cur ) )
      return 0
    ;;    
    plugin-install)
    COMPREPLY=( $( compgen -W 'local global' -- $cur ) )
    return 0
    ;;
    global|local)
    COMPREPLY=( $( compgen -W 'symfony/' ) )
    return 0
    ;; 

    *)
      case "$action" in
        propel-generate-crud|propel-init-crud|propel-init-admin)
          if (($COMP_CWORD == 3)); then
            COMPREPLY=( $( compgen -W "$( find lib/model -maxdepth 1 -name '*.php' -exec basename {} .php \; |grep -v Peer\$| tr [:upper:] [:lower:] )" -- $cur ) )
          elif (($COMP_CWORD == 4)); then
            COMPREPLY=( $( compgen -W "$( find lib/model -maxdepth 1 -name '*.php' -exec basename {} .php \; |grep -v Peer\$ )" -- $cur ) )

          fi
          return 0
          ;;
      esac
      return 0
    ;;
      sync)
          if (($COMP_CWORD == 3)); then
            COMPREPLY=( $( compgen -W 'go' -- $cur))
          fi
          return 0
          ;;

  esac

     return 0  
}

complete -F _symfony symfony

Télécharger le script

Publié sous  | Mots clés  | aucun commentaires

L'URL rewriting

Publié par Jonathan Demoutiez Mar 17 juil 2007 10:02:00 GMT

Symfony utilise de l’U.R.L. rewriting comme ceci :

http://domaine/_NOM_ACTION_/_NOM_MODULE_/_NOM_VAR1_/VALEUR1/_NOM_VAR2_/VALEUR2...

Nous remarquons que le passage de variables en méthode ‘GET’ ne va plus s’effectuer avec les caractères : ’?’, ’=’ et ‘&’, mais sera dans la continuité de l’U.R.L. séparé par des ’/’.

Remarque :

L’URL http://domaine/ appellera le module et l’action par défaut que l’on pourra définir (exemple: ‘Accueil/index’), mais si l’on veux passer des variables en paramètre, on sera obligé de les préciser :

http://domaine/Accueil/index/var1/valeur1

et non :

http://domaine/var1/valeur1
ici on appelle la module ‘var1’ et l’action ‘valeur1’, ce qui nous renverra sur une page erreur 404

Publié sous  | Mots clés  | aucun commentaires

Applications & modules

Publié par Jonathan Demoutiez Mar 17 juil 2007 08:15:00 GMT

Un projet Symfony se base sur la création d’applications qui va permettre de séparer par exemple le front-office et le back-office.

Les modules d’une application vont permettre de séparer chaque fonction distincte d’un projet (espace membre; catalogue; paiement; inscription; ...)

Grâce à ce principe nous allons pouvoir obtenir un projet clair et structuré !

Le modèle, généré par propel est commun à toutes les applications, ce qui va nous permettre de pouvoir intéragir avec la base de données dans la totalité du projet. Nous en verrons les GRANDS avantages.

Voici l’architecture d’un projet symfony :

(à la racine)

  • apps/ * Les applications du projet.
  • batch/ * Les tâches automatisées du projet.
  • cache/ * Le dossier de cache (géré par Symfony).
  • config/ * La config général du projet.
  • data/ * Les données de configurations relatives au projet. (Accès BDD…)
  • doc/ * Emplacement de la documentation.
  • lib/ * Contient entre autre le Modèle du projet, mais aussi les librairies communes aux applications.
  • log/ * Emplacement des logs.
  • plugins/ * Emplacement des plugins dédiés à Symfony.
  • test/ * Gestion des tests fonctionnels et unitaires.
  • web/ * Dossier accèssible d’internet il contient “index.php; images; CSS; JS; ...”

Publié sous  | Mots clés  | aucun commentaires

Qu'est ce que Symfony ?

Publié par Jonathan Demoutiez Mar 17 juil 2007 08:08:00 GMT

Symfony est un framework Open Source développé en PHP5. Inspiré de Ruby On Rail, il intégre PROPEL (ORM), CREOLE (Couche d’abstraction de base de données) et Mojavi (implémention MVC).

  • Propel est un ORM, il permet de créer une correspondance entre le monde objet du langage et le monde relationnel de la base de données;
  • CREOLE est une couche d’abstraction de base de données, elle va permettre de gérer n’importe quel gestionnaire de base de données;
  • MVC : Le principe MVC permet de séparer nettement les couches MODELES (Base de données), VUES et CONTROLEURS.

En réutilisant l’existant plutôt que de repartir à zéro, Symfony reste à ce jour l’une des solutions les plus complètes en PHP.

Publié sous  | Mots clés  | aucun commentaires