Ce que je n'aime pas dans typo3...

(ou en tout cas dans l'installation que j'ai de typo3)

le login n'est pas durablement persistant. Il faut toujours se reloguer. Il y a trop souvent une boite pop up qui revient pour demander de se reloguer. En général elle est filtrée par l'anti pop-up ! Si ce n'est pas le pop up qui revient, il y a une jauge extjs qui vient pour demander de cliquer dessus. Une sorte d'équivalent de la pédale de l'homme mort. Problème, ça ne fonctionne pas ! Peu importe la réponse, il faut toujours que je me relogue quand je vois cette boite. De plus, je n'ai pas encore compris comment elle survient. Il peut se passer des jours sans que je ne la voie et parfois elle surgit direct après le login... c'est toujours encourageant comme accueil !
En parlant de login, il est étrange d'avoir utilisé la balise pour rediriger sur le backend. Un header(.. aurait été plus propre. J'ai découvert ceci lorsque mon firefox ne voulait plus interpréter les refresh html à cause d'un bug de l'extension alexa.
Pourquoi est ce qu'il y des utilisateurs front end et des utilisateurs backend qui sont séparés ? pourquoi avoir fait deux tables séparées. Un type d'utilisateur dans un simple champ n'aurait pas suffit ? Fréquemment, on est obligé de bidouiller avec des synchronisation de ces tables et mettre du contenu à double. C'est assez ennuyant !
ergonomie du backend: je déteste ce système de frame. Jamais moyen d'ouvrir un onglet facilement. Jamais moyen de rafraichir la page pour voir le résultat d'une modification. Il faut toujours faire plus de clique qu'il n'en faudrait avec un système dans une seule page.
Ce système de frame à poussé à créer des fonctions inutiles. Pourquoi avoir un système de "shortcuts" interne. Tous les navigateur on un système de bookmark. Mais c'est vrai, il ne fonctionne pas avec une backend à frame.
Une autre conséquence de ces frames, c'est de ne jamais voir les url. Or c'est la base du web. On se coupe de la géniale barre d'adresse intélligente qui sert également de bookmark.
Typo3 est le champion de la récursivité. Il y a souvent des concepts qui se répliquent à l'infini. Déjà les frames. C'est un site dans le site. Il arrive que les frames se multiplies à l'infini à cause de bug. Mais c'est surtout l'idée que dans typo3 on réinvente souvent la roue. Au lieu d'utiliser un language connu, on en refait un. On code en typoscript du css et du javascript de façon moins propre et moins claire. Il y a des plugins, dans les extentions, dans des plugins. One sait plus trop parfois. Les termes sont peut clairs. Parfois, on a même un framework dans le framework. Comme souvent, l'interface de base TCA, n'est pas très sexy, on recode tout un cms dans le cms, pour avoir une application personnalisée. (bon, c'est un choix. Mais parfois je me demande à quoi sert typo3 si on l'utilise si peu !)
Le RTE que j'utilise ne stocke pas le html (ou pas tout) dans la base. Il le retransforme à la volée. Les liens ne sont pas des balises ce sont des , les paragraphes ne sont pas stocké, ils sont ajouté à la volé sur la base des fins de lignes.
le jeu de cache-cache. ça c'est une vrai plaie. Je veux bien que l'on gagne en performance en utilisant des systèmes de mémoire cache. Mais alors dans typo3, j'ai l'impression que l'on perd beaucoup de temps et d'énergie à cause de ces système. Il y a en a trop, et surtout pas de manière transparente. Pourquoi doit-il y avoir un bouton clear all cache ? surtout que souvent il ne vide pas tout !!! Il faut encore utiliser un no_cache dans l'url, et un clear branche cache.... Un vrai bon système de cache est transparent.
La BD par défaut est énorme et pèse déjà très lourd même vide ! Il n'est pas rare d'avoir plus de 100 tables. Là aussi il y a de nombreuse table de cache ! Pour comparer, par défaut, wordpress à 8 tables !
Dans ce fouilli de table, il y a aussi un fouilli de champs. Donc la plupart ne sont, en général, pas utilisés. Il y a des tables courantes, comme tt_news, tt_address, tx_dam qui reviennent souvent dans plusieurs extensions. C'est pour cette raison que l'on fini par toujours utiliser les mêmes tables pour faire à chaque fois d'autres choses. Il serait certainement mieux de n'utiliser à chaque fois que ce dont on a vraiment besoin. ça évite le syndrome usine à gaz et ça apporte beaucoup de clareté. ça éviterai de perdre du temps à chaque fois en cherchant le champ que l'on veut dans la table parmi plusieurs dizaines.
Parmi les extensions courantes, on retrouve souvent tt_news, qui permet de gérer des news. (étonnant ! :P) Chose qui n'est pas très compliqué. Mais chaque fois que j'ai utilisé tt_news, j'ai eu des ennuis. L'extension buggait mystérieusement et aléatoirement !
Dans les extensions courantes, on utilise fréquemment YAML pour faire le design. C'est un système de template déjà tout fait qui fonctionne avec tout navigateur et qui a prévu de nombreux cas. C'est bien. Pour éviter de devoir se battre avec du css qui passe pas bien dans les navigateurs. Mais souvent, je me bats aussi beaucoup avec la complexité de YAML. Il y a une manière compliquée de mettre à jour les templates. Il y a une feuille de style quasi identique pour chaque modèle avec une ou plusieurs colonne. Je trouve qu'il y a donc beaucoup de redondance. Je me demande si je ne serait pas plus rapide en codant moi-même la feuille de style. Surtout que de nos jours, il y a moins de problème de compatibilité de nvagiateurs web.
Dans YAML, il y a une feuille de style personnal.css qui est sensée être utilisée pour surcharger les styles par défauts. Il y a juste un problème avec cette feuille, c'est qu'elle n'est pas chargée en dernier. Donc elle ne surcharge rien, à moins d'avoir préciser important !. (je suppose qu'en fait cette feuille n'a jamais eu pour vocation de surcharger, mais surtout de compléter des styles.)
Dans la philosophie des gens proche de typo3, j'ai souvent remarqué que le but est d'éviter d'avoir des outils pour permettre d'éviter de devoir écrire du code. C'est louable pour un utilisateur finale qui a des connaissances en programmation limitée. Cependant, j'ai l'impression que ce concept manque sa cible: typo3 se veut être plus un framwork de développement qu'un CMS. C'est à dire que finalement ce sont des développeurs web qui vont utiliser les outils où l'on veut masquer le php pour tenter de développer les mécanismes d'un site. C'est seulement tout à la fin que l'utilisateur finale va utiliser une interface graphique simplifiée pour mettre à jour son site. Donc finalement l'utilisateur finale se retrouve avec une interface un peu usine à gaz, car elle permet de faire des choses qu'il ne fera jamais. Le développeur doit utiliser des outils "graphiques" pleins de formulaire et de typoscript pour éviter d'avoir à code du php, alors que si il est développeur web, il doit logiquement avoir des notions de programmation ?!? Il me semble que l'outils est destiné à une classe d'utilisateur qui est finalement la moins grande: une tranche de poweruser de l'informatique mais qui n'est pas à l'aise avec du code. Personnellement, je suis beaucoup plus à l'aise avec du php qu'avec du typoscript et des centaines de formulaires à remplir.
tesseract. C'est l'outil (presque maison) qui est un pack d'extensions qui travaillent ensemble pour faire un affichage de donnée selon le design pattern: MVC. On y crée graphiquement une requête qui va aller chercher des données, pour les filtrer avec un filtre (il faut de bonnes notion de sql pour utilise ces outils), puis l'on va matcher les données reçu sur un template html, tout ça de manière graphique, pour sortir un contenu. Ce contenu est principalement des listes. Tout ceci est très bien pour des choses simples, très simple. Mais dès qu'il faut ajouter des boutons (filtres de tri, etc) autour de la liste que l'on veut produire. Il est, à mon avis, plus simple et plus souple de tout coder en php. Un outil graphique sera toujours plus limité qu'un language de programmation. Il ne sert à rien de se torturer l'esprit pour trouver comment contourner les limitations de l'outil alors que l'on maitrise un autre outil plus efficace. Si j'utilise un outil, c'est pour qu'il m'aide, ce n'est pas pour me battre contre lui !
Pourquoi utiliser typo3 ? On m'a souvent dit qu'il y a une grande communauté opensource qui fourni beaucoup d'extensions. Désolé, mais mon expérience de typo3 ne me montre pas tellement ça. J'ai voulu utilise un jour un forum. Il y en en avait que 2 à disposition. Or, un forum est quand même quelque chose de courant !!! Sur les deux, aucun n'avait de captcha intégré. Donc c'est le spam assuré dans les quelques jours. A croire que ça n'a jamais été utilisé. Finalement j'ai compris que la communauté typo3 n'est pas si grande, et que surtout elle est vieillissante. Selon google trends, la communauté typo3 est actuellement au plus bas depuis le début des statistiques google en 2004 ! typo3 n'a pas bien passé le cap du web2.0. De nombreuses applications plus séduisantes et modernes sont arrivé dans un domaine où il régait en maitre avant. De même que plone. Drupal et surtout wordpress sont les nouveaux outils populaire depuis 2005. C'est là que se trouve la communauté et les plugins.
Un manque dans typo3 c'est de ne pas avoir de base un système de tag. Mais heureusement pour ça il y a tagpack. Même si l'extension est parfois un peu douteuse sur certain côté.
Je fini tellement par tout faire moi même dans une sorte d'immense patchwork de plusieurs framework et extensions que j'en viens à me poser la question à quoi sert vraiment typo3 dans les sites que l'on fait ? J'ai l'impression de passer plus de temps à me battre contre un outil imparfait que de construire les fonctions dont j'ai besoin.
C'est une détail, mais qu'on aille pas me dire que le backend est ergonomique quand parfois en ajoutant une page, je suis obligé de cliquer sur le bouton rafraichissement de l'arborescence des pages du site pour voir apparaitre la page. Idéalement l'ajout d'une page devrait rafraichir automatiquement ceci non ? c'est si dur que ça ? C'est du au système de frames je suppose.
Dans l'api, il y a des fonctions pour interfacer la base de donnée. Cette api est bien mais pas top. Par exemple, la fonction exec_SELECTgetRows(...) est pratique pour obtenir un tableau à partir des données de la base. Cependant, il est dommage que cette fonction ne mange pas comme paramètre directement le string de la requête sql, mais un version de cette requête coupée en plein de paramètres. Ainsi, pour le debug, je passe mon temps à reconstruire la requête avec les select, from, where, limit ... afin de pouvoir l'afficher.... Je ne vois pas quel est l'avantage de découper ainsi la requête ?

