Tag : WYSIWYG

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...

Un peu de nouvelles de Los Angeles, brut de pomme :

• Fluidesign a déménagé depuis le début d'année. Nouvelle adresse, suivez le lien. Vue sur l'océan depuis la salle de réunion, grande classe pour commencer la semaine. Dans le même immeuble, deux étages plus bas, on trouve le fameux Habbo
• J'en ai profité pour déménager pour ne pas me taper une heure ou plus de bus le soir... 10 minutes de bus pour aller au boulot, un peu moins pour la plage.
• Fluidesign a ouvert son blog au grand public. Pas trop d'activité dessus, mais il est là quand même. Je n'aime pas du tout le graphisme, le précédent était plus sympa. Damned Designer!
• Stage terminé depuis une semaine, je rempile pour 6 mois de plus chez Fluidesign avec énormément de boulot en ce moment.
• le DUT SRC de Montbéliard fêtait ses 10 ans aujourd'hui à l'occasion de la journée des anciens, dommage que je sois à l'autre bout du monde. Rendez-vous pour les 15 ans !
• Aujourd'hui peut-être promenade de 3 heures le long de la plage comme au premier jour. Pantacourt et T-shirt était de rigueur (d'où le titre du billet, juste pour narguer les lecteurs français qui sont dans le froid et que je vais rejoindre)
• Retour en France pour 2 semaines vendredi prochain. Au programme : gala de gym dès l'arrivée, rendez-vous à l'ambassade pour obtenir un nouveau visa, soirées avec les amis, repas avec la famille, soutenance de stage, et encore plein d'autres choses.

Un peu de news logiciels, web, brut de pomme aussi :

• jQuery sort en version 1.2.2; au menu 300% plus rapide pour la sélection d'éléments, fonctions au chargement de la page se font après le chargement des CSS, possibilité d'indiqué quel Mime-Type on veut lors d'une requête ajax, le scroll de la souris est maintenant gérer très facilement par un tout nouveau plugin. A quand des nouveautés dans jQuery UI ?
• TinyMce sort sa version 3 en Release Candidate 2. Sortie prévue de la finale à la fin du mois. A mon avis elle n'arrivera qu'à la mi-février
• Filezilla ajoute quelques fonctionnalités demandés : éditer les fichiers locaux par un clic droit > editer le fichier. Une nouvelle fonctionnalité absoluement démentiel a fait son apparition : la synchronisation entre les dossiers locaux et distants, avec retour visuel pour savoir si les fichiers ne sont présents que d'un côtés ou différent. Vous entrez dans un dossier d'un côté, l'autre se met à jour automatiquement. Un gain de temps énorme. Il me manque toujours une fonction indispensable pour moi : la configuration du double-clic. Après demande sur le forum, le développeur, botg, ne veut pas l'implanté car il considère que Filezilla n'est pas un explorateur de fichiers... Si vous voulez testez, pensez à mon convertisseur automatique et cmplet de config.
• Veille info, mais je n'en avais pas parlé, et cela me tiens à coeur : Prism est un dernier né des labos de Mozilla et permet de mettre vos applis web dans une petite appli, différent de Firefox. Il utilise le moteur de Firefox 3, et est toujours en version beta. D'après ce que j'ai lu ici et là, la prochaine version ne saurait tardé. Je vois en Prism un moyen facile pour faire utiliser le moteur de Firefox à ses clients, et pourquoi pas proposer des administrations en XUL ?
• Encore une vieille info : Android, la plateforme de l'open handset alliance issue du travail de google et open-source. 1er téléphone prévue pour la mi 2008, vraissemblablent un HTC.
• Apple a sorti son MacBook Air : écran 13' qui rentre dans une enveloppe. Ok c'est super, tout petit et beau comme les autres produits Apple, mais c'est bien trop cher selon moi : 1699€. Autant s'acheter un macBook Pro pour 200€ de plus...

Depuis un peu plus de 3 mois, on n'avait pas de nouvelles de TinyMCE. Je m'étais promené sur le site pour essayer de trouver une roadmap mais je n'avais pas trouvé.

Et aujourd'hui, qu'est-ce qui tombe dans mon netvibes ?
L'annonce de la sortie de la version 3 alpha 1

Et les changements sont réjouissants :

