Reprise du message précédent :
Une chose qui serait bien est que vous postiez des exemples car j'ai un peu de mal à concevoir tout ce dont vous racontez Je ne pense pas être le seul
 
MERCI

En lien avec l'affichage, alors.
Genre le controleur passe la langue à la vue, et les fonctions de celle-ci vont retourner des choses différentes en fonction de la valeur du paramètre.

 
Ce que j'utilise pour les images internes
 

function image($path, $file, $alt = null, $title = null) {
    $alt   = is_null($alt)   ? $file : $alt;
    $title = is_null($title) ? ''    : 'title="' . $title . '"';
    return '<img src="' . IMG_ROOT . $path . '/' . $file . '" alt="' . $alt . '" ' . $title . ' />';
}

image('avatars', 'mon_image.jpg');

 
qui me sort un :
 

function image($path, $file, $alt = null, $title = null) {
    $alt   = is_null($alt)   ? $file : $alt;
    $title = is_null($title) ? ''    : 'title="' . $title . '"';
    return '<img src="' . IMG_ROOT . $path . '/' . $file . '" alt="' . $alt . '" ' . $title . ' />';
}

T'as pas plus naze que de mettre le fichier dans le alt en cas de alt vide ? Si pas de alt, alors alt vide, mais surtout pas mettre le fichier

Ben en fait c'est surtout mon exemple qu'est pourri

Alors après c'est sûr que c'est pas forcément le mieux, mais j'ai justement fait ça parce que mes noms d'images sont pour la plupart explicite

Edit : Tu mettrais quoi ? "image" ?

Edit 2 : j'avais pas vu que tu disais un alt vide ... mais je croyais que le alt était obligatoire ?

Alt est obligatoire, mais ça veut pas dire qu'il ne peut pas être vide, justement...

Moué ... je vois pas l'intérêt qu'il soit obligatoire s'il peut rester vide dans ce cas

Genre pour une barre d'outils, tu met une image et un texte, style :

Ceux sans CSS verront le bel icône, mais en même temps comme ça sert à rien on fait pas chier les aveugles avec un texte dupliqué ou un fichier image...

Un exemple de helper pour une image quelconque :

 
J'ai fait le choix de faire un "$extras" qui permet rapidement d'ajouter ce qui est nécessaire, plutot que de vouloir compliquer le helper. Quelques exemples d'utilisation dans la vue :

 
On peut ensuite faire des helpers plus spécifiques, qui viendront se servir de ce helper générique :

 
Celui-ci permet d'afficher une image se trouvant dans le dossier "view/images" de l'application par exemple.

Merci pour les exemples

Et pour utiliser les helpers, plutot que de tous les charger, c'est dans la vue qu'on charge les helpers au besoin avec une petite classe dédiée.  
 
Exemple de vue utilisant des helpers :

 
On remarque le code suivant au debut de la vue :

 
Les helpers sont regroupés par fichiers dans un dossier /helpers, et suivant leur fonction : url.php, header.php etc...
Helper::load se charge d'inclure le fichier php s'il n'a pas été déjà inclut en allant le chercher dans le dossier des helpers.
 
Les fonctions du helper 'header' par exemple chargées sont ensuite directement utilisable :

Ce helper app_stylesheet(...) permet d'afficher très simplement la balise  d'inclusion du css, en allant chercher le css à l'endroit qui va bien.
 
L'avantage, c'est qu'on ne charge un helper que si l'on en a besoin.

C'est foutrement bien foutu! J'en apprend tous les jours

Moi pour l'instant j'ai pas de helpers. J'en ai pas eu encore besoin. Dès que le problème se posera je m'y pencherais

'xactly  