Ce que je trouve pas trop mal dans typo3.

Pour ne pas être négatif, je vais aussi parler de ce que je trouve intéressant dans typo3.

le système de tca qui permet de rapidement fournir une interface graphique d'admin à une structure de base de donnée. (dommage que parfois ce ne soit pas assez joli et qu'on finisse par tout réinventer juste pour faire joli)
le mode page qui permet de choisir et d'arranger dans une page les blocs de contenu.
le système de gestion des permissions permet d'être précis. Il est possible de donner accès uniquement à certaines parties d'arborescence pour des utilisateurs différents.

Comment générer un pdf à partir d'une page web

Il est souvent utile de pouvoir générer un pdf à partir d'un contenu web.

Il existe de nombreuses solutions plus ou moins bonne.

Tout d'abord, il faut savoir que l'html+css et le format pdf sont quand même passablement différents. Il va donc être facile de convertir du contenu dans un format ou dans l'autre. Mais il ne va pas être simple d'avoir la même mise en page dans les deux cas.

Traditionnellement, le pdf est souvent utilisé pour faire des documents que l'on exporte d'un site web. L'exemple typique c'est la facture qui est générée après un achat sur un site de e-commerce.

Pour concevoir ce genre de document, on conçoit un canevas tout fait où il suffit de remplir les données de la marchandises achetée et les données du client.

