[Yucky]

Mmmh trouvé,

Pour les versions 4.2.x de Typo3 utilisez la version 0.0.5
Pour les versions 4.3 de Typo3 utilisez la dernière version

[Oom Paul]

Yucky, le 02/04/2010, 13:36, dit :

Mmmh trouvé,

Pour les versions 4.2.x de Typo3 utilisez la version 0.0.5
Pour les versions 4.3 de Typo3 utilisez la dernière version

rhâââa^ces français : http://forge.typo3.o...ension-modernbe
quand on cherche ...

[Yucky]

Oom Paul, le 02/04/2010, 16:07, dit :

Yucky, le 02/04/2010, 13:36, dit :

Mmmh trouvé,

Pour les versions 4.2.x de Typo3 utilisez la version 0.0.5
Pour les versions 4.3 de Typo3 utilisez la dernière version

rhâââa^ces français : http://forge.typo3.o...ension-modernbe
quand on cherche ...

Et ben ? ...Pour les versions c'est pour l'extension kb_nescefe...

Sinon par rapport à modernBe, très dommage de parler d'une alternative à TV sans préciser qu'elle ne sera disponible que dans la 4.4 ... quand on voit que la 4.3 est déjà pas exploitable en prod, l'arrivée de la 4.4 paraît... irréaliste.

Donc on aura pas d'alternative avant un bon moment !

Sinon par rapport à kb_nescefe c'est déjà une très belle alternative, je n'ai pas fini de la paramétrer, mais elle offre des possibilités déjà vraiment très intéressantes ! A suivre de près je pense

[Popy]

@Rakel : Je sais que c'est le nom du champ dans le XML, le souci est que tu ne peux pas l'extraire d'où tu veux.
Je sais, je suis désespérant

[rakel]

Popy, le 06/04/2010, 11:26, dit :

@Rakel : Je sais que c'est le nom du champ dans le XML, le souci est que tu ne peux pas l'extraire d'où tu veux.
Je sais, je suis désespérant

alors je manque de temps mais promis je t'envoie le code dès que j'ai 5 min. Le principe c'est que kb_tv_cont_slide permet non seulement de slider mais aussi de récupérer des contenus d'une autre page :
http://typo3.org/documentation/document-li.../1/2/#id4321448

l'idée est donc d'utiliser ce principe dans le TS proposé plus haut.

Je me demande si on devrait pas faire plus tard un post plus propre avec les script de slide et et random avec TV.

[rakel]

réponse ci-dessous :
(on utilise kb_tv_cont_slide qui est bien utile et permet de récupérer une liste d'id de contenus de n'importe qu'elle page et n'importe quel champ)

        10 = CONTENT
        10.table = tt_content
        10.select {
        	pidInList = 1
        	recursive = 20
                max = 1
                orderBy = rand()
                andWhere {
                        preUserFunc = tx_kbtvcontslide_pi1->main
                        preUserFunc.field = contenu2
                        preUserFunc.table = tt_content
                        preUserFunc.overridePage = 60
                        preUserFunc.collect = 1
                }
                andWhere.wrap = uid IN(|)
        }

NB : habituellement on utilise tx_kbtvcontslide_pi1 en postUserFunc, mais ici, il faut une preUserFunc, sinon le wrap ne fonctionnerait pas car il passerait avant.

[duch]

Je comprends mieux maintenant.

Ok, ça marche, mais on ne peut pas vraiment dire que soit simple...

Donc, encore une fois tu as démontré que c'était possible, bravo, mais ça me renforce dans l'idée que beaucoup de choses triviales deviennent casse-têtes avec TV.

[Julien Renier]

- Si TV était aussi génial que ça, ça ferait longtemps qu'il aurait été intégré au core de Typo3.
- un site bien fait doit pourvoir s'administrer simplement, et pour cela, le BE Typo3 standard suffit. S'il est nécessaire d'avoir recours à un BE plus évolué (TV), c'est qu'il y a un problème de conception / d'organisation de l'information dans le site. Donc autant repenser l'ergonomie du site avant de proposer un BE alambiqué.
- ma première (et seule) expérience avec TV remonte à il y a 3 ans, après avoir mis pas mal de temps à m'imprégner de la logique du DS/TO, j'ai réussi à faire ce que je voulais, puis en un seul click j'ai perdu tout le mapping ; tout à refaire. Depuis je ne touche plus à TV.
- Aujourd'hui je referais ce premier site en Typoscript et automaketemplate en moins de 2 jours.
- Je deteste les "boites noires", qui plus est buggées ; déjà que le concept (génial) du TS est assez surprenante, alors autant ne pas en rajouter.
- TV peut empêcher les intégrateurs Typo3 de plonger réellement dans les entrailles de Typo3. Si bien qu'ils ne savent pas ce qu'ils font, ou en tous cas le gain d'expérience du cms est bridé par cette couche. Je ne dis pas qu'il est nécessaire de mettre les mains dans le moteur pour bien programmer, mais juste que si on ne le fais pas on passe à côté de trucs et astuces qui font gagner du temps/de la qualité.

