Méthodes d’intégration avec TYPO3: 01 La méthode classique historique

La méthode classique pour intégrer son site avec TYPO3 consiste à ajouter des ###MARKERS### ou des ###SUBPARTS### ###SUBPARTS### pour remplacer, ou encadrer les zones qui ont pour vocation d’être dynamique dans votre site internet.

Ces zones sont remplacer avec du typoscript, qui va dynamiquement récupérer des valeurs, ou vous permettre de saisir du contenu via le back-office ou le front-office.

Avantages

Natif, pas de temps de calcul ou de sur-couche de traitement
L’ajout de markers est très simple
Fonctionne avec la majorité des extensions
Pas de bugs
Les données sont stockées tel-quel en base
Les fichiers HTML sont simples à modifier par un profil développeur Frontend

Inconvénients

Backend trop limité pour un site complexe
Difficile de présenter le backend de manière ergonomique sur un site complexe
Obligation de créer des extensions pour créer des éléments de contenus spécifiques
Difficile de mutualiser les intégrations déjà réalisées
Pas de framework HTML intégré

Profils métier nécessaires à l’intégration

Intégrateur TYPO3
Développeur Frontend
Développeur PHP dans certains cas

Du point de vue du client

Adapté à un site simple
Backend très fouillis pour un site complexe
Possibilité de modifier facilement les Templates
Facile de trouver un prestataire pour faire évoluer le design

En savoir plus

Tutoriel historique de l’intégration classique avec TYPO3: Modern Template Building
Une documentation en Français ( format pdf ) http://www.gdidees.eu/userfiles/file/docs/livre_typo3.pdf

Publié

mai 18, 2013

dans

Backend, Frontend, Intégration TYPO3

par

Cyril WOLFANGEL

Étiquettes :

comparatif, Flow, Fluid, intégration TYPO3, templavoila, typoscript

Commentaires

12 réponses à “Méthodes d’intégration avec TYPO3: 01 La méthode classique historique”

Popy

mai 18, 2013

Inconvénients
* Backend trop limité pour un site complexe
Fake, le grid layout rend la chose faissable sans difficulté

* Difficile de présenter le backend de manière ergonomique sur un site complexe
Je suis presque certain que le display du grid layout est customizable

* Difficile de mutualiser les intégrations déjà réalisées
Pourquoi donc ? Rien n’empèche de faire des libs de ts / templates.

Et il manque un inconvénient : La majorité des tutoriaux nobrain recommandent de mettre le ts en base et les html / css / images dans fileadmin, ce qui est contre productif.

Répondre
1. Cyril Wolfangel
  
  mai 18, 2013
  
  Wow le roi des Trolls est le premier à répondre, bizarrement je ne suis pas surpris :)
  Je vais parler du backend layout dans un autre article, effectivement ça change la donne.
  
  Répondre
Méthodes d’intégration avec TYPO3: 02 Templavoilà | Cyril Wolfangel

mai 20, 2013

[…] Le backend peut devenir beaucoup plus attrayant qu’avec la méthode classique historique […]

Répondre
Grégory Copin

mai 21, 2013

Quelqu’un utilise encore cette méthode sans au minimum automaketemplate et des plugins de FCE ? Tu souhaitais peut-être compléter cette méthode via plugins dans un autre article ?

Tu connais sans doute très bien toutes les méthodes de templatage, mais j’ai écrit deux articles là dessus. Si ça peut te faire gagner du temps pour retrouver le nom des plugins alternatifs par exemple, les voici :
http://www.test4u.fr/2012/05/20/typo3-sans-templavoila/
et
http://www.test4u.fr/2012/05/22/fusionner-les-methodes-de-template-de-typo3/

Répondre
Popy

mai 22, 2013

« Quelqu’un utilise encore cette méthode sans au minimum automaketemplate et des plugins de FCE ? »
Ben, oui :)

Répondre
1. Grégory Copin
  
  mai 22, 2013
  
  Pourquoi n’utilises-tu pas automaketemplate ? C’est quand même plus sympa que de se retrouver avec les markers dans le HTML, non ?
  
  Répondre
Popy

mai 22, 2013

Parce que j’ai pas besoin d’un morceau tout merdique de code sans cache spécifique pour ajouter 3 marqueurs dans un template HTML.

Répondre
1. Cyril Wolfangel
  
  mai 31, 2013
  
  Pareil, je n’ai jamais utilisé automake, justement, avec les subparts commentées tu peux cacher tes markers du gabarit, et au moins la vision des zones dynamique est claire dans le template en mode source, et pas de sur-couche.
  
  Répondre
Aude

mai 23, 2013

Backend_layout permet de faire une mise en forme très proche de ce que l’on a avec templavoilà.
Il existe une extension, grid_elements, qui permet de faire l’équivalent des FCE. Et avec kb_nescafe on peut créer du multicolonne ou des contenus avancés également.
Il n’est donc pas (toujours) nécessaire de créer des extensions pour créer des éléments de contenus spécifiques.
Pour la mutualisation je ne comprends pas ce que tu entends par là ?

Concernant l’argument « backend très fouillis », c’est à quel niveau ?

Pour répondre à Grégory, nous n’utilisons plus automaketemplate depuis… la 4.2 de TYPO3…

Et donc je plussoie Popy, comme d’habitude….

Répondre
1. Cyril Wolfangel
  
  mai 26, 2013
  
  Je comptais traiter les backend layout avec le grid-elements dans un articles à venir.
  Assez d’accord avec toi sur le fond, mais je trouve tout de même que le backend de kb_nescafe ne vaut pas celui d’un backend layout ou d’un templavoila framework.
  
  Répondre
2. Cyril Wolfangel
  
  mai 31, 2013
  
  Salut Aude,
  J’ai réparé l’injustice dans ce nouveau post: http://www.cyril-wolfangel.com/2013/05/31/methodes-dintegration-avec-typo3-04-la-methode-classique-actuelle-avec-backend-layout-et-grid-elements/
  Effectivement, l’intégration classique moderne corrige bien des défaut de la méthode historique !
  
  La mutualisation, j’entendais la réutilisation de templating pour d’autre intégration. C’est très facile avec Templavoilà Framework par exemple et son système de skin. Du coup tu peux aussi facilement changer l’apparence d’un site, sans modifier le backend ni les contenus clients.
  
  Répondre
Popy

mai 23, 2013

Elle en veut a mon corps, j’en suis sûr !

Répondre

Laisser un commentaire Annuler la réponse

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.