La langue je la gère très simplement grâce à une seul fonction.
Dans la vue, ça se présente comme ceci :

 
Le fichier de traduction : (en php, très simple)

 
La fonction __($string) permet d'en obtenir la traduction :

 
La classe l10n possède donc une méthode statique i18n($toTranslate) qui charge les fichiers de langue à la première demande de traduction puis qui retourne la traduction de la chaine. (si aucune traduction n'est dispo, alors elle renvoie la chaine à traduire telle quelle)
 
Il s'agit d'une sorte de "super helper" puisque cette fonction est accessible depuis n'importe quelle partie du code (controlleur et vue). Le fait d'avoir une fonction très simple comme celle-ci permet d'eviter d'allourdir l'ecriture.
 
Un petit plus c'est aussi que les chaines à traduire soient des chaines deja lisibles (ici "Hello World !" ), plutot que des index de tableau peu clair ('hello_world') qui ne feraient à la longue que compliquer la compréhension.
 
Voila, je vous apporte un peu de ce que je fais habituellement, si ça peut aider quelqu'un ça sera toujours ça de gagné

 
 
Justement tiens, comme tu parles de ça, je me suis toujours demandé avec ce genre de fonction comment ça se passe pour traduire un long texte ?
 
Genre tout ce que je suis en train d'ecrire en ce moment sur ce post ... ?

pourquoi ne pas utiliser gettext, qui fais déjà ça ? (surement en mieux en plus)

 
En ce qui me concerne j'ai déjà essayé ... j'ai même cherché des tutos etc... jamais réussi J'ai trouvé ça horrible à mettre en place

C'est vrai que c'est un peu particulier à utiliser (faire les fichiers de trad., les compiler, initialiser l'environnement, toussa).

+1 pour gettext

Dj YeLL > Il n'y a aucun problème pour traduire des phrases longues :

Ca fonctionne très bien et le contraire m'aurait étonné puisque je me suis inspiré du framework Symfony
 
multani > J'ai également essayé getext, et si en pratique ça offre quelques plus, gettext est globalement moins performant et moins pratique à utiliser que de simples tableaux php sur de petites applications.
L'objectif pour moi c'est de choisir des solutions adaptées à la taille de mes projets, et ne pas sombrer dans "l'overkill" en optant pour des solutions comme gettext ou encore XLIFF. De toute façon, il ne faut pas oublier que si ces solutions proposent chacunes leur format d'écriture, au final, on construit un tableau php clef => valeur des textes à traduire et leur traduction.

Il me semblait en effet voir une ressemblance assez forte
 
D'ailleurs pourquoi ne pas utiliser symfony ?

J'utilise Symfony mais aussi mon propre framework, plus léger et plus adapté à certains de mes sites. Tout dépend du projet
J'aime apprendre en développement mes propres solutions : certes je réinvente la roue, mais le but est pédagogique et je suis un passionné de développement.
C'est un peu comme la conduite, j'aime conduire mais aussi comprendre comment mon véhicule fonctionne (sans aller jusqu'à en monter un moi-meme lol)

vanadium > Principal problème que je vois à ton système : a chaque fois que tu modifies une phrase de la langue principale, tu es obligé de modifier tous les fichiers de traductions.
Second problème : t'es coincé si tu te retrouves avec deux phrases identiques dans la langue principale mais que tu as besoin de les traduire différemment à cause du contexte ou pour de simple raison de conjuguaison ou de grammaire.
 
Par contre, c'est vrai qu'un "Your name is " est plus parlant qu'un "phrase_nom_1" ou qu'un nombre.

Certes, si je modifie la phrase de la langue principale, je dois modifier les fichiers de traduction. Mais il est impossible de faire autrement. (ou alors tu me montre pke je suis curieux de voir comment tu arriverais à découpler ça )
Pour une phrase donnée il n'y a qu'une traduction possible . Mais ma gestion des fichiers de langue permet plusieurs définitions possible : chaque controleur a son propre fichier de langue. Il est ainsi aisé de mettre des définitions différentes pour chaque controleur.
De meme, l'application (qui est un ensemble de controleurs, modeles et vues) a un fichier de langue dont le controleur peut sans aucun problème surcharger les définitions.

vanadium > On peut l'éviter tout simplement en utilisant des clés numériques ou textuelle (genre le fameux "hello_world" ) à la place de la phrase finale. Ton système à ses avantages et ses inconvénients, l'autre système à les avantages et inconvénients inverse.

Tu ne résoud absolument pas le problème : si tu changes ta clef, qu'elle soit numérique ou une phrase, il faut répercuter la modification partout.
Et il vaut mieux avoir des phrases parlantes plutot que des index, pour la relecture et la maintenabilité du code.  
Tu perdras plus de temps à essayer de retrouver la définition de tes clefs à chaque fois que tu voudras savoir ce qu'elle cache, que moi de faire en quelques secondes un rechercher+remplacer sous Eclipse

vanadium > Si tu fais un système de clé, c'est justement par ce qu'on a jamais besoin de changer leur nom quelque que soit la langue qu'on décide de modifier. Il faudrait être taré pour mettre en place un système de clé et décider tout à coup que la clé "hello_word" va désormais s'appeler "bonjour".

 
Deux raisonnements totalement contradictoires.  

 
Nan mais toi pas comprendre
 
Si tu fais un truc du genre
 
$lng['hello'] = 'Bonjour à vous les gros cons !';
 
Et que 3 mois après t'as envie de changer pour  
 
'Bonjour à vous les amis !';
 
Bah tu changes ton fichier de langue.
 
Si tu as un truc du genre
 
$lng['Bonjour à vous les gros cons !'] = 'Bonjour à vous les gros cons !'
 
Ben le jour où tu veux changer c'est plus chiant déjà, il faut changer la clé + l'appel dans la vue, + le contenu de la variable....

CTRL + H tu connais pas ?
Je perd du temps une fois à faire la modif si nécessaire.
 
Dans ton cas, on perd à chaque fois du temps à comprendre quel traduction se cache derrière l'index en étant obligé d'aller dans le fichier de langue.
 
En fait, je me dis tout simplement : "Make the common case faster."
Accélérons les taches les plus courantes, quitte à ralentir celles qui sont executées le plus rarement.

Principe essentiel

Au fait florentG, ou en est ton framework perso ? J'aimerais bien tester ça

Personne ne taiste, c'est closed-source
 
Sinon là je suis en plein interface d'admin pour des choses diverses et variées (catalogue, news, etc.). J'ai un max de trucs à implémenter, parce que là j'ai pas mal de choses redondantes...
 
Sinon la structure MVC est à peu-près figée, et fonctionne plutôt bien, c'est pas trop relou de développer avec. Car c'est une règle essentielle, ça sert à rien de développer un framework si on l'utilise pas (ou peu), la plupart des trucs que j'ai implémenté ont été implémentés après avoir rencontré des cas concrets.
 
 
Au niveau de la structure d'un controller, j'ai découpé en méthodes http. Genre je balance à la racine un fichier pouet.controller.php, et dedans je mets :

class pouet extends MFW_Controller
{
 
  public function get($machin, $truc)
  {
     // ...
  }
 
  public function post()
  {
     // ...
   }
}

 
Si j'accède par l'url /pouet/valeur1/valeur2.html, je retrouve valeur1 dans $machin et valeur2 dans $truc. URL Rewriting pour zéro dollars. J'peux aussi déclarer un paramètre en optionnel, ou lui filer une valeur par défaut. Pour la méthode post(), elle est exécutée en cas d'http post. Embrace HTTP, do not avoid it. Je déteste les frameworks event-driven où t'as des trucs genre :

Rien de pire que ça. En web, on clique pas un bouton : on POST des informations à une URL...
 
 
Sinon les controllers peuvent être regroupés en modules. Genre j'ai un module catalogue, avec un sous-dossier catalogue\controller, et dedans plein de controllers style liste, ajoutcat, ajoutprod, etc. On accède par catalogue/ajoutcat.html par exemple.
 
Les modules peuvent être hébergés au sein du framework, et être appellés dans le site. Pour ça dans le style je fait un :

Et j'hérite automatiquement de toutes les fonctionnalités du module catalogue, comme s'il était dans le site.
 
 
Aussi, on peut mettre dans les controllers une méthode beforeRequest, j'ai pu voir qu'il y avait souvent des choses redondantes entre la méthode get et post. Elle sera donc systématiquement exécutée quelque soit la méthode HTTP.
 
 
La semaine prochaine, les view...
 
 
 

Comme dans web.py

Et si on appelle l'URL /pouet/valeur1/valeur2/valeur3 sur la même fonction ça nous pète à la gueule

Et si on se retrouve avec $machin = "valeur1" et $truc = "valeur2/valeur3", il y a moyen de demander à récupérer $machin = "valeur1/valeur2" et $truc = "valeur3"? Ou l'inverse?

En PHP

D'un côté j'ai envie de voir ce que ça donne, de l'autre j'ai trai trai peur

DELETE, PUT et HEAD sont gérés aussi, ou pas

J'ai également commencé mon propre framework MVC. Et je deteste également les framework par événement
 
Mon controller se présente de cette manière :

 
Les méthodes du controleur (index()...) sont des "action" pour moi.
Aucune méthode du controleur n'a besoin de paramètres. On remarque la méthode preExecute(), qui est executée juste avant l'action du controleur (ici index() par exemple). Il existe également une méthode postExecute().
 
Mais alors comme je récupère mes paramètres d'urls ? Grace à des règles de routage, spécifiques à chaque Application (une application est un ensemble de controleurs et vues) :

 
La route ci-dessus définit les urls de type /controller/action/id.
Pourquoi des routes ? Tout simplement pour permettre d'avoir des urls totalement configurables (aussi bien en nombres de parametres, qu'en url rewrite). Par exemple, on pourra /category/21 ou animaux-21.html pour aller sur la meme page de la catégorie avec l'id 21.
 
On tape une url dans le navigateur. Elle arrive au Front Controller. Celui-ci demande au Routeur de parser l'url et, suivant les routes définies d'extraire les paramètres de la requête. une fois l'url parsée, le routeur  crée un objet HttpRequest en assignant les paramètres suivant la route qui correspond à l'url.
Le Front Controller va ensuite consulter la requete Http (HttpRequest) et essayer d'invoquer le controleur et l'action qui correspondent. bien sur les cas d'erreur divers possibles ont été traités. (controleur non trouvé, action non trouvée...
 
Dans le controleur invoqué, on a accès à diverses méthodes qui facilitent la vie :

 
Les exemples ci-dessus sont une petite partie de ce qu'il est possible de faire dans le controleur.
 
Voyons la vue qui affiche les catégories :

Elle affiche les catégories :

 
On remarque le helper :

il permet de construire directement le lien d'après la route qu'on lui donne:  
- Edit : texte du lien (et il suffit de spécifier la traduction dans le fichier de langue, et c'est automatiquement traduit)
- 'default' : la route à utiliser
- array(...) : les paramètres de la route
 
Ainsi, le parsing et la reconstruction des urls se font via les routes : il suffit de modifier les routes pour que les urls changent dans toute l'application.
 
Pour le modèle, plutôt que d'utiliser un ORM (Object Relational Mapper) maison, j'ai préféré opter pour PHPDoctrine (http://www.phpdoctrine.net/trac/), un ORM extremement complet et facile à utiliser.
 

 
L'avantage de PHPDoctrine, c'est qu'il sait gérer moultes choses de lui meme, comme les jointures par exemple.
 
Voila, mon petit framework de tous les jours pour mes petits besoins.

Tu ne penses pas qu'il serait plus simple d'utiliser Rails? Non parce que là tout ce que je vois c'est une réimplémentation en PHP de Rails
 
(pour la partie controller et les templates, en tout cas)

Pourquoi pas, je n'ais jamais touché à Ruby on Rails mais je m'y interresse depuis un moment. Le plus dur c'est de se lancer
 
Dans tous les cas, c'est pour le plaisir que je fais ça

Nanan, ça retourne valeur1 dans le premier, et valeur2/valeur3 dans le deuxième
 

J'en ai pas encore eu besoin, je le ferais le jour où le cas se présentera. YAGNI YAGNI YAGNI
 
Au pire, on peut toujours utiliser la méthode traditionnelle style pouet.html?valeur1=truc&valeur2=machin. On peut mixer les deux aussi : pouet/bidule.html?valeur2=truc. La valeur dans la query string prenant le pas sur celle extraite de l'url.
 
 

Oui oui
 
Style :

Normalement oui, toutes les méthodes HTTP peuvent être implémentées

J'apprend des trucs là
 
Et imaginons qu'on ait

function foo($bar = "baz", $qux = "quux", $corge = "grault" ) { /* etc */}

il y a un moyen de ne fournir de valeur "pas par défaut" que pour $corge