La nouvelle version du FEEdit de Typo3 4.3 est trèèès bien et à mon avis couvre 90% des besoins du contributeur lambda (j'en saurais plus avec un retour d'expérience dans qq temps. Je viens de livrer un site fait avec la 4.3).

[CMD]

Ça fait bien longtemps que je n'ai pas posté ici, mais j'aime bien les débats

Avant toute chose, j'ai longtemps était hermétique à TV, mais de l'eau à coulé et les choses ont changé.

Il faut bien recadrer l'ensemble:
Le BE typo3 est bien tel quel et se suffit à lui même 90% du temps.
TV est plus que pratique dans des cas particulier où le client à des demandes très spécifiques.
jetts, jamais mis les pieds dedans.
automake template, je n'y vois aucune utilité c'est juste une ptite amélioration du BE standard.

TV apporte un gros plus dans la souplesse et dans l'utilisation pour un client. Certes il peut compliquer la vie des devs, mais en même temps, si on se casse pas la tête de temps en temps que nous reste-t-il?

Pour répondre un peu a Julien:

Julien Renier, le 09/04/2010, 15:18, dit :

- Si TV était aussi génial que ça, ça ferait longtemps qu'il aurait été intégré au core de Typo3.

Comme tu le dit, c'est génial, pas indispensable... de plus s'il avait été intégré dans ses premières version (très bugué il faut l'avouer) aujourd'hui la donne est différente, et il est de plus en plus difficile de perdre un mapping.

Julien Renier, le 09/04/2010, 15:18, dit :

- un site bien fait doit pourvoir s'administrer simplement, et pour cela, le BE Typo3 standard suffit. S'il est nécessaire d'avoir recours à un BE plus évolué (TV), c'est qu'il y a un problème de conception / d'organisation de l'information dans le site. Donc autant repenser l'ergonomie du site avant de proposer un BE alambiqué.

Pas forcement, toujours le problème de cas spécifique. Typo3 n'est pas là que pour faire du site, on peut en faire des intranets très spécifique et sophistiqué. Dans ce cas là tu peux avoir besoin de certain fonctionnement de TV (mais a ce moment là, le BE ne sera pas forcement accès rédacteur).

Julien Renier, le 09/04/2010, 15:18, dit :

- ma première (et seule) expérience avec TV remonte à il y a 3 ans, après avoir mis pas mal de temps à m'imprégner de la logique du DS/TO, j'ai réussi à faire ce que je voulais, puis en un seul click j'ai perdu tout le mapping ; tout à refaire. Depuis je ne touche plus à TV.

Idem, mais bcp de choses ont changé

Julien Renier, le 09/04/2010, 15:18, dit :

- Aujourd'hui je referais ce premier site en Typoscript et automaketemplate en moins de 2 jours.

Avec une bonne biblio de TS faite maison pour ton utilisation, le temps de dev sera identique et tu n'aura pas besoin de automake

Julien Renier, le 09/04/2010, 15:18, dit :

- Je deteste les "boites noires", qui plus est buggées ; déjà que le concept (génial) du TS est assez surprenante, alors autant ne pas en rajouter.

Si le TS est génial, il se suffit à lui même, pourquoi à ce moment là utilisé automake et risquer de tomber sur une "boites noires" justement?

Julien Renier, le 09/04/2010, 15:18, dit :

- TV peut empêcher les intégrateurs Typo3 de plonger réellement dans les entrailles de Typo3. Si bien qu'ils ne savent pas ce qu'ils font, ou en tous cas le gain d'expérience du cms est bridé par cette couche. Je ne dis pas qu'il est nécessaire de mettre les mains dans le moteur pour bien programmer, mais juste que si on ne le fais pas on passe à côté de trucs et astuces qui font gagner du temps/de la qualité.

Rien ne t'empêche de mettre les mains dans le cambouis... la structure de TV est un assemblage de TS, pourquoi ne pas les modifier? j'ai eu fait ça plusieurs fois afin d'obtenir le résultat escompté. C'est open comme système...

Julien Renier, le 09/04/2010, 15:18, dit :

La nouvelle version du FEEdit de Typo3 4.3 est trèèès bien et à mon avis couvre 90% des besoins du contributeur lambda (j'en saurais plus avec un retour d'expérience dans qq temps. Je viens de livrer un site fait avec la 4.3).

Pas encore vraiment testé, j'avais vu les beta, pas trop convaincu car encore bugué et je me pose la question des tt_content qu'on pourrais rajouter, comment seront-ils gérés, n'auront-il pas de bug, pire encore, un plugin comment on le modifie en front? (d'ailleurs si qqun a les réponses, ou une vidéo montrant ces cas de figure je suis preneur).

