Ceci est un brouillon d'introducion à la documentation de nyroFwk. Toutes remarques, suggestions ou questions pour l'améliorer est la bienvenue !

Vendredi dernier, j'ai mis en ligne l'API et le svn (user : anon / passe : anon) de nyroFwk.

Bon c'est très bien tout ça, mais qu'est-ce que c'est ?

Pour commencer, petit extrai de wikipedia : Un framework est un kit de composants logiciels structurels, qui définissent les fondations ainsi que les grandes lignes de l'organisation de tout ou partie d'un logiciel.

Oui, mais des frameworks PHP, il en existe des tas, non ?
Oui, on peut signaler symfony, Zend Framework et CakePHP ici. J'ai testé ces 3 là plus ou moins fortement. Chacun a ses avantages et ses inconvénients. Mais aucun ne répondait exactement à mes besoins et habitudes de développements. Alors quand quelque chose ne me convient pas, moi, je le refais, tout simplement (comme nyroModal par exemple)

Alors qu'est-ce que je n'aime pas ou j'aime dans ces frameworks ?

• CakePHP : la gestion des bases de données et des objets associés. A l'époque où j'avais testé, on était obligé de modifier les objets lorsqu'on avait des relations entre différents objets. Et puis je n'ai jamais réussi a vraiment faire quelque chose de bien avec. Pas forcément réellement tout testé non plus, je dois bien l'avouer. Là où CakePHP marque des points, c'est dans la génération automatique de l'administration et toutes les fonctionnalités ajax super simple à implémenter.
• Zend Framework : Je ne l'ai jamais concrètement utilisé car il me paraissait trop énorme. Ce framework a absolument tout ce dont on peut rêver. L'organisation des fichiers, de la documentation et de tout ce qui va autour de ce framework est géniale.
• Symfony : c'est celui que j'ai le plus utilisé (et que j'utilsie encore). J'aime bien la génération automatique des objets de base de données, même si je trouve cela dommage de devoir regénérer ça à chaque modification de la base de donnée. J'aime pas le grand nombre de fichiers de configuration et encore moins tous les différents formats possibles. Pourquoi s'embetter et donc ralentire le processus avec des fichiers YAML alors qu'un simple tableau PHP fait très bien l'affaire ? La barre de débuggage peut être très utile. La séparation des classes de chaque controller pose problèmes ; dans certains cas, on est obligé de réécrire le code...
  

Et puis il y a plein d'autres choses qui ne sont pas dans ces frameworks, comme :

• Gestion simple de formulaire permettant d'ajouter des champs, de vérifier s'il est valide, de le remplir, de récupérer les valeurs, etc...
• Intégration des règles d'opitimisations de yahoo developper simplement et de base
• Gestion des images souples, rapide et efficace
• Intégration d'un éditeur WYSIWYG simple
• Gestion des fichiers envoyés par les utilsiateurs sécurisée (ie : possibilité de restreindre l'affichage de ces fichiers qu'aux utilsiateurs connectés)
• Tout est objet

Vous l'aurez compris, ces éléments sont intégrés de base dans nyroFwk.

Dans mon framework, chaque objet a sa propre configuration, qui hérite de toutes la configuration de ses parents. Chaque configuration est définie de base par le framework mais est modifiable pour chaque site très simplement. Suivant les besoins, on peut aussi modifier la configuration de chaque classe suivant le controller (front ou admin). Prenons un exemple, plus parlant. La classe response_http_html gère tout ce qui sera envoyé au navigateur lorsque la page demandée est en HTML. Elle hérite de la classe reponse_http, qui elle hérite de la classe reponse_abstract qui hérite de object. La définition de cette classe est dans le fichier nyro/response/http/html.class.php. Sa configuration est dans le fichier nyro/response/http/html.cfg.php est conteint (extrait) :

$cfg = array(
    'meta'=>array(
        'robots'=>'index, follow',
        'description'=>'nyro project',
        'keywords'=>'nyro, project',
        'language'=>request::get('lang'),
    ),
);

On définit donc les balises meta par défaut de toutes les réponses HTML. A noter que la langue ici est dynamique sera en rapport avec la langue demandée par l'utilisateur (explications plus tard).

Cette configuration est là pour définir des éléments par défaut, mais doit bien évidemment être modifié pour chaque site. Pour ce faire, chaque site aura un dossier personnel dans lequel il doit définir ses classes propres aux sites, mais aussi toutes ces configurations. Ce dossier se nomme par défaut my dans nyroFwk et est placé juste à côté du dossier nyro.

Dans ce dossier propre à chaque site, on peut aussi redéfinir chaque classe de nyroFwk. En effet, à la demande de chaque classe, le framework va vérifier si le fichier correspondant à la classe existe dans le dossier my au bon endroit. Sinon, il cherchera dans le dossier de base du framework. Un mécanisme similaire est utilisé pour les configurations. Au lieu de remplacer la configuration, on va fusionner les configurations successives de la classe, en gardant bien sûr le plus spécifique. Par exemple, pour nyrodev.com, le fichier my/response/http/html.cfg.php ressemble à (extrait) :

$cfg = array(
    'meta'=>array(
        'title'=>'nyroDev, Analyste Développeur Web (PHP, jQuery)',
        'description'=>'Cédric Nirousset, nyroDev : Conception, Analyse et Développement de sites web (PHP, jQuery).',
    ),
);

Je redéfinis les balises meta title et description pour mon site public.

Les configurations sont un point très important pour nyroFwk. C'est pourquoi il est possible de définir encore plus finement ces configurations. Tout d'abord, on peut spécifier le controller de la configuration si on veut être plus précis. Pour mon site, l'administration porte le nom de controller 'admin' et le site public 'front' (par défaut dans nyroFwk). Pour l'administration, on n'a pas besoin des meta description par exemple. C'est la raison pour laquelle le fichier de configuration du site public ne se nomme pas comme je l'ai indiqué plus haut, mais en réalité my/response/http/html.front.cfg.php. Vous avez remarquer le front en plus qui indique que l'on veut l'affciher que pour le site public. Juste à côté, le fichier my/response/http/html.admin.cfg.php existe pour définir les éléments pour l'administration.

Avec ce système, on a déjà quelque chose de tout à fait souple. Mais ce n'est pas fini ! nyroFwk gère les sites multilangues de base. Son fonctionnement est :

• On définit une langue par défaut
  
• On définit les langues disponibles
• Si l'URL demandé est du type : monsite.com/LANG/maPage avec LANG une langue définit, alors on passe dans la langue demandée.

Bien, et alors, le rapport avec les fichiers de configuration ? Simple, en plus de la spécification par rapport au controller, les fichiers de configuration permettent aussi de spécifier une configuration spécifique pour la langue demandée. Exemple pour mon site qui est aussi disponible en anglais, le fichier my/response/http/html.front.en.cfg.php contient :

$cfg = array(
    'meta'=>array(
        'title'=>'nyroDev, Analyst Developper Web (english) (PHP, jQuery)',
        'description'=>'Cédric Nirousset, nyroDev: Conception, Analysis and Development of websites (PHP, jQuery).',
    ),
);

Ce mécanisme est utilisé à plusieurs endroits dans nyroFwk pour définir des messages à l'utilisateurs. Et comme vous l'avez remarques, ces fichiers sont de vrais fichier PHP. Donc rien ne vous empêchera, quand vous serez plus à l'aise avec le framework, d'utiliser des classes avec des fonctions statiques pour faire d'autres choses comme par exemple utiliser la base de donnée pour modifier ces éléments...

Et n'oubliez pas : les configurations sont successives et n'écrasent pas les autres configurations, aussi bien des classes parentes, mais aussi des configurations du controller et de langue. Ainsi, pour la classe response_http_html, la configuration est le résultat de la fusion des configurations (le plus bas étant le plus prédominant) :

1. nyro/object.cfg.php
2. nyro/object.fr.cfg.php
3. nyro/object.front.cfg.php
4. nyro/object.front.fr.cfg.php
5. my/object.cfg.php
6. my/object.fr.cfg.php
7. my/object.front.cfg.php
8. my/object.front.fr.cfg.php
9. nyro/response_abstract.cfg.php
10. nyro/response_abstract.fr.cfg.php
11. nyro/response_abstract.front.cfg.php
12. nyro/response_abstract.front.fr.cfg.php
13. my/response_abstract.cfg.php
14. my/response_abstract.fr.cfg.php
15. my/response_abstract.front.cfg.php
16. my/response_abstract.front.fr.cfg.php
17. nyro/response_http.cfg.php
18. nyro/response_http.fr.cfg.php
19. nyro/response_http.front.cfg.php
20. nyro/response_http.front.fr.cfg.php
21. my/response_http.cfg.php
22. my/response_http.fr.cfg.php
23. my/response_http.front.cfg.php
24. my/response_http.front.fr.cfg.php
25. nyro/response_http_html.cfg.php
26. nyro/response_http_html.fr.cfg.php
27. nyro/response_http_html.front.cfg.php
28. nyro/response_http_html.front.fr.cfg.php
29. my/response_http_html.cfg.php
30. my/response_http_html.fr.cfg.php
31. my/response_http_html.front.cfg.php
32. my/response_http_html.front.fr.cfg.php

Bien sûr, ces fichiers ne sont utilisés que s'ils existent ! Et ceci avec n'importe quelle classe du framework.

Mais je dois créer un fichier pour chaque classe qui en a besoin ? Au début, c'était le cas oui. Mais je me suis aperçu que cela pouvoit devenir très vite long et fastidieux. Ce mécanisme existe toujours et est toujours utilisé car dans certains cas indispensable, mais il existe un autre moyen. En effet, la configuration de la classe nyro permet de modifier la configuration de n'importe quelle classe dans un seul et même fichier de configuration. Par exemple, on aurait pu définir les éléments montrés précédemment dans le fichier my/nyro.front.cfg.php de cette façon :

$cfg = array(
    'response_http_html'=>array(
        'meta'=>array(
            'title'=>'nyroDev, Analyst Developper Web (english) (PHP, jQuery)',
            'description'=>'Cédric Nirousset, nyroDev: Conception, Analysis and Development of websites (PHP, jQuery).',

        ),
    ),
    'une_autre_classe'=>array(
        'uneAutreConfig'=>'yeah'
    ),
);

Cette configuration est utilisé en dernier lieu pour créer la configuration de chaque classe.

Vous avez d'ailleurs remarqué la classe object ? Toutes les classes instanciables héritent de cette classe, ce qui permet une gestion centralisée et uniforme des configurations et de la création des objets.

Bon, voilà déjà pour la configuration.

Pour revenir sur les fonctionnalités du framework, voici une liste (sans doute non exhaustive) de ce que gère pour l'instant nyroFwk :

• Programmation orientée objet
• Configuration avancée et très souple des classes
• Gestion des sites multilingues
• Gestion des bases de données multilingues avec récupération automatique des données propre à la langue
• Configuration de base de donénes multiples
• Gestion des utilsiateurs et de leur connexion, vérifications des accès, etc...
  
• Gestion des formulaires avancées et souples : validation, affichage, etc...
• Manipulation des images simplement, avec souplesse et efficacement
• Création de formulaires directement depuis la structure de la base de données (gestion des données liées et en relation)
• Création de l'administration automatique
• Minimisation en un seul fichier compressé des fichiers JavaScript et CSS nécessaire à la page
• Application d'un maximum de règle d'optimisations données par Yahoo
• Barre de débogage
• Editeur WYSIWYG (tinyMce) très simplement intégrable
• jQuery et jQuery UI intégré
• Ajax ready : différents templates s'il s'agit d'une requêtes ajax
• Extensibilité simple et accrue : tout peut être redéfini
• etc...

Fiou, ça n'a pas été une mince affaire de rédiger tout ça... J'espère que ça vous donne déjà une meilleure idée de ce qu'est nyroFwk et que vous aurez envie d'en savoir plus...

I was a long time since this one was on the boxes, it finally cames out: the new version of my website is online!

Aymeric aka Miho designed it; I think it's very clear and let a good place for the content with a great readability.

I developed it using my own framework which optimizes every to the server by compressing every HTML pages. It also merges and compresses CSS and JavaScript after removing all the comments and useless whitespaces. With that my website gains a A-grade with YSlow - only one F for not using CDN and one B for contents without cookies.

I also enjoyed make it accessible without reloading the page using AJAX and jQuery. I used jQuery address which works perferctly. And nyroModal is also in the party to show the references. Of course all pages are accessible without JavaScript for a better ranking.

In the same time I left phpMyVisites to use Google Analytics, using the manual tracker for Ajax pages.

Finally, I want to thnaks the following personns:

• Miho for the design
• My mother for the French corrections
• Chonchon for the English corrections
• Florian for the new logo

To celebrate this, I created a facebook group and I'm twitting again more often. Don't hesitate to join the group or follow me!

If you have any remarks, suggestions or anything else to say about the new wbesite, the comments are here for you!

Elle traînait dans le cartons depuis plus d'un an, elle arrive enfin : la nouvelle version de mon site est enfin en ligne !

C'est Aymeric aka Miho qui a réalisé le graphisme que je trouve très clair et laissant bien la place pour le contenu avec une bonne lisibilité.

Je l'ai développé en utilisant mon propre framework qui optimise toutes les requêtes vers le serveur en compressant les pages HTML, mais aussi les CSS et les JavaScript. Ces derniers sont aussi fusionnés en une seule URL pour limiter au maximum le nombre de requêtes vers le serveur. Grâce à ça, le site obtient le grade A avec YSlow - un seul F pour ne pas utiliser un CDN, et un B pour les contenus sans cookies.

Je me suis aussi amusé à rendre tout le site accessible sans recharger de page en utilisant AJAX et jQuery. J'ai utilisé le plugin jQuery address qui fonctionne à la perfection. Enfin, nyroModal est aussi de la partie pour afficher les références. Bien sûr, l'ensemble du site reste accessible sans javaScript pour permettre un meilleur indexage.

J'en ai aussi profité pour quitter phpMyVisites pour intégrer Google Analytics, utilisant la tracker manuel lors des changements de pages avec Ajax.

Enfin, je tiens à remercier les personnes suivantes :

• Miho pour le graphisme
• Ma mère pour les corrections de français
• Chonchon pour les corrections d'anglais
• Florian pour le nouveau logo

Pour l'occasion, j'ai créé un groupe facebook et je me mets à twitter plus régulièrement. N'hésitez pas à rejoindre le groupe ou me suivre !

Si vous avez des remarques, suggestions ou n'importe quoi à dire sur le nouveau site, les commentaires sont là pour vous !

I've just finished this book Subject to Change, written by Adaptive Path, edited by O'Reilly.

On these pages, this book try to answer to one question: "How could we manage long projects when needs and requirements are changing between the beginning and the end of the project?"
With their experience in the website design, Adaptive Path explain us how they work, but even more interesting, which errors they did and what they did to not reproduce them.

The first chapters speaks about products and/or services to be designed. Quick reminder and extension of the Purple Cow, it's explained that time when designers created without take care of the user is past. The user -and his experience- should be now the center of the development process to result in a product which will please -and so which will be bought.
We learn how to create user cases more convivial, by developing the empathy for the final user. Adaptive path discovered actually that this empathy, which must be present in the whole team, the project will most of time fo to the trash or won't be as good as expected.

Then along the reading we're starting to draw the Adaptive Path's work methodology. They set up an work organization allowing us to increase the team spirit and the design ideas for the final result. Nobody is excluded from the project meeting: developer, graphic designer, project manager, and the client speaks all together about the solution to realize a successful final product. The method isn't infallible. Errors are actually part of the process, used to correct as soon as possible the project thanks to the user tests.

Finally the last chapter speaks about the Agile method which correspond to the description above. At the first reading it looks like funnier, and more pleasant than the heavy development method. But when a project manager will read this, he won't like it simply because, as the name said, this method make it a matter of principle of the team should be flexible to answer to the expectation when they arrive or when they are discovered. This is what its strength, and also its weakness.
How a project manager will know how long will take a project before knowing what will do his team? To do that, Adaptive Path explain his own experience for doing this transition smoothly. Some key points that we could remember are: encourage innovation, improve feedback and user support, and make development more iterative.

If you're a project manager or development manager in a company, no matter what is its size, I strongly recommend this book. It won't probably be possible for you to implement the idea immediately. However it'll provide you new ways to work and fresh ideas.

Version française de ce billet

Je viens de terminer le livre Subject to Change, écrit par Adaptive Path, édité par O'Reilly.

Dans ses pages, ce livre essaie de répondre à une question : "Comment peut-on mener de longs projets alors que les besoins changent entre le début et la fin de ce projet ?"
Par son expérience dans la conception de sites internet, Adaptive Path nous expliquent comment ils travaillent, mais plus intéressant encore, quelles erreurs ils ont comment et ce qu'ils ont entrepris pour ne plus les reproduire.

Les premiers chapitres sont consacrés au produits et/ou services à concevoir. Petit rappel et prolongation de la vache violette, on nous explique que le temps où les designers créant dans leur coin sans se soucier de l'utilisateur est révolu. Il faut maintenant mettre l'utilisateur final -et surtout son expérience- au cœur du processus de développement pour arriver à un produit qui plaira, et donc se vendra.
On apprend ainsi comment on peut créer des cas utilisateurs plus conviviaux, on développant de la sympathie pour l'utilisateur final. Adaptive path a en effet découvert que sans cette sympathie, qui doit être présente pour toute l'équipe, le projet a de grandes chances de tomber à l'eau ou ne pas être aussi bien qu'espérer.

Puis, au fur et à mesure que l'on avance dans le livre, on commence à y voir plus clair dans les méthodes de travail d'Adaptive Path. Ils ont mis en place une organisation de travail leur permettant de développer l'esprit d'équipe et les idées ergonomiques pour le résultat final. Personne n'est exclu des réunions de projet : on trouve aussi bien le développeur, le graphiste, le chef de projet et le client qui discutent tous ensemble des solutions pour réaliser un produit final réussi. La méthode n'est pas infaillible. Bien au contraire, les erreurs commises sont incluses dans le processus de développement afin de les corriger au plus vite grâce à de nombreux tests utilisateurs.

Enfin, le dernier chapitre est consacré à la méthode Agile, qui correspond en fait à tout ce qu'il y a de décrit plus tôt. Il est certain que cette méthode paraît à prime-abord plus fun, plus sympa et plus ludique que les méthodes lourdes de développement. Mais lorsqu'un chef de projet lira ces chapitres, il n'aimera pas, tout simplement car, comme son nom l'indique, cette méthode part du principe que l'équipe doit être assez flexible pour répondre aux attentes au fur et à mesure qu'elles arrivent ou qu'on les découvre. C'est ce qui fait sa force, mais aussi sa faiblesse.
Comment un chef de projet va pouvoir gérer un projet pour lequel il ne sait pas à l'avance ce que l'équipe va devoir développer ? Pour cela, Adaptive Path livre son expérience dans cette transition pour le faire en douceur. Les quelques points clés que l'on peut en retenir sont favoriser la créativité, améliorer les feedback et support utilisateurs et rendre le développement plus itératif.

Si vous êtes un chef de projet ou responsable de développement dans une entreprise, quelque soit sa taille, je vous recommande vraiment ce livre. Il ne vous sera sans doute pas possible d'adhérer à toutes les idées dans l'immédiat, mais il aura au moins le bénéfice de vous présenter de nouvelles façons de travailler et de vous donner de nouvelles idées.

English Version of this post

I deployed in a website an Ajax reload for every pages. This website use a small audio player and the sound was stopped each time a new page was requested. That wasn't so graceful. The result now is exactly the same website reloading the pages through Ajax, without changing accessibility: I didn't modify ehe HTML source.

I did it quickly bu using jQuery. As this method could be useful for others, I will describe step by step how I made it.
The website which I worked on was pretty small: Amandine Café. Nothing better to train himself in a small example and then apply it in big projects

Current Website Analysis

The first thing to do is to navigate in the whole website to deduct the fixed zone and dynamic zone to reload. You have to identify which links will reload which zones, and what will be happen regarding the reloaded page. For instance you have to worry about the possible javascript control which could be a problem. Write down them and we'll take care of that at the end.
This part was pretty fast for me as the website don't use sub navigation and contains only 5 pages. I found 2 zones delimited by 3 div identified with the id header, page, and footer. Only the div#page vary regarding the pages. That will be only this content that I will update with Ajax.

PHP Side Preparation

Before dealing with the javascript code, we'll update the PHP code of our pages. When an Ajax load is made, we won't reload the full page, but only the content to update. For more simplicity and flexibility, we'll use the same URL than the real links. That's mean we have to be able to provide only the requested content in PHP, without the head page, or the fixed div. If you don't want –can't– do that, take a look to the little bonus at the bottom of this post...
The easiest way to do that is to put the fix part in separate files, named randomly header.php and footer.php. These files will be include in every pages; that's may already the case, using the include function. The thing is now to don't show these parts when the request is an Ajax request. Pretty easy, we'll write a PHP function: isAjax. The file includes will occur only if isAjax is false. In others words:

if (!isAjax())
    inlcude('header.php');

The isAjax function is, as you can see, very very hard:

function isAjax() {
    return array_key_exists('HTTP_X_REQUESTED_WITH', $_SERVER);
}

Actually jQuery –also Prototype, I don't know about the others– add a HTTP_X_REQUESTED_WITH element in the request that you can retrieve in the $_SERVER global variable.
We're done with the PHP preparation pages, which are now able to provide light version of your pages especially for the Ajax request.

Javascript Integration

We're moving now on the real Ajax request programmation. To keep the website totally accessible, which will works exactly in the same way without Javascript, We won't modify any current HTML sources. We'll just include jQuery in all the pages and one other javascript file containing the upcoming code.
The script schema will be:

1. On the page load, intercept all links pointed to .php pages
2. Add an onclick function to make the Ajax request and stop the page change
3. On the click, call the page through Ajax with the same URL and then integrate the result where we want.
4. Stop the click propagation

With jQuery, we're writing that very simply:

$(function() {
    $('a[href*=.php]').click(function() {
        $('#page').load(this.href);
        return false;
    });
});

Very short, isn't it?
Of course this code won't work perfectly in every case. In my example I have to update the body id according to the requested page; that's mean the navigation bar link will going brown as expected by the graphic designer. To do so we can use the third parameter of the load function which will be called once the Ajax load is done. Here is how looks like my function:

$(function() {
    $('a[href*=.php]').click(function() {
        $('#page').load(this.href, null, function() {
            $('body').attr('id', this.href.substring(this.href.indexOf('.')));
        });
        return false;
    });
});

If you read the code in the live site, that's not at all like that because I occured other problems.

Little Bonus

If you can't–don't want– deploy the PHP cutting for the Ajax request, don't stop right now! Firstly it could be possible to reload the whole page. This solution will be very sad and you'll probably occurs many others problems.
jQuery will help. Indeed, in the URL provided to the load function, you can specifiy a HTML selector to filter the result and show only the part you want to.
In my example the call could become simply:

$('#page').load(this.href+' #page');

I dissuade to use this technique as that's mean you will reload the whole page. So we loose the Ajax utility to reduce data transfer between clients and server.

If it's not that simple?

Give proof of imagination!
As I already thought about this question, I'll give you some example soon. This post is yet consistent and you can start to enjoy. Finally I hope you won't wait me to do that... Or if you have a website where do you want deploy this kind of solution, let me know and I will use it as my example.

Express Yourself!

How did you find this post? Interesting, boring, totally useless, can do better?
Do you have some questions? Suggestions?
Did you read some English mistakes?
Use the comments!

Version française de ce billet

Des news d'ici et d'ailleurs :

• Prism sort en version 0.9
• Si vous chercher l'extension ultime pour rechercher vos messages dans Thunderbird, Seek est votre ami
• Firefox sort en beta 4. Encore une beta 5 avant laversion finale. A noter les améliorations de mémoire.
• IE8 sort en beta
• Les résultats des navigateurs en beta à l'acid test 3
• Vous travaillez sur une version mobile d'un site ? Lisez ceci pour connaitre les bonnes pratiques
• jQuery organise un worldwide sprint ce week-end spécialement pour jQuery UI
• On parle de plus en plus de Piwik
• TinyMCE sort en version 3.0.5
• Netvibes évolue vers le réseau social, sous le nom de Ginger. Ma page est ici, et devrait se remplir ce week-end.
• Marre de créer vos htaccess à la main ? La solution en ligne.
• Après l'Air Guitar, Canal Plus lance l'Air Fuck : filmez-vous et gagner un scooter (wahou, un scooter, j'en ai toujours rêver...)
• Les LoKataires, amis et artistes que j'adore, ont maintenant leur clip, simplement nommé le LoKaclip (Bravo à Pitch pour le montage !)