• Réécriture complète du code (d'où le passage à la version 3) avec nettoyage en profondeur
• Réduction de 33% de la taille totale des scripts
• Réduction de 75% des requêtes au serveur
• Les popups sont maintenant personnalisables à souhait lors d'une ouverture inline (popup Ajax)
• Les plugins peuvent maintenant ajouter des éléments au menu contextuel, avec des sous-menus possibles
• Chargement à la demande des éléments et non tout au chargement
• Tous les éléments d'affichages passent maintenant par CSS (les images des boutons par exemple). Ce qui veut dire que la personnalisation sera encore amélioré à ce niveau là
• Les listes déroulantes (pour sélectionner la police par exemple) sont maintenant crées en javascript. On peut donc voir la police sur chaque ligne comme dans votre éditeur de texte favori

Et encore plein d'autres.

Je n'ai pas encore eu le temps de regarder en profondeur comment cette nouvelle mouture marche, mais on nous dit :

From a pure feature point of view, this release might not be very impressive, but if you are interested in JavaScript and do a lot of custom development, this is the release you have been waiting for.

En français :

Du point de vue des fonctionnalités, cette version ne sera pas vraiment impressionnante, mais si vous vous intéressez au JavaScript et à la personnalisation de TinyMCE, c'est la version que vous attendiez.

Dès que j'ai le temps, je fais un petit tour des nouvelles fonctionnalités JavaScript.

Vous pouvez d'ores et déjà voir la démo de cette dernière version : attention, les fichiers de langue n'étant pas encore prêt, vous verrez sans doute des choses bizarres...

Edit : Sans avoir de timeline véritablement défini, l'équipe de Moxiecode pense sortir une version finale à la fin du mois. Ils travaillent à la correction de bug, à la documentation et un tutoriel sur comment passer de la version 2 à la version 3.

Sur certains projets, on s'investit tellement qu'on a envie qu'ils marchent.
Bien sûr, on passe par des phases de doutes, on ne sait pas trop si ça va marcher, on ne sait plus. Mais on fait quand même.

Ce projet est une commande de La Communication Directe, qui m'a trouvé sur google au mois de décembre dernier. Il m'a fourni un cahier des charges que j'ai lu et annoté pendant un week-end à Lyon. Retour sur Besançon pour lui faire un devis. J'étais en concurrence avec 2 autres entreprises (pas des freelance) : j'étais plus cher et plus long. J'ai eu le contrat car j'avais donné la sensation de maîtriser plus ses attentes que les autres. En effet, je travaillais déjà (et je travaille toujours) sur la refonte d'un site du même genre.

Parlons un peu du projet à proprement parlé : WikiJournal est un site national désireux d'être proche de vous. Pour cela, tous les contenus sont localisés par régions, départements et 'pays'; on peut consulter le site au niveau national ou bien au niveau de chaque région. C'est la vision du client. Dans ce journal, on y trouve des articles présentant les régions, ce qu'on peut y faire, etc... Il y a aussi des petites annonces gratuites pour vendre ou acheter ce que vous voulez, un agenda local pur annoncer vos manifestations ou trouver de quoi faire ce week-end et un annuaire professionnel pour trouver votre plombier.

Dans chaque partie, vous pouvez soit consulter les ajouts effectués par les utilisateurs par catégories et/ou par localisations, mais aussi en ajouter par des formulaires qui sont à la fois simples, concis et faciles d'utilisation. Tous les ajouts et modifications doivent être validés pour apparaître sur le site.
Pour ce faire, le client dispose d'une administration protégée, dont j'ai fait le graphisme depuis un design récupéré sur OSW. Voici le résultat :

Ici pour les petites annonces. Evidemment, il n'y en a pas beaucoup, le site vient tout juste d'être lancé.
Comme à mon habitude, j'utilise TinyMCE (que j'affectionne particulièrement) dans l'administration pour gérer des pages fixes du site, ou le contenu des articles.

Il y a beaucoup d'Ajax dans le site. Par exemple, pour recharger les liste déroulantes lorsqu'on sélectionne une nouvelle localisation. Ce n'est pas la première fois que j'en fait, mais c'est le premier projet où il y en a autant.

Un gros travail a été fait pour optimiser le référencement. Si vous regarder les URLS des pages de résultats, vous verrez par exemple ceci :
http://www.wikijournal.fr/articles,r11,Midi_Pyrenees.html
http://www.wikijournal.fr/articles,r16,Provence_Alpes_Cote_d_Azur.html
On ne sait pas encore trop ce que va donner cet URL Rewriting, mais c'est toujours plus beau que des paramétres passé en GET. Bien sûr, un travail similaire a été fait sur les titres des pages, qui reprennent à peu près le même principe.

De plus, tous les formulaires d'ajout de données (ou de contact) utilise un captcha fait maison pour éviter tout pourrisage par des robots malveillant. En voici un exemple :

Et où gagne-t-il de l'argent ?
Il mise tout sur 2 choses :

• Les Google Ads qui sont présentes un peu partout, plus ou moins dominantes. Personnelement, je les trouve pas vraiment envahissante.
• Les bandeaux publicitaires, qu'il n'est pas encore possible d'acheter; ce sera possible un peu plus tard, quand le site aura grandi. Lorsqu'on achète un bandeau, la personne désirant affichée sa pub pourra sélectionné la partie du site, la catégorie de la partie, mais aussi la localisation où il veut afficher sa pub. Ainsi, il peut cibler ces affichages et avoir un retour sur les clics plus intéressants

J'ai aussi mis en place PhpMyVisites pour qu'il puisse suivre ses visite au jour le jour. Il commence déjà à regarder quelles recherches tapent les visiteurs qui arrivent son site, et à le paramétrer pour ne pas se prendre en compte dans les stats. Cet outil est vraiment adaptéà n'importe qui !

Une dernière verion du célèbre éditeur WYSIWYG TinyMCE vient de sortir.

Enormément de corrections de bug pour les liens, l'édition en plein écran et d'autres encore.
Quelques petits apports aussi, entre autres :

• Ajout simpfilifé des vidéos de Youtube ou Google Vidéo en passant simplement l'URL de celle-ci
• Les boutons d'annulation fonctionnement maintenant avec les plugins
• Un nettoyage du code inutile et réécriture de certaines parties
• Une nouvelle option qui permet de charger un fichier template, pas forcément sur le même site : il est donc possible d'utiliser un même fichier template pour plusieurs sites.

L'annonce de la sortie
Le changelog complet
TinyMCE