Désolé d'avoir utilisé ton post pour répondre Julien mais c'était le dernier en date n'y vois pas une attaque personnelle.

Quoi qu'il en soit je suis vieux jeu et aime le codage à l'ancienne (cad les bases de typo3 et du TS, je fait pas du html 0.2beta4 ) mais il me reste à travers l'esprit (ça m'étonne ainsi que certain membre du forum surement) que TV est une réponse adéquate dans certain cas et que je suis prêt à l'utiliser.

Amicalement

[phf64]

Suite à cette question que j'ai posé sur le forum, et qui n'a pas reçu de réponse, je dirais que TV possède là un avantage considérable sur les autres méthode de templating, d'un point de vue "rédacteur".
Devoir passer par le module liste pour faire du copier/coller de contenu ou devoir éditer un contenu pour le faire passer d'une colonne à l'autre sont des manipulations qui sont loin d'être évidente pour un "rédacteur lambda", et qui ne facilitent pas l'adoption de TYPO3.
L'usage de TV permet de proposer aux rédacteurs une seule interface, le module "Page", avec des fonctionnalités "sexy", comme le glisser/déposer. Leur résistance à l'adoption de l'outil est ainsi bien moindre, et c'est quand même la satisfaction de l'utilisateur final qui fait le succès d'un projet.

[Oom Paul]

ce n'est plus le cas avec "grid layout" qui est dans la version 4.5... ou en tout cas c'est "moins" le cas...

[phf64]

Le BE grid layout permet juste d'améliorer le look du BE, pour faire un peu plus "coller" la disposition des éléments à la disposition FE, mais le copier / coller directement dans le module "Page", seul TV le propose, et pour ma part, c'est quand même un élément d'ergonomie fondamental pour un rédacteur.

D'ailleurs, y a t'il quelque part une "feature request" en ce sens? Je n'ai pas encore cherché pour ma part, juste testé cette extension, kb_pm_paste, mais pas satisfaisant.

[Popy]

phf64, le 28 janvier 2011 à 11:19, dit :

Devoir passer par le module liste pour faire du copier/coller de contenu

Mode page standard, click sur l'icone du contenu, ho, magie, un bouton couper

phf64, le 28 janvier 2011 à 11:19, dit :

ou devoir éditer un contenu pour le faire passer d'une colonne à l'autre sont des manipulations qui sont loin d'être évidente pour un "rédacteur lambda", et qui ne facilitent pas l'adoption de TYPO3.

Il existe des extensions permettant de faire du drag & drop sur le mode page standard

D'un point de vue développeur, TemplaVoila a un inconvénient particulièrement gênant : le stockage en bdd

[phf64]

Merci Popy de rallumer la lumière.

Effectivement, j'avais oublié le clic droit. Je retire le point accordé à TV.
Mais pourquoi donc ne pas mettre cette action directement dans la barre d'outil? Car toujours en me plaçant du point de vue de mes "rédacteurs standards", le clic droit ne leur est pas une action très "évidente" (d'ailleurs, je l'avais zappé moi-même).

Pour ce qui est des extensions qui font du drag&drop, pas trouvé . Un exemple?

Et pour le dernier point, c'est sûr, mais c'est le coté "contributeur" que je cible là.

[OlivierSC]

pour Popy:

Sur une installation de base, il est effectivement possible de copier/couper en cliquant sur l'icone...

par contre il est plus difficile de coller le contenu là où on veux...

- Il est possible de coller via le menu visible lorsque l'on clique sur la page dans l'arborescence, cela va coller le contenu dans la meme colonne que la colonne d'origine du contenu collé.

- Il est possible de coller en cliquant sur la meme icone que celle qui a servit à copier, cela déposera le contenu juste en dessous.

- par contre il me semble impossible de base de coller du contenu dans une colonne VIDE.

OlivierSC

[phf64]

Un petit récap pour obtenir le même comportement qu'avec TV:
- on peut copier / couper un contenu avec le menu 'clic droit' en mode "Page".
- on peut le coller où on veut dans la page grâce à l'extension kb_pm_paste, qui prend en charge le changement de colonne.

Par contre, il me manque la/les extensions qui permettent de faire ceci en Drag&Drop.

[guigui_rondat]

Bonjour à tous,

Je ne veux pas relancer ce vaste sujet (quoique, de l'eau a coulé sous les ponts, pourquoi pas faire un point...), mais j'ai une question subsidiaire.

Un principe intéressant de Templavoilà est le fait de pouvoir diffuser un contenu sur plusieurs pages (sans utiliser de TypoScript bien sûr...) grâce à la fonction de "Copie par référence".
C'est effectivement une lacune assez importante (même s'il y a sans doute d'autres moyen mais quand même) de Typo3, dont l'arborescence se limite à une arborescence de pages (d'ailleurs il n'est pas non plus possible de rattacher une page à plusieurs parent facilement sauf erreur de ma part).

Bref, y a-t-il des solutions sans utiliser TV pour mutualiser un contenu standard (Texte, etc...) et le rattacher à plusieurs pages (quelque soit le colPos) ?

Merci,

Guillaume

[Popy]

COntenu de type "insérer un enregistrement"

[guigui_rondat]

Popy, le 14 février 2012 à 18:05, dit :

COntenu de type "insérer un enregistrement"

Effectivement, j'allais dire que c'était un peu lourd, mais bon ça répond au besoin, surtout qu'on peut accéder à l'édition du contenu sans connaître la page sur laquelle il est à l'origine.

J'en profite pour poser une autre question, en lien avec le sujet de ce post tout de même.

Par rapport à l'utilisation d'un objet TEMPLATE basique pour gérer la template des pages, quels sont les intérêts d'utiliser à la place :
- automaketemplate
- Jetts (je ne connais pas, mais le principe de base me semble assez proche)
- un autre système ?

Concrètement, aujourd'hui j'ai un site qui est fait "à l'ancienne" avec des TEMPLATE. Je ne trouve pas ça idéal, car au final c'est un peu le bazar dans tous les setups pour définir ou redéfinir des "page.10.marks" etc...
Donc j'aurais envie d'utiliser autre chose, mais j'ai l'impression que ca va revenir au même (je vais éviter d'utiliser Templavoilà, car là ça me ferait tout casser).
J'ai du mal à trouver de bons arguments de comparaison entre ces différentes méthodes.

Merci pour vos réponses,

Guillaume

[Popy]

automaketemplate : intéret très limité. Si c'est bien configuré, ça te permet d'utiliser des HTMLs sans passer par la case "je met mes marqueurs la dedans".
Je ne l'ai utilisé qu'une fois parce que je recevait un nouveau html chaque jour.

jetts : jamais utilisé, ça m'a l'air mignon tout plein, mais le mapping en clicaudrome, j'y vois peu d'intéret (je ne dis certainnement pas ça pour provoquer les papas de jetts )

Perso, le système de TEMPLATE me conviens pas trop mal. Ca mériterais quelques ajustements, quelques améliorations, mais globalement ça suffit.
Si c'est le bazard dans tes setups, t'en es le seul responsable. Je suis partisant d'un seul setup, le plus simple possible, le plus clair possible.

[guigui_rondat]

Merci Popy pour ta réponse.

Et quid du nouvel object FLUIDTEMPLATE ?

[Popy]

A voir. Tu va y trouver des fonctionnalités supplémentaire dans ton gabarit, mais je doute qu'elles soient exploitables (le typoscript ne retournant que des strings, jamais de listes d'objets), et tu y perd (en théorie) la possibilité de visualiser ton template comme un simple fichier html.