Pour ce genre d'application on utilise traditionnellement des applications comme pdflib.

Pour faire plus léger, en php, et totalement gratuit, d'autres alternatives on été crées. Il s'agit par exemple de TCPDF.

Cette bibliothèques est utilisée dans de nombreux cms pour exporter directement un pdf à partir d'une page. Bien que le résultat ne soit pas si mal, il est toujours frustrant. Le résultat n'est pas pareil que l'original web.

Ce script est capable de comprendre une partie d'html, mais comprendre les styles css par dessus est trop compliqué.

Une nouvelle idée est apparue: créer un moteur qui interprète le html+css comme n'importe quel navigateur web et sortir l'affichage au format pdf.

C'est ce que fait l'application prince-xml.

Prince est capable de comprendre de nombreuse grammaire xml et de les transformer en pdf. Le résultat est totalement différent de ce qu'un tcpdf est capable de faire ! C'est nettement mieux.

Google utilise cette solution pour générer des pdf à partir de document google docs... Si google n'a pas mieux maison... c'est que le produit est vraiment bien !

Il reste un petit bémole à cette solution qui est probablment la meilleures, c'est que pour une utilisation serveur, il faut une license qui est passablement chère... 3000 dollars australiens.. gloups. Même si le soft vaut certainement son prix... c'est quand même hors de prix pour beaucoup.....

Voilà qu'une nouvelle réflexion s'est faite..... Quand j'imprime une page web depuis safari sur mon mac, directement je peux exporter l'impression en pdf.... on ne peut pas utiliser le soft qui fait ça ??

Et effectivement, en creuseant de ce côté il y a moyen de faire quelque chose. Les basses couche de safari, webkit, sont opensource. Il reste juste les hautes couches applicative à bidouiller, mais le plus dur est fait, comprendre le html+css qui est vraiment de plus en plus complexe.

C'est ainsi qu'est née l'application wkhtmltopdf, c'est une application opensource qui est maintenant à maturité. Elle permet très simplement de faire juste ce qu'on lui demande, manger de l'html+css pour en resortir un pdf.

Personnellement, je suis assez bluffé. Pas mal du tout. Les petits à côté sont sympa aussi. Ce que j'aime beaucoup, c'est la génération automatique de la table des matières et le fait de pouvoir ajouter directement une page de titre.

Voici la commande qui permet de générer un fichier pdf à partir d'une page web tout en ajoutant au début du document une page de table des matières qui a pour titre "Table des matières".

wkhtmltopdf -t --toc-header-text "Table des matières" monfichier.html monfichier.pdf

Voilà, j'ai maintenant tout ce qu'il me faut pour avoir un traitement de texte complet dans un simple navigateur web.

C'est ce que j'utilise ici pour écrire ces lignes.

Un couplage de tinyMCE pour la partie écriture wysiwyg, puis j'enregistre et gère mes documents l'application web que j'ai codée, puis j'exporte les documents que j'écris à l'aide de wkhtmltopdf.

Merveilleux !

Pourquoi s'ennuyer avec M$ office... ou même openoffice... qui sont des suite bureautique de plus en plus lourdes pour ne pas faire grand chose de plus qu'il y a 15 ans dans le traitement de texte !

Étiquette : themeGeek