Import de template de Dreamweaver vers Bluegriffon
Fermé
Calispera
Messages postés
1
Date d'inscription
mercredi 27 octobre 2021
Statut
Membre
Dernière intervention
27 octobre 2021
-
27 oct. 2021 à 13:29
Calispera - 15 janv. 2022 à 15:14
Calispera - 15 janv. 2022 à 15:14
A voir également:
- Bluegriffon templates
- Bluegriffon français - Télécharger - HTML
- Les templates en C++ - Astuces et Solutions
- Openoffice impress templates - Forum LibreOffice / OpenOffice
- Templates php gratuits - Forum PHP
- Templates joomla 4 - Forum Créer un site
4 réponses
Salut,
Pour répondre vite non ce n'est pas possible et pas souhaitable!
laissez tomber le WYSIWYG cela ne permet pas de faire des sites corrects à bien des égards.
C'est d'ailleurs le cas si votre site fait 150 pages il y a 140 pages de trop*.
Les contenus similaires doivent être automatisés:
en gros et sans rentrer dans les détails un modèle de page permet de changer le contenu de la page. Ce sont les sites dynamiques et l'ensemble des sites modernes doivent l'être car ça permet justement de pouvoir changer / mettre à jour des contenus et modifiant les contenus sur la base de données sans changer la présentation (ou modèle de la page). C'est justement le point fort des CMS et l'origine de leurs noms (Content Management System ou en français logiciel de gestion de contenus).
Le problème de la création/édition en WYSIWYG est inhérent au WYSIWYG et vous vous y retrouvez confronté. Les problèmes plutôt:
1)dans la création de site web la règle d'or et de séparer 3 parties qui correspondent d'ailleurs à différents aspects techniques donc à leur gestion et surtout leur utilisation. C'est le principe même et concept des pages web dans son aspect conceptuel comme technique( voir par exemple le rôle de HTML, ce qu'est un système d'informations appliqué à la gestion des données)
Le WYSIWYG en apportant une solution uniquement basé sur le visuel/présentation à tendance à oublier les autres aspects et donc ne pas satisfaire les nécessités du web(= un site de mauvaise qualité = un impact sur plusieurs aspects qui ne sont pas correctement effectués aussi bien dans l concept que techniquement). L'approche WYSIWYG n'est donc pas une approche valable et explique la disparition de tels outils au profit des CMS qui ont une approche qui s'attache à respecter le cadre et les normes et nécessités des pages web.
2)Le WYSIWYG automatise la création mais à grands prix. Outre le point précédent le résultat est la création d'une écriture des pages(les pages web s'appuient sur différents fichiers de différents langages c'est le principe de l'hypertexte) est vraiment mauvais même s'il peut paraître fonctionnel. Comme pour le point précédent le WYSIWYG s'axe sur l'apparence au détriment du reste(gestion et qualification des données: essentiel et nécessaire dans le web) C'est à dire que la formation même de vos pages(scripts et écriture des fichiers) est illisible incompréhensible par un humain et bien sûr ne peut satisfaire par automatisation tout ce que ne sait pas faire une automatisation. Par exemple assurer la valeur sémantique et le respect des normes et règles d'écriture. En gros un site WYSIWYG n'est pas pérenne et dépendant de l'éditeur utilisé. Un exemple simple et concret avec DW:
En utilisant cet éditeur une série de fonctions JavaScript peuvent être utilisés. Non seulement le résultat rends indispensable le logiciel Dreamweaver pour fournir ces fonctions et celles ci peuvent ne pas satisfaire les besoins de qualité
exemple concret : dans le cas d'un survol qui changerait une image d'un menu utiliser de la programmation alors que la solution correcte est de ne pas utiliser la programmation mais le langage dédié à la présentation/mise en page de l'affichage: CSS. Dans cet exemple non seulement à la base le rendu de l'interactivité(changer une image et rendre un bouton plus beau et clair visuellement) n'est pas implémenté correctement mais dépends de la bibliothèque de programmation(des fonctions) utilisée mais aussi cette approche rends quasiment impossible la mise à jour/modification de façon simple ne serait ce que pour satisfaire aux nécessités de mises à jour qui concerne l'évolution et l'amélioration des possibilités techniques et normes du web(qui vont de pair et sont constantes).
Vous vous y retrouvez confrontés et ce sera quasiment impossible pour vous de reprendre des fonctions de DW dans Blue Griffon parce que DW à son propre 'logiciel' de fonctions et Blue Griffon aussi.
Bref le WYSIWYG fournit un code indigeste(et incompréhensible pour un humain), peu respectueux des normes et donc rends celui ci non modifiable et dépendant de l'éditeur utilisé jusque dans la version utilisé(si l'éditeur WYSIWYG est encore mis à jour ce qui est une gageure comme vous avez pu le constater avec le quasi abandon de DW par clui qui fournit le logiciel, pourtant une entreprise pro reconnue dans le domaine de la création informatique/multimédias).
Pour résumer abandonnez le WYSIWYG pour passer aux CMS (comme Wordpress, Joomla, Spip...qui sont d'ailleurs disponibles au moins dans une version gratuite et libre d'utilisation ) qui vous permet une approche plus viable tandis que ce n'est pas le cas du WYSIWYG. Ce que vous gagnez en facilité de création vous le perdrez simplement en qualité intrinsèque du site et ce n'est pas un point mineur car ces qualités nécessaires sont obligatoires. Paradoxalement il vaut être connaisseur expérimenté pour utiliser un logiciel WYSIWYG pour obtenir un résultat qui soit un tant soit peu correct et un connaisseur aura à sa disposition de meilleurs outils pour créer des sites. Donc le WYSIWYG c'est mort si vous tenez à faire un site de qualité. Surtout que utiliser un CMS peut s'avérer aussi simple et facile mais avec une différente approche, une approche plus proche des réalités techniques et nécessités (normes et aspects à satisfaire) de la création et édition de vos communications à fournir(pour rappel la séparation distincte des contenus, de leur mise en forme et qualification/sémantique) tout en satisfaisant une modularité et des possibilités plus importantes qu'avec le WYSIWYG et une possibilité de mises à jour qui n'existe pas avec une approche qui ne considère que l'aspect visuel qui n'est pas en accord avec la réalité de ce qu'il se passe et les contraintes nécessaire d'un site.
Donc oui cette façon de faire (le WYSIWYG) est périmé car son approche même oblige à tout recommencer si l'on doit modifier quelque chose dans la structure, pour satisfaire les exigences de qualités des nouvelles normes(que n'ont pas les versions précédentes du logiciel) et c'est bien cet aspect qui a précipité le déclin et l'abandon progressif(il y a une quinzaine d'année avec l'apparition de CMS de qualités) de tels logiciels et à la base permet très difficilement des contenus corrects par son approche qui est déconnecté de la réalité et des nécessités techniques et conceptuelles. Quand les CMS permettent (il y a bien sûr des règles et écueils à éviter aussi mais moins nombreux) un contenu et la présentation comme gestion et valorisation des contenus adaptés aux spécificités du web, par la même une pérennité par la possibilité de mise à jour directement de l’ossature et nécessités sémantiques(description; qualification et valorisation des contenus servant à les rendre accessible et repérable par un moteur de recherche) comme technique et de leur évolution éventuelles au cours des années ainsi que des pages aux contenus dynamiques(comme il faut faire les sites de nos jours) quand cet aspect est assez rugueux (pour pas dire autre chose) avec une approche appuyé sur la présentation/visuel uniquement.
CQFD, bon travail
(*)si ce n'est pas le cas et qu'il y a vraiment 150 pages différentes (je ne parle pas du contenu uniquement mais bien de pages qui n'ont rien à voir entre elles) c'est aussi un problème mais de conception: un nombre élevés de pages différentes et présentant des contenus vraiment différent dans leur idées (au delà d'une dizaine de pages) rend simplement ces contenus obscurs et inatteignables pour les utilisateurs. En effet imaginez une utilisateur qui a le choix entre 30 pages qui n'ont rien à voir entre elles. Même avec un menu de présentation clair cela est trop complexe, ne donnera pas envie à l'utilisateur de se creuser la tête pour les trouver et même si c'est lle cas ça rends la navigation complexe et fastidieuse hors n'importe quel document ou communication se doit d'avoir la qualité inverse: clair et facilement accessible à tous les niveaux. Cela s'appelle l'ergonomie web(la prise ne main du site) et ne pas y faire attention fait des sites de qualités médiocres à tout point de vue(tout comme la valorisation sémantique et des contenus présentés, c'est à dire le référencement et la possibilité de diffuser ces contenus). La solution est donc une meilleure organisation des données et une réduction effective du nombre de pages ou si les contenus n'ont vraiment aucun lien entre eux simplement plusieurs sites différents sur un thème/sujet donné.
Pour répondre vite non ce n'est pas possible et pas souhaitable!
laissez tomber le WYSIWYG cela ne permet pas de faire des sites corrects à bien des égards.
C'est d'ailleurs le cas si votre site fait 150 pages il y a 140 pages de trop*.
Les contenus similaires doivent être automatisés:
en gros et sans rentrer dans les détails un modèle de page permet de changer le contenu de la page. Ce sont les sites dynamiques et l'ensemble des sites modernes doivent l'être car ça permet justement de pouvoir changer / mettre à jour des contenus et modifiant les contenus sur la base de données sans changer la présentation (ou modèle de la page). C'est justement le point fort des CMS et l'origine de leurs noms (Content Management System ou en français logiciel de gestion de contenus).
Le problème de la création/édition en WYSIWYG est inhérent au WYSIWYG et vous vous y retrouvez confronté. Les problèmes plutôt:
1)dans la création de site web la règle d'or et de séparer 3 parties qui correspondent d'ailleurs à différents aspects techniques donc à leur gestion et surtout leur utilisation. C'est le principe même et concept des pages web dans son aspect conceptuel comme technique( voir par exemple le rôle de HTML, ce qu'est un système d'informations appliqué à la gestion des données)
Le WYSIWYG en apportant une solution uniquement basé sur le visuel/présentation à tendance à oublier les autres aspects et donc ne pas satisfaire les nécessités du web(= un site de mauvaise qualité = un impact sur plusieurs aspects qui ne sont pas correctement effectués aussi bien dans l concept que techniquement). L'approche WYSIWYG n'est donc pas une approche valable et explique la disparition de tels outils au profit des CMS qui ont une approche qui s'attache à respecter le cadre et les normes et nécessités des pages web.
2)Le WYSIWYG automatise la création mais à grands prix. Outre le point précédent le résultat est la création d'une écriture des pages(les pages web s'appuient sur différents fichiers de différents langages c'est le principe de l'hypertexte) est vraiment mauvais même s'il peut paraître fonctionnel. Comme pour le point précédent le WYSIWYG s'axe sur l'apparence au détriment du reste(gestion et qualification des données: essentiel et nécessaire dans le web) C'est à dire que la formation même de vos pages(scripts et écriture des fichiers) est illisible incompréhensible par un humain et bien sûr ne peut satisfaire par automatisation tout ce que ne sait pas faire une automatisation. Par exemple assurer la valeur sémantique et le respect des normes et règles d'écriture. En gros un site WYSIWYG n'est pas pérenne et dépendant de l'éditeur utilisé. Un exemple simple et concret avec DW:
En utilisant cet éditeur une série de fonctions JavaScript peuvent être utilisés. Non seulement le résultat rends indispensable le logiciel Dreamweaver pour fournir ces fonctions et celles ci peuvent ne pas satisfaire les besoins de qualité
exemple concret : dans le cas d'un survol qui changerait une image d'un menu utiliser de la programmation alors que la solution correcte est de ne pas utiliser la programmation mais le langage dédié à la présentation/mise en page de l'affichage: CSS. Dans cet exemple non seulement à la base le rendu de l'interactivité(changer une image et rendre un bouton plus beau et clair visuellement) n'est pas implémenté correctement mais dépends de la bibliothèque de programmation(des fonctions) utilisée mais aussi cette approche rends quasiment impossible la mise à jour/modification de façon simple ne serait ce que pour satisfaire aux nécessités de mises à jour qui concerne l'évolution et l'amélioration des possibilités techniques et normes du web(qui vont de pair et sont constantes).
Vous vous y retrouvez confrontés et ce sera quasiment impossible pour vous de reprendre des fonctions de DW dans Blue Griffon parce que DW à son propre 'logiciel' de fonctions et Blue Griffon aussi.
Bref le WYSIWYG fournit un code indigeste(et incompréhensible pour un humain), peu respectueux des normes et donc rends celui ci non modifiable et dépendant de l'éditeur utilisé jusque dans la version utilisé(si l'éditeur WYSIWYG est encore mis à jour ce qui est une gageure comme vous avez pu le constater avec le quasi abandon de DW par clui qui fournit le logiciel, pourtant une entreprise pro reconnue dans le domaine de la création informatique/multimédias).
Pour résumer abandonnez le WYSIWYG pour passer aux CMS (comme Wordpress, Joomla, Spip...qui sont d'ailleurs disponibles au moins dans une version gratuite et libre d'utilisation ) qui vous permet une approche plus viable tandis que ce n'est pas le cas du WYSIWYG. Ce que vous gagnez en facilité de création vous le perdrez simplement en qualité intrinsèque du site et ce n'est pas un point mineur car ces qualités nécessaires sont obligatoires. Paradoxalement il vaut être connaisseur expérimenté pour utiliser un logiciel WYSIWYG pour obtenir un résultat qui soit un tant soit peu correct et un connaisseur aura à sa disposition de meilleurs outils pour créer des sites. Donc le WYSIWYG c'est mort si vous tenez à faire un site de qualité. Surtout que utiliser un CMS peut s'avérer aussi simple et facile mais avec une différente approche, une approche plus proche des réalités techniques et nécessités (normes et aspects à satisfaire) de la création et édition de vos communications à fournir(pour rappel la séparation distincte des contenus, de leur mise en forme et qualification/sémantique) tout en satisfaisant une modularité et des possibilités plus importantes qu'avec le WYSIWYG et une possibilité de mises à jour qui n'existe pas avec une approche qui ne considère que l'aspect visuel qui n'est pas en accord avec la réalité de ce qu'il se passe et les contraintes nécessaire d'un site.
Donc oui cette façon de faire (le WYSIWYG) est périmé car son approche même oblige à tout recommencer si l'on doit modifier quelque chose dans la structure, pour satisfaire les exigences de qualités des nouvelles normes(que n'ont pas les versions précédentes du logiciel) et c'est bien cet aspect qui a précipité le déclin et l'abandon progressif(il y a une quinzaine d'année avec l'apparition de CMS de qualités) de tels logiciels et à la base permet très difficilement des contenus corrects par son approche qui est déconnecté de la réalité et des nécessités techniques et conceptuelles. Quand les CMS permettent (il y a bien sûr des règles et écueils à éviter aussi mais moins nombreux) un contenu et la présentation comme gestion et valorisation des contenus adaptés aux spécificités du web, par la même une pérennité par la possibilité de mise à jour directement de l’ossature et nécessités sémantiques(description; qualification et valorisation des contenus servant à les rendre accessible et repérable par un moteur de recherche) comme technique et de leur évolution éventuelles au cours des années ainsi que des pages aux contenus dynamiques(comme il faut faire les sites de nos jours) quand cet aspect est assez rugueux (pour pas dire autre chose) avec une approche appuyé sur la présentation/visuel uniquement.
CQFD, bon travail
(*)si ce n'est pas le cas et qu'il y a vraiment 150 pages différentes (je ne parle pas du contenu uniquement mais bien de pages qui n'ont rien à voir entre elles) c'est aussi un problème mais de conception: un nombre élevés de pages différentes et présentant des contenus vraiment différent dans leur idées (au delà d'une dizaine de pages) rend simplement ces contenus obscurs et inatteignables pour les utilisateurs. En effet imaginez une utilisateur qui a le choix entre 30 pages qui n'ont rien à voir entre elles. Même avec un menu de présentation clair cela est trop complexe, ne donnera pas envie à l'utilisateur de se creuser la tête pour les trouver et même si c'est lle cas ça rends la navigation complexe et fastidieuse hors n'importe quel document ou communication se doit d'avoir la qualité inverse: clair et facilement accessible à tous les niveaux. Cela s'appelle l'ergonomie web(la prise ne main du site) et ne pas y faire attention fait des sites de qualités médiocres à tout point de vue(tout comme la valorisation sémantique et des contenus présentés, c'est à dire le référencement et la possibilité de diffuser ces contenus). La solution est donc une meilleure organisation des données et une réduction effective du nombre de pages ou si les contenus n'ont vraiment aucun lien entre eux simplement plusieurs sites différents sur un thème/sujet donné.
Bonjour Artos,
Wouaw, un super grand merci d'avoir pris la peine d'expliquer tout en détail.
Mais je vais devoir vous contredire : si si c'est possible :-) possible de rendre responsive un site créé en Dreamweaver il y a 13 ans en combinant l'utilisation du vieux programme et de Bluegriffon.
En fait, je dois être honnête : vous avez raison : ce n'est pas possible de créer un template avec Bluegriffon.
Mais il est possible de créer un fichier responsive en Bluegriffon, de le récupérer dans le vieux programme (téléchargeable) Dreamweaver, et de le transformer en template/modèle, afin de pouvoir dégeler certaines plages où peuvent être encodées les données différentes pour chaque page du site. Et cela exige, à chaque création de nouvelle page, de le faire via Dreamweaver avec l'utilisation du template, de récupérer la page créée via Bluegriffon afin d'y faire les encodages dans la plage dégelée (cela permet de garder la plupart des formats des traitements de texte, ce qui n'est pas possible avec ma vieille version de DW). Une fois la page sauvegardée, elle peut être mise en ligne. Et si plus tard le template est modifié (dans DW); la page sera automatiquement mise à jour par DW et pourra être remise en ligne.
Je peux dès lors utiliser Dreamweaver pour modifier les templates, et transformer automatiquement toutes les pages du site, et créer toutes les nouvelles pages. Et je peux en parallèle utiliser Bluegriffon pour copier du texte formaté dans les pages créées en Dreamweaver, en gardant la plupart des formats de mon traitement de texte (ce que Dreamweaver ne fait pas (la version de 2008 en tout cas)).
C'est un peu tiré par les cheveux, mais je gagnerai beaucoup de temps.
Je sais donc à présent que ce que je demandais dans mon message je peux le réaliser de manière détournée. Cependant, la page d'essai responsive que j'ai créée et transformée en template, ressemble très fort à toutes les pages actuelles, faites justement en Wordpress : tout à la verticale, et je n'aime pas ça du tout (ok pour le smartphone, pas pour le pc).
Je comptais venir répondre à mon propre message pour donner l'information (au cas où d'autres aurait la même obstination que moi), mais comme je ne suis pas satisfaite de la présentation de cet essai et veux d'abord le peaufiner, j'ai remis cela à plus tard, si j'arrive à faire mieux.
Donc je cherche encore à voir si je pourrais récupérer mes "div" (frame/cadre en Dreamweaver, ou box en Blugriffon) pour ramener la structure de mon site actuelle (4 cadres sous forme de grille dont le plus large propose le texte, avec en colonne de gauche le sommaire du texte, ou menu du site (selon la page), avec la barre de navigation et titre du site au-dessus du texte, et une photo au-dessus du sommaire) . Mon objectif serait de parvenir à rendre cette grille de cadres responsive (la fonction tableau n'étant pas utilisable pour le responsive: j'ai fait des essais : improductifs, et je sais qu'en 2008 je m'étais cassé déjà la tête là-dessus, afin d'obtenir les lifts horizontaux et verticaux qui rendaient le site plus flexible selon la taille des écrans de l'époque).
Je pense qu'un informaticien compétent et créatif, et qui a de la bouteille en développement du web et connaît Dreamweaver et Bluegriffon, pourrait m'aider à me dépatouiller à ce niveau sans que cela ne me coûte des milliers d'euros.
Je vous explique tout de même pourquoi je m'obstine à vouloir rester avec du wysiwyg. Non seulement je ne tiens pas à m'investir dans l'apprentissage des html, CSS, et autres langages de développement web, alors que je n'ajoute que maximum 3 à 6 pages web sur mon site, par an ces dernières années (en fait ce sont de très longs articles en général et que je traduis en espagnol et anglais, soit 3 pages html à ajouter à chaque article), mais aussi, en restant en Dreamweaver, si je parviens à rendre un seul modèle/template responsive, je sauve l'entièreté du site, sans avoir rien de plus à réencoder.
Dans mon site actuel de 150 pages, j'ai réalisé 6 templates, basés sur un seul template (ou modèle ) de base. De la sorte, les 150 pages dépendent toutes de ces 6 templates. Il y a deux templates par langue, et soit c'est le menu du site qui se trouve dans la colonne de gauche, soit c'est le sommaire de l'article. Donc quand j'ajoute un article, il est mentionné dans les sommaire de gauche du template, et toutes les pages le mentionnent automatiquement. Et si je décide de changer la barre de navigation, ou la photo, je change le template, et toutes les pages sont mises à jour automatiquement. (Rem : et il est aussi important pour moi que chaque page soit différenciée par son adresse, de manière à pouvoir être bookmarquée, ou citée en hyperlien - et cela implique aussi que si je transforme mon site, toutes les adresses soient conservées pour que les bookmarks et hyperliens enregistrés par d'autres ne deviennent pas obsolètes - et dans ce cas cela concerne également les adresses des pdf et des epub qui sont proposés pour au moins la moitié des articles, soit au moins une centaine d'adresses en plus).
Ainsi, si je transforme complètement les templates (donc un seul, dont seront extraits les 5 autres), la totalité du site sera transformée.
Et je sais bien que les CMS proposent les mêmes avantages en fonctionnant différemment, mais si je dois refaire la base du site en CMS, non seulement, cela exige que j'apprenne à utiliser le CMS (un moindre mal, mais je n'ai pas trop envie), mais aussi, cela exigera probablement de devoir exporter mon site hors de mon disque dur (ça me plait beaucoup moins), et surtout, cela exigera de retravailler dans le détail les 150 pages en question, et je devrai en plus faire un travail supplémentaire pour veiller à ce que toutes les adresses du site ancien mènent encore vers les nouvelles pages créées.
Avant vous, 4 web developpers m'ont proposé de passer au CMS en me proposant leurs services : l'un pour 750€ en Wix, un second pour 2800€ en Wordpress, et les deux autres me l'ont proposé avec tant de mépris face à ma demande, que je ne leur ai pas donné le temps de me faire une offre. En me donnant toutes vos explications vous faites tout le contraire. Non seulement vous me donnez des arguments solides (qui peut-être un jour finiront par me convaincre), mais en plus vous le faites avec respect, et gratuitement. Vous avez donc toute ma reconnaissance.
Les 2 offres que j'ai reçues, proposaient de recréer la base du site pour moi, et de me laisser le travail d'encodage en allant recopier dedans toutes mes pages. Et par la même occasion, le deuxième proposait de me rendre en plus dépendante d'eux pour la sécurité et la maintenance (350€/an) + l'hébergement (350€/an aussi) soit plus du double que ce que Dreamweaver demande annuellement et que je refuse de payer car je juge cela trop cher pour composer seulement quelques pages par an.
Mais je m'obstine à ne pas vouloir de CMS, car, comme mes pages actuelles sont bourrées de liens internes, donc vers d'autres fichiers de mon site, ou encore d'ancres (renvoyant vers le sommaire ou vers des liens internes) : je ne pourrai rien récupérer et devrai recopier le tout (c'est à dire le contenu texte des 150 pages), et recréer non seulement certains formats, mais surtout la totalité de ces liens internes et ancres (par centaines). Ce serait un travail monstre, que seuls les modèles/templates de Dreamweaver pourraient m'épargner.
Etant donné que j'ai au total une centaine d'articles, que certains ont 15 -20 - 40 pages, avec ancres et liens internes réguliers : j'en aurais pour des mois de travail d'encodage fastidieux qui me rendraient tout simplement folle.
Donc, merci beaucoup pour le conseil, mais actuellement, je tiens à rester avec mon bon vieux Dreamweaver, quitte à ce que mon site devienne peu attrayant dans sa présentation, mais reste fonctionnel.
Je me dis que lorsque les wysiwyg seront devenus obsolètes à 100% je me contenterai peut-être de recréer une pâle version de mon site dans un CMS en recopiant simplement les contenus des pdf actuellement proposés, sur les pages, et en perdant les liens internes et ancres, et sommaires pour les plus longs fichiers.
Et par rapport à votre second message:
Pour les stats concernant les CMS et les wysiwyg, j'avais déjà lu un article de cette année, qui montre que les écarts se renforcent encore et rapidement - voir les deux premiers tableaux qui donne les stats plus complètes. En 2021 Worpress s'octroie 64% du marché au total, et Dreamweaver se contente d'un 0,4% (= tout de même 2,7 millions de propriétaires de sites).
https://www.ionos.fr/digitalguide/sites-internet/creation-de-sites-internet/alternatives-a-dreamweaver-les-solutions-open-source/
Et concernant le lien vers un autre forum, j'avoue ne pas me sentir trop concernée. Ce sont des pros (ou quasi) qui parlent entre eux.
A partir du moment où je n'ai aucune formation en html et dans les autres langages, je n'ai pas trop le choix de faire du texte malpropre avec un wysiwyg. Mais je dois avouer que c'est parfois dur de s'y retrouver quand je regarde la page codes. Dans mon cas, l'important c'est d'être capable de copier des blocs de codes d'une page vers une autre pour éviter d'y intégrer des codes spécifiques au programme, quand on utilise deux programmes à la fois, par exemple.
Encore merci d'avoir pris la peine de répondre.
Wouaw, un super grand merci d'avoir pris la peine d'expliquer tout en détail.
Mais je vais devoir vous contredire : si si c'est possible :-) possible de rendre responsive un site créé en Dreamweaver il y a 13 ans en combinant l'utilisation du vieux programme et de Bluegriffon.
En fait, je dois être honnête : vous avez raison : ce n'est pas possible de créer un template avec Bluegriffon.
Mais il est possible de créer un fichier responsive en Bluegriffon, de le récupérer dans le vieux programme (téléchargeable) Dreamweaver, et de le transformer en template/modèle, afin de pouvoir dégeler certaines plages où peuvent être encodées les données différentes pour chaque page du site. Et cela exige, à chaque création de nouvelle page, de le faire via Dreamweaver avec l'utilisation du template, de récupérer la page créée via Bluegriffon afin d'y faire les encodages dans la plage dégelée (cela permet de garder la plupart des formats des traitements de texte, ce qui n'est pas possible avec ma vieille version de DW). Une fois la page sauvegardée, elle peut être mise en ligne. Et si plus tard le template est modifié (dans DW); la page sera automatiquement mise à jour par DW et pourra être remise en ligne.
Je peux dès lors utiliser Dreamweaver pour modifier les templates, et transformer automatiquement toutes les pages du site, et créer toutes les nouvelles pages. Et je peux en parallèle utiliser Bluegriffon pour copier du texte formaté dans les pages créées en Dreamweaver, en gardant la plupart des formats de mon traitement de texte (ce que Dreamweaver ne fait pas (la version de 2008 en tout cas)).
C'est un peu tiré par les cheveux, mais je gagnerai beaucoup de temps.
Je sais donc à présent que ce que je demandais dans mon message je peux le réaliser de manière détournée. Cependant, la page d'essai responsive que j'ai créée et transformée en template, ressemble très fort à toutes les pages actuelles, faites justement en Wordpress : tout à la verticale, et je n'aime pas ça du tout (ok pour le smartphone, pas pour le pc).
Je comptais venir répondre à mon propre message pour donner l'information (au cas où d'autres aurait la même obstination que moi), mais comme je ne suis pas satisfaite de la présentation de cet essai et veux d'abord le peaufiner, j'ai remis cela à plus tard, si j'arrive à faire mieux.
Donc je cherche encore à voir si je pourrais récupérer mes "div" (frame/cadre en Dreamweaver, ou box en Blugriffon) pour ramener la structure de mon site actuelle (4 cadres sous forme de grille dont le plus large propose le texte, avec en colonne de gauche le sommaire du texte, ou menu du site (selon la page), avec la barre de navigation et titre du site au-dessus du texte, et une photo au-dessus du sommaire) . Mon objectif serait de parvenir à rendre cette grille de cadres responsive (la fonction tableau n'étant pas utilisable pour le responsive: j'ai fait des essais : improductifs, et je sais qu'en 2008 je m'étais cassé déjà la tête là-dessus, afin d'obtenir les lifts horizontaux et verticaux qui rendaient le site plus flexible selon la taille des écrans de l'époque).
Je pense qu'un informaticien compétent et créatif, et qui a de la bouteille en développement du web et connaît Dreamweaver et Bluegriffon, pourrait m'aider à me dépatouiller à ce niveau sans que cela ne me coûte des milliers d'euros.
Je vous explique tout de même pourquoi je m'obstine à vouloir rester avec du wysiwyg. Non seulement je ne tiens pas à m'investir dans l'apprentissage des html, CSS, et autres langages de développement web, alors que je n'ajoute que maximum 3 à 6 pages web sur mon site, par an ces dernières années (en fait ce sont de très longs articles en général et que je traduis en espagnol et anglais, soit 3 pages html à ajouter à chaque article), mais aussi, en restant en Dreamweaver, si je parviens à rendre un seul modèle/template responsive, je sauve l'entièreté du site, sans avoir rien de plus à réencoder.
Dans mon site actuel de 150 pages, j'ai réalisé 6 templates, basés sur un seul template (ou modèle ) de base. De la sorte, les 150 pages dépendent toutes de ces 6 templates. Il y a deux templates par langue, et soit c'est le menu du site qui se trouve dans la colonne de gauche, soit c'est le sommaire de l'article. Donc quand j'ajoute un article, il est mentionné dans les sommaire de gauche du template, et toutes les pages le mentionnent automatiquement. Et si je décide de changer la barre de navigation, ou la photo, je change le template, et toutes les pages sont mises à jour automatiquement. (Rem : et il est aussi important pour moi que chaque page soit différenciée par son adresse, de manière à pouvoir être bookmarquée, ou citée en hyperlien - et cela implique aussi que si je transforme mon site, toutes les adresses soient conservées pour que les bookmarks et hyperliens enregistrés par d'autres ne deviennent pas obsolètes - et dans ce cas cela concerne également les adresses des pdf et des epub qui sont proposés pour au moins la moitié des articles, soit au moins une centaine d'adresses en plus).
Ainsi, si je transforme complètement les templates (donc un seul, dont seront extraits les 5 autres), la totalité du site sera transformée.
Et je sais bien que les CMS proposent les mêmes avantages en fonctionnant différemment, mais si je dois refaire la base du site en CMS, non seulement, cela exige que j'apprenne à utiliser le CMS (un moindre mal, mais je n'ai pas trop envie), mais aussi, cela exigera probablement de devoir exporter mon site hors de mon disque dur (ça me plait beaucoup moins), et surtout, cela exigera de retravailler dans le détail les 150 pages en question, et je devrai en plus faire un travail supplémentaire pour veiller à ce que toutes les adresses du site ancien mènent encore vers les nouvelles pages créées.
Avant vous, 4 web developpers m'ont proposé de passer au CMS en me proposant leurs services : l'un pour 750€ en Wix, un second pour 2800€ en Wordpress, et les deux autres me l'ont proposé avec tant de mépris face à ma demande, que je ne leur ai pas donné le temps de me faire une offre. En me donnant toutes vos explications vous faites tout le contraire. Non seulement vous me donnez des arguments solides (qui peut-être un jour finiront par me convaincre), mais en plus vous le faites avec respect, et gratuitement. Vous avez donc toute ma reconnaissance.
Les 2 offres que j'ai reçues, proposaient de recréer la base du site pour moi, et de me laisser le travail d'encodage en allant recopier dedans toutes mes pages. Et par la même occasion, le deuxième proposait de me rendre en plus dépendante d'eux pour la sécurité et la maintenance (350€/an) + l'hébergement (350€/an aussi) soit plus du double que ce que Dreamweaver demande annuellement et que je refuse de payer car je juge cela trop cher pour composer seulement quelques pages par an.
Mais je m'obstine à ne pas vouloir de CMS, car, comme mes pages actuelles sont bourrées de liens internes, donc vers d'autres fichiers de mon site, ou encore d'ancres (renvoyant vers le sommaire ou vers des liens internes) : je ne pourrai rien récupérer et devrai recopier le tout (c'est à dire le contenu texte des 150 pages), et recréer non seulement certains formats, mais surtout la totalité de ces liens internes et ancres (par centaines). Ce serait un travail monstre, que seuls les modèles/templates de Dreamweaver pourraient m'épargner.
Etant donné que j'ai au total une centaine d'articles, que certains ont 15 -20 - 40 pages, avec ancres et liens internes réguliers : j'en aurais pour des mois de travail d'encodage fastidieux qui me rendraient tout simplement folle.
Donc, merci beaucoup pour le conseil, mais actuellement, je tiens à rester avec mon bon vieux Dreamweaver, quitte à ce que mon site devienne peu attrayant dans sa présentation, mais reste fonctionnel.
Je me dis que lorsque les wysiwyg seront devenus obsolètes à 100% je me contenterai peut-être de recréer une pâle version de mon site dans un CMS en recopiant simplement les contenus des pdf actuellement proposés, sur les pages, et en perdant les liens internes et ancres, et sommaires pour les plus longs fichiers.
Et par rapport à votre second message:
Pour les stats concernant les CMS et les wysiwyg, j'avais déjà lu un article de cette année, qui montre que les écarts se renforcent encore et rapidement - voir les deux premiers tableaux qui donne les stats plus complètes. En 2021 Worpress s'octroie 64% du marché au total, et Dreamweaver se contente d'un 0,4% (= tout de même 2,7 millions de propriétaires de sites).
https://www.ionos.fr/digitalguide/sites-internet/creation-de-sites-internet/alternatives-a-dreamweaver-les-solutions-open-source/
Et concernant le lien vers un autre forum, j'avoue ne pas me sentir trop concernée. Ce sont des pros (ou quasi) qui parlent entre eux.
A partir du moment où je n'ai aucune formation en html et dans les autres langages, je n'ai pas trop le choix de faire du texte malpropre avec un wysiwyg. Mais je dois avouer que c'est parfois dur de s'y retrouver quand je regarde la page codes. Dans mon cas, l'important c'est d'être capable de copier des blocs de codes d'une page vers une autre pour éviter d'y intégrer des codes spécifiques au programme, quand on utilise deux programmes à la fois, par exemple.
Encore merci d'avoir pris la peine de répondre.
Bonjour
Ok j'ai l'impression que vous êtes passé à côté des points clés que j'ai voulu aborder. Certainement ma faute le message est long et j'ai voulu détailler un peu mais ça le rends moins accessible. C'est aussi normal quand on connait les publications papiers de considérer uniquement le résultat final/visuel mais ce n'est pas envisageable en informatique comme approche.
"Mais je vais devoir vous contredire : si si c'est possible :-) possible de rendre responsive un site créé en Dreamweaver il y a 13 ans en combinant l'utilisation du vieux programme et de Bluegriffon. "
Oui tout est possible mais est ce souhaitable?
Je n'ai nulle part parler du responsive mais bien sûr cela fait partie de ce que j'explique pour des normes. Le rôle des normes est de permettre que chacun ait le même résultat plus ou moins malgré les différences. Effectivement s'il n'y avais pas des normes afficher un site identique sur un smartphone et sur un grand écran serais plus complexe. Le soucis avec le WYSIWYG c'est qu'il génère(de façon automatique) un contenu qui correspond globalement à ce qui est indiqué visuellement. La quasi impossibilité de manière simple de faire des mises à jours est le problème de tels programmes de création de site par là même: un texte automatisé ne peut pas satisfaire toutes les contraintes et la richesse et complexité de concepts humains.
DW je l'ai pas mal utilisé au début de mon apprentissage et je reconnait son 'utilité' mais ce que vous venez de dire ça revient à employer DW en tant qu'éditeur de texte / EDI . Et ce n'était pas ça mon sujet mais bien que l'approche en visuelle et graphique n'est pas adapté pour faire des sites corrects et que c'est bien là l problème. Si vous avez vu les liens que j'ai joints vous savez que cette question est débattue et que la conclusion est celle que j'indique(ce afin d'illustration et pour pas rentrer dans d'autres détails). En fait si j'ai du utiliser Blue griffon 2h dans ma vie donc je sais qu'il est possible de faire des modèles de pages, du moins avec la version que j'ai utilisé.
Sachez que reprendre un texte dans un langage informatique qui n'est pas fait pour être lisible et modifiable n'a strictement aucun intérêt car est 20 plus long complexe et moins valablale que de recommencer sur des bonnes bases. Le probléme du WYSIWYG qui n'est bon que pour
Ce que je voulais vous apporter principalement comme information: il est plus compliqué/difficile et complexe de faire un site avec de tels outils et le résultat est de moins bonne qualité donc vous AVEZ TOUT INTÉRÊT A ABANDONNER CE GENRE DE LOGICIELS pour passer à des solutions qui soient valables.
Sans connaissance en développement informatique et techs du web ces solutions existent et ont rendues caduques le WYSIWYG car elles apportent les mêmes avantages mais de meilleures qualité. Je ne suis pas du tout pro CMS privilégiant une autre approche mais pour répondre à de nombreuses problématiques et fournir quelques chose de stable les CMS sont là et leur plus grand point fort est bien leur accessibilité.
Certes si l'approche WYSIWYG à de nombreux problèmes et n'a eu qu'une petite notoriété au début de l'ère Internet on ne saurais penser que l'on peut créer quelque chose de très performant/hautement technique et qui nécessite pour un cerveau humain pas mal de connaissances en un claquement des doigts. Avoir des connaissance et une culture des bases d'un sujet ne peut qu'aider et fournir des moyens nécessaires à savoir ce qu'on peut faire et comment on peut le faire mieux(et éviter les trappes qui ne sont pas efficaces/valables).
Les CMS pallient à ce problème en fournissant l'ensemble du logiciel le plus important et avec le principe de modularité tout comme la mise à jour du logiciel et des modules. Il y a bien sûr des règles et façon de faire meilleure que d'autres(pour le résultat) et apprendre comme vous avez appris à utiliser Dream est nécessaire. A vous de voir moi je n'ai aucune prosélytisme pour l'un ou pour l'autre des façons de faire je voulais vous informer des réalités dont il est question, de 'comment ça marche' et surtout pourquoi c'est bien ou mal pour le résultat et la persistance dans le temps de votre solution informatique pour la gestion de vos publications. Multiples et rédibitoires pour le WYSIWYG, avec peu d'inconvénients pour le novice qui n'a pas le temps/intérêt d'apprendre les technologies pour les appliquer lui même. Mais certes si vous faites vous même votre site vous pouvez aspirer à mieux et cela fait de vous quelqu'un qui fait, et savoir par la pratique est aussi une bonne façon de se perfectionner, à vous de voir si l'investissement temps/conséquence(résultat de qualité et viable sur la longueur et résultat médiocre qui sera une plaie dans le temps car nécessitera constamment à être modifié et ne peut pas gérer correctement mes données-un autre probléme de ne opas avoir une approche cohérente sur le sujet: en informatique c'est simplement la perte irrécupérable des données).
" Et je peux en parallèle utiliser Bluegriffon pour copier du texte formaté dans les pages créées en Dreamweaver"
Un autre point important qui me fait penser que vous n'avez pas compris mes explications.
Vous pouvez très bien utiliser Dreawmweaver puisqu'il permet d'écrire du texte. Que ce soit Blue Griffon ou le bloc notes Windows ou text-edit Mac c'est la même chose: il s'agit de textes donc vous pouvez le traiter en texte et n'importe quel éditeur texte fait l'affaire que ce soit pour du HTML/CSS ou de la programmation.
Ce n'est pas le sujet mais bien la façon d'aborder les concepts nécessaires au publication sur Internet.
L'éditeur de Dream(mode mixte ou code) à de très bonnes capacités pour aider au développement comme l'auto-complétion des "mots techniques" des langages web mais ce n'est pas la question et le problème qui sont inhérents à la création de site en WYSIWYG.
Le code produit par de tels logiciels n'est pas correct, difficilement au normes et illisible par un humain donc difficilement récupérable et modifiable.
Hors ces derniers points sont bien ce que vous souhaitez faire qui sont le problème inhérent et qui rendent inefficace de tels logiciels conjointement avec le problème de l'approche de réalités technologiques qui sont trop éloignées de ce qui se passe vraiment et ne tiennent pas compte des normes.
L'avantage du WYSIWYG est sa possibilité de prise en main intuitive et approche il n'y a que le résultat visuel qui compte, c'est la rapidité de mise en œuvre avec peu de connaissances en pensant les pages comme entité d'affichage uniquement.
Implicitement ces facilités comporte le problème. Et du moment où les CMS sont aussi voire plus simples à utiliser(WIX par exemple mas que je ne conseille pas car produit commercial et un paquet de défauts).
Les CMS offrent une base correctement développé et qui utilise une approche axée sur les informations. Sur la base ou le modèle(template) des configurations, ajout de contenu et des possibilités multiples sous forme d'ajout de modules permettent rapidement et sans connaissance du développement d'obtenir des sites dynamiques de qualités.
La possibilité de mises à jours(ce sont des humains derrière sur du travail humain qui font la nouvelle version et non un texte automatisé qui doit être retranscrit en quelque chose de compréhensible qui passe à côté de toute notion conceptuelle )
_approche conceptuelle et matérielle qui ne tient pas comptes des nécessités et de la séparation du fond de la forme
le fond = le contenu/communication à présenter qui lui même comporte des méta-informations(sémantique et "valeurs" des éléments qui permettent de les identifier en tant que tel ,de les hiérarchiser et de les organiser).
Exemples: un texte est les lettres et mots qui le constituent mais aussi impliquent aussi qu'il soit indiqué en tant que texte et la valeur de ce texte consistant à son rôle.
Ainsi un texte est couramment indiqué(par HTML) en tant que "paragraphe de texte", "titre principal ou secondaire de la page" ce qui permet leur référencement et dans les moteurs de recherches.
de même pour une image, l'adresse d'un fichier d'illustration sur la page est clairement(par HTML) indiqué en tant qu'image auquel par soucis d'accessibilité et compatibilité un texte descriptif est obligatoirement requis afin de fournir des indications aux navigateurs qui ne présenterait pas d'image(et conséquemment pouvoir aussi fournir des contenus qui gardent leur sens auprès des personnes mal-voyantes).
la forme = sa présentation et l'apparence qu'il va recouvrir. Une partie aussi qui permet l'interactivité comme afficher/masquer une liste déroulante et faire réagir la page à l'utilisateur pour lui fournir des contenus. C'est en grande partie le CSS que vous évoqué. C'est ce qui concerne toute la mise ne forme, présentation , couleurs, cadres sur la couche d'organisation purement sémantique et hiérarchique du fond(exemple: rubrique C, chapitre 1, acte 3, sa mise en forme pourrait d'avoir un cadre de couleur bleu).
Conceptuellement cette approche correspond à l'utilisation de la réalité de fichiers numériques: Séparer la forme du fond(contenu à afficher/message ou information à diffuser) de son occurrence dans une publication ou présentation ("texte sur deux colonnes sur toute la page") est nécessaire pour l'automatisation et une gestion efficace.
Elle permet sur le web de référencer les contenus et ainsi que lors d'une recherche nous puissions avoir accès (je schématise certes) à des résultats qui aient du sens.
Cela pour pallier qu'une machine n'a pas d''esprit et ne fait pas de déduction.
Mais bref je m'éloigne un peu du sujet.
"Si la question est il possible..."
La réponse est oui. Mais surtout à ne pas faire(j'ai quand même donné un paquet d'arguments sur 2 messages, vérifiez mes dires bien sûr), faire mal et avoir de nouveaux les mêmes problèmes n'est pas ce que je vous recommande. Une approche et des outils meilleurs permettent d'arriver à des résultats valables avec un minimum d'investissement(on parle de semaines et pas de mois de travail comme il faut pour apprendre soi-même les techs. employées) et ce n'est pas l'approche que j'ai car j'utilise mieux mais ai des années d'apprentissage et de pratique pro du sujet, ai aussi fait mes propres erreurs en autodidacte (explorer et toujours une bonne chose et les expériences peu concluantes sont une bonne façon de passer à mieux, en tout cas ça a été le cas pour moi pour Dreamweaver dans sa gestion des bases de données) et ait été confrontés au même question plus ou moins.
Voilà je vous fait part de mes connaissances et expérience mais faites comme vous sentez, j'insiste pour que vous preniez en compte les points négatifs mais c'est à vous de faire vos choix et erreur si vous le souhaitez.
Ok j'ai l'impression que vous êtes passé à côté des points clés que j'ai voulu aborder. Certainement ma faute le message est long et j'ai voulu détailler un peu mais ça le rends moins accessible. C'est aussi normal quand on connait les publications papiers de considérer uniquement le résultat final/visuel mais ce n'est pas envisageable en informatique comme approche.
"Mais je vais devoir vous contredire : si si c'est possible :-) possible de rendre responsive un site créé en Dreamweaver il y a 13 ans en combinant l'utilisation du vieux programme et de Bluegriffon. "
Oui tout est possible mais est ce souhaitable?
Je n'ai nulle part parler du responsive mais bien sûr cela fait partie de ce que j'explique pour des normes. Le rôle des normes est de permettre que chacun ait le même résultat plus ou moins malgré les différences. Effectivement s'il n'y avais pas des normes afficher un site identique sur un smartphone et sur un grand écran serais plus complexe. Le soucis avec le WYSIWYG c'est qu'il génère(de façon automatique) un contenu qui correspond globalement à ce qui est indiqué visuellement. La quasi impossibilité de manière simple de faire des mises à jours est le problème de tels programmes de création de site par là même: un texte automatisé ne peut pas satisfaire toutes les contraintes et la richesse et complexité de concepts humains.
DW je l'ai pas mal utilisé au début de mon apprentissage et je reconnait son 'utilité' mais ce que vous venez de dire ça revient à employer DW en tant qu'éditeur de texte / EDI . Et ce n'était pas ça mon sujet mais bien que l'approche en visuelle et graphique n'est pas adapté pour faire des sites corrects et que c'est bien là l problème. Si vous avez vu les liens que j'ai joints vous savez que cette question est débattue et que la conclusion est celle que j'indique(ce afin d'illustration et pour pas rentrer dans d'autres détails). En fait si j'ai du utiliser Blue griffon 2h dans ma vie donc je sais qu'il est possible de faire des modèles de pages, du moins avec la version que j'ai utilisé.
Sachez que reprendre un texte dans un langage informatique qui n'est pas fait pour être lisible et modifiable n'a strictement aucun intérêt car est 20 plus long complexe et moins valablale que de recommencer sur des bonnes bases. Le probléme du WYSIWYG qui n'est bon que pour
Ce que je voulais vous apporter principalement comme information: il est plus compliqué/difficile et complexe de faire un site avec de tels outils et le résultat est de moins bonne qualité donc vous AVEZ TOUT INTÉRÊT A ABANDONNER CE GENRE DE LOGICIELS pour passer à des solutions qui soient valables.
Sans connaissance en développement informatique et techs du web ces solutions existent et ont rendues caduques le WYSIWYG car elles apportent les mêmes avantages mais de meilleures qualité. Je ne suis pas du tout pro CMS privilégiant une autre approche mais pour répondre à de nombreuses problématiques et fournir quelques chose de stable les CMS sont là et leur plus grand point fort est bien leur accessibilité.
Certes si l'approche WYSIWYG à de nombreux problèmes et n'a eu qu'une petite notoriété au début de l'ère Internet on ne saurais penser que l'on peut créer quelque chose de très performant/hautement technique et qui nécessite pour un cerveau humain pas mal de connaissances en un claquement des doigts. Avoir des connaissance et une culture des bases d'un sujet ne peut qu'aider et fournir des moyens nécessaires à savoir ce qu'on peut faire et comment on peut le faire mieux(et éviter les trappes qui ne sont pas efficaces/valables).
Les CMS pallient à ce problème en fournissant l'ensemble du logiciel le plus important et avec le principe de modularité tout comme la mise à jour du logiciel et des modules. Il y a bien sûr des règles et façon de faire meilleure que d'autres(pour le résultat) et apprendre comme vous avez appris à utiliser Dream est nécessaire. A vous de voir moi je n'ai aucune prosélytisme pour l'un ou pour l'autre des façons de faire je voulais vous informer des réalités dont il est question, de 'comment ça marche' et surtout pourquoi c'est bien ou mal pour le résultat et la persistance dans le temps de votre solution informatique pour la gestion de vos publications. Multiples et rédibitoires pour le WYSIWYG, avec peu d'inconvénients pour le novice qui n'a pas le temps/intérêt d'apprendre les technologies pour les appliquer lui même. Mais certes si vous faites vous même votre site vous pouvez aspirer à mieux et cela fait de vous quelqu'un qui fait, et savoir par la pratique est aussi une bonne façon de se perfectionner, à vous de voir si l'investissement temps/conséquence(résultat de qualité et viable sur la longueur et résultat médiocre qui sera une plaie dans le temps car nécessitera constamment à être modifié et ne peut pas gérer correctement mes données-un autre probléme de ne opas avoir une approche cohérente sur le sujet: en informatique c'est simplement la perte irrécupérable des données).
" Et je peux en parallèle utiliser Bluegriffon pour copier du texte formaté dans les pages créées en Dreamweaver"
Un autre point important qui me fait penser que vous n'avez pas compris mes explications.
Vous pouvez très bien utiliser Dreawmweaver puisqu'il permet d'écrire du texte. Que ce soit Blue Griffon ou le bloc notes Windows ou text-edit Mac c'est la même chose: il s'agit de textes donc vous pouvez le traiter en texte et n'importe quel éditeur texte fait l'affaire que ce soit pour du HTML/CSS ou de la programmation.
Ce n'est pas le sujet mais bien la façon d'aborder les concepts nécessaires au publication sur Internet.
L'éditeur de Dream(mode mixte ou code) à de très bonnes capacités pour aider au développement comme l'auto-complétion des "mots techniques" des langages web mais ce n'est pas la question et le problème qui sont inhérents à la création de site en WYSIWYG.
Le code produit par de tels logiciels n'est pas correct, difficilement au normes et illisible par un humain donc difficilement récupérable et modifiable.
Hors ces derniers points sont bien ce que vous souhaitez faire qui sont le problème inhérent et qui rendent inefficace de tels logiciels conjointement avec le problème de l'approche de réalités technologiques qui sont trop éloignées de ce qui se passe vraiment et ne tiennent pas compte des normes.
L'avantage du WYSIWYG est sa possibilité de prise en main intuitive et approche il n'y a que le résultat visuel qui compte, c'est la rapidité de mise en œuvre avec peu de connaissances en pensant les pages comme entité d'affichage uniquement.
Implicitement ces facilités comporte le problème. Et du moment où les CMS sont aussi voire plus simples à utiliser(WIX par exemple mas que je ne conseille pas car produit commercial et un paquet de défauts).
Les CMS offrent une base correctement développé et qui utilise une approche axée sur les informations. Sur la base ou le modèle(template) des configurations, ajout de contenu et des possibilités multiples sous forme d'ajout de modules permettent rapidement et sans connaissance du développement d'obtenir des sites dynamiques de qualités.
La possibilité de mises à jours(ce sont des humains derrière sur du travail humain qui font la nouvelle version et non un texte automatisé qui doit être retranscrit en quelque chose de compréhensible qui passe à côté de toute notion conceptuelle )
- Points faibles
_approche conceptuelle et matérielle qui ne tient pas comptes des nécessités et de la séparation du fond de la forme
le fond = le contenu/communication à présenter qui lui même comporte des méta-informations(sémantique et "valeurs" des éléments qui permettent de les identifier en tant que tel ,de les hiérarchiser et de les organiser).
Exemples: un texte est les lettres et mots qui le constituent mais aussi impliquent aussi qu'il soit indiqué en tant que texte et la valeur de ce texte consistant à son rôle.
Ainsi un texte est couramment indiqué(par HTML) en tant que "paragraphe de texte", "titre principal ou secondaire de la page" ce qui permet leur référencement et dans les moteurs de recherches.
de même pour une image, l'adresse d'un fichier d'illustration sur la page est clairement(par HTML) indiqué en tant qu'image auquel par soucis d'accessibilité et compatibilité un texte descriptif est obligatoirement requis afin de fournir des indications aux navigateurs qui ne présenterait pas d'image(et conséquemment pouvoir aussi fournir des contenus qui gardent leur sens auprès des personnes mal-voyantes).
la forme = sa présentation et l'apparence qu'il va recouvrir. Une partie aussi qui permet l'interactivité comme afficher/masquer une liste déroulante et faire réagir la page à l'utilisateur pour lui fournir des contenus. C'est en grande partie le CSS que vous évoqué. C'est ce qui concerne toute la mise ne forme, présentation , couleurs, cadres sur la couche d'organisation purement sémantique et hiérarchique du fond(exemple: rubrique C, chapitre 1, acte 3, sa mise en forme pourrait d'avoir un cadre de couleur bleu).
Conceptuellement cette approche correspond à l'utilisation de la réalité de fichiers numériques: Séparer la forme du fond(contenu à afficher/message ou information à diffuser) de son occurrence dans une publication ou présentation ("texte sur deux colonnes sur toute la page") est nécessaire pour l'automatisation et une gestion efficace.
Elle permet sur le web de référencer les contenus et ainsi que lors d'une recherche nous puissions avoir accès (je schématise certes) à des résultats qui aient du sens.
Cela pour pallier qu'une machine n'a pas d''esprit et ne fait pas de déduction.
Mais bref je m'éloigne un peu du sujet.
"Si la question est il possible..."
La réponse est oui. Mais surtout à ne pas faire(j'ai quand même donné un paquet d'arguments sur 2 messages, vérifiez mes dires bien sûr), faire mal et avoir de nouveaux les mêmes problèmes n'est pas ce que je vous recommande. Une approche et des outils meilleurs permettent d'arriver à des résultats valables avec un minimum d'investissement(on parle de semaines et pas de mois de travail comme il faut pour apprendre soi-même les techs. employées) et ce n'est pas l'approche que j'ai car j'utilise mieux mais ai des années d'apprentissage et de pratique pro du sujet, ai aussi fait mes propres erreurs en autodidacte (explorer et toujours une bonne chose et les expériences peu concluantes sont une bonne façon de passer à mieux, en tout cas ça a été le cas pour moi pour Dreamweaver dans sa gestion des bases de données) et ait été confrontés au même question plus ou moins.
Voilà je vous fait part de mes connaissances et expérience mais faites comme vous sentez, j'insiste pour que vous preniez en compte les points négatifs mais c'est à vous de faire vos choix et erreur si vous le souhaitez.
Bonjour,
Je vais répondre de manière définitive à ma propre question : NON pour la première partie, et OUI pour la deuxième partie.
Utiliser Bluegriffon ne permet pas de travailler sur les templates d'un vieux programme Dreamweaver (MX). Par contre il permet de modifier les pages html produites par ces templates. Il est plus facile de recopier du texte créé en LibreOffice par exemple, pour les intégrer sur des pages html avec le Wysiwyg de Bluegriffon qui garde tous les formats de LibreOffice. Car l'ancien programme Dreamweaver exige de réencoder les formats.
Mais il est tout à fait possible de récupérer les anciens templates Dreamweaver et de les rendre responsive avec des connaissances légèrement plus poussées en CSS : connaître les grid et les meta queries principalement.
Le plus simple aurait pu être de m'abonner à Dreamweaver. Mais, pour rappel, la version actuelle de Dreamweaver, coûte 300€ par an.
J'ai aussi cherché auprès de web developpers. Certains m'ont proposé de recréer mon site en Wix ou Wordpress. Le premier (une petite association sans but lucratif) me demandait 750€ le second entre 2145 et 2800€ (selon les options) tout en me rendant dépendante de l'hébergement à 350€ l'an, et la maintenance à 350€ l'an. Un troisième envisageait de me faire une offre sous les 1000€. Et dans les trois cas, ils me laissaient la totalité du travail de réencodage (reformattage en fait) des 150 pages dans le nouveau site (soit des semaines de travail, vu le nombre de liens internes et ancrages à recréer, et le temps de vérification que cela exige vu que c'est une travail abrutissant et ennuyeux où les erreurs de distraction sont courantes).
Or, j'ai pu rendre mon site responsive assez rapidement, en modifiant les templates via le CSS et ensuite, en récupérant la totalité des environs 150 pages en à peine quelques clics de la sorte. Je me suis fait aider par un coach qui connaît Dreamweaver. Le travail de modification des templates et de création de fichiers CSS m'a pris quelques heures. J'en ai perdu beaucoup d'autres car j'ai bidouillé par manque de connaissances, mais dès que je revoyais le coach, tout roulait. (Ignorer un simple détail peut fausser toutes les données dans les codes, et on peut chercher des heures à réajuster, mais le coach le repérait rapidement.)
Cela m'a coûté 4 heures de cours à 35€ de l'heure, soit 140€.
Et je garde ainsi la totale gestion de mon site, en comprenant le contenu html et CSS des templates.
En plus, je me suis bien amusée à le faire.
Bref, j'estime que j'ai bien fait de m'entêter vis-à-vis de toutes les personnes qui m'ont soit prise de haut ou qui ont voulu faire du profit sur mon dos, plutôt par ignorance (si on ne connaît pas vraiment les templates de Dreamweaver, on ne pouvait pas comprendre ma question).
Je suis reconnaissante vis-à-vis du coach qui a parfaitement fait son boulot, et vis-à-vis de l'association qui, suite à nos échanges, m'a conseillé de trouver par moi-même.
Je viens mettre cette réponse, au cas où d'autres seraient confrontés au même problème : entêtez-vous pour trouver le moyen d'y arriver. Je précise aussi que les pages de mon site, nombreuses, diffèrent par le contenu en texte, mais très peu par la présentation. C'est un site statique. C'est cela même qui rend l'utilisation des templates efficace.
Je vais répondre de manière définitive à ma propre question : NON pour la première partie, et OUI pour la deuxième partie.
Utiliser Bluegriffon ne permet pas de travailler sur les templates d'un vieux programme Dreamweaver (MX). Par contre il permet de modifier les pages html produites par ces templates. Il est plus facile de recopier du texte créé en LibreOffice par exemple, pour les intégrer sur des pages html avec le Wysiwyg de Bluegriffon qui garde tous les formats de LibreOffice. Car l'ancien programme Dreamweaver exige de réencoder les formats.
Mais il est tout à fait possible de récupérer les anciens templates Dreamweaver et de les rendre responsive avec des connaissances légèrement plus poussées en CSS : connaître les grid et les meta queries principalement.
Le plus simple aurait pu être de m'abonner à Dreamweaver. Mais, pour rappel, la version actuelle de Dreamweaver, coûte 300€ par an.
J'ai aussi cherché auprès de web developpers. Certains m'ont proposé de recréer mon site en Wix ou Wordpress. Le premier (une petite association sans but lucratif) me demandait 750€ le second entre 2145 et 2800€ (selon les options) tout en me rendant dépendante de l'hébergement à 350€ l'an, et la maintenance à 350€ l'an. Un troisième envisageait de me faire une offre sous les 1000€. Et dans les trois cas, ils me laissaient la totalité du travail de réencodage (reformattage en fait) des 150 pages dans le nouveau site (soit des semaines de travail, vu le nombre de liens internes et ancrages à recréer, et le temps de vérification que cela exige vu que c'est une travail abrutissant et ennuyeux où les erreurs de distraction sont courantes).
Or, j'ai pu rendre mon site responsive assez rapidement, en modifiant les templates via le CSS et ensuite, en récupérant la totalité des environs 150 pages en à peine quelques clics de la sorte. Je me suis fait aider par un coach qui connaît Dreamweaver. Le travail de modification des templates et de création de fichiers CSS m'a pris quelques heures. J'en ai perdu beaucoup d'autres car j'ai bidouillé par manque de connaissances, mais dès que je revoyais le coach, tout roulait. (Ignorer un simple détail peut fausser toutes les données dans les codes, et on peut chercher des heures à réajuster, mais le coach le repérait rapidement.)
Cela m'a coûté 4 heures de cours à 35€ de l'heure, soit 140€.
Et je garde ainsi la totale gestion de mon site, en comprenant le contenu html et CSS des templates.
En plus, je me suis bien amusée à le faire.
Bref, j'estime que j'ai bien fait de m'entêter vis-à-vis de toutes les personnes qui m'ont soit prise de haut ou qui ont voulu faire du profit sur mon dos, plutôt par ignorance (si on ne connaît pas vraiment les templates de Dreamweaver, on ne pouvait pas comprendre ma question).
Je suis reconnaissante vis-à-vis du coach qui a parfaitement fait son boulot, et vis-à-vis de l'association qui, suite à nos échanges, m'a conseillé de trouver par moi-même.
Je viens mettre cette réponse, au cas où d'autres seraient confrontés au même problème : entêtez-vous pour trouver le moyen d'y arriver. Je précise aussi que les pages de mon site, nombreuses, diffèrent par le contenu en texte, mais très peu par la présentation. C'est un site statique. C'est cela même qui rend l'utilisation des templates efficace.
"C'est un site statique. C'est cela même qui rend l'utilisation des templates efficace. "
Ah bon...si vous savez utiliser CSS avec un fichier externe vous devez savoir que le principe même de template n'a aucune utilité pour un site statique puisque vous pouvez(devez) utiliser CSS dans ce but: fournir un modèle de mise en page réutilisable(template) en tout cas en ce qui concerne la mise en page.
CSS permettant d'être repris sur plusieurs pages si vous voulez la même présentation il vous suffit de copier le HTML dans un autre fichier (avec la partie qui fiat appel au CSS).
Ce qui en revient au but de nos échanges, le mien était de vous apporter des bases de connaissances correctes qui vous permettent avec un travail personnel de faire grandir celles ci.
Et que le problème des sites statiques et (par définition) qu'ils ne peuvent être modifiés sans avoir à modifier le code. Cela devient impossible si le site est utilisé parce que ce travail à fournir devient exponentiel et humainement infaisable et rends les sites statiques obsolètes, les faisant presque entièrement disparaître depuis les CMS qui sont l'approche que je vous ai recommandé puisque qu'elle s'adresse à des non professionnels et permet des sites dont les contenus peuvent changer de manière automatisé à partir d'un modèle(template en anglais) donc sans avoir à refaire/réécrire la page ce qui devient ingérable quand les modifications deviennent fréquentes.
" Certains m'ont proposé de recréer mon site en Wix ou Wordpress."
Ce sont 2 CMS facilement accessible sans avoir de formation en développement informatique donc apprendre à les utiliser était la meileure solution bien que vous ne les ayez pas envisagé(je parle de manière générale, Wix étant une arnaque commerciale, un professionnel qui vous vends un site Wix est donc un escroc ou un incompétent)
Si "vous prendre de haut" c'est essayer de corriger vos conceptions erronées en création de pages web alors je plaide coupable et justement apprendre c'est aussi accepter que l'on ne sait pas tout.
"Et je garde ainsi la totale gestion de mon site, en comprenant le contenu html et CSS des templates. "
Euh oui mais cela a rapport à HTML et CSS et non à Dreamweaver qui n'est pas une bonne approche de création de sites de nos jours pour tout un tas de raison évoqué dans ma 1ère réponse. Ne me croyez pas sur parole et vérifiez chaque point c'est une bonne façon d'apprendre aussi :)
Si vous connaissez HTML et CSS vous êtes donc capable de faire un site web statique avec un éditeur de texte et utilisez DW pour cela est un point de détails(un éditeur de texte édite du texte).
Je n'ai jamais nié (au contraire) les qualités de DW pour l'édition(l'autocomplétion étant particulièrement efficace en effet) mais bien la façon d'aborder la création de pages en WYSIWYG donc par l'aspect visuel et non l'écriture des langages HTML, CSS ou autres qui sont possibles par n'importe quel EDI ou éditeur de textes comme bloc notes de windows.
Vous n'êtes pas obligé de le croire mais je suis un professionnel de la création web et de la formation dans ce domaine et suis régulièrement confronté à ces problèmes qui vous expliqueront mon envie de vous aider, de vous éviter de tomber dans des erreurs de principes et des mélanges de notions fausses qui ont un impact sur la qualité du résultat d'une page web et font perdre du temps à son auteur et/ou administrateur.
Encore une fois faites comme vous le voulez mais si vous comprenez mes explications vous éviterez certaines erreurs qui auront un impact dont l'un d'eux est une perte de temps et un apprentissage d'une mauvaise méthodologie(le WYSIWYG).
Et la méthodologie est le plus important pour ce domaine technique, plus que savoir écrire du code puisque le code est l'aboutissement de cette méthodologie.
Content que vous ayez fait une formation et se confronter aux problèmes et être capable de les résoudre par vous même devrait être le but d'une formation.
Les formations il y en a beaucoup, à commencer pour HTML et CSS par un cours/tuto gratuit comme ceux bien connus (et mis e avant par F. Hollande lors de sa présidence) fournis par Open CLass Room. Si vous avez fait des recherches sur la création web vous pouvez voir qu'il y a peu de cours sur l'approche du WYSIWYG qui est par définition intuitive, hélas tout ce qui est intuitif n'est pas toujours correct ni vrai et ne permet pas d'obtenir un résultat de qualité. C'est cela que j'ai voulu mettre en avant aussi dans mes explications, c'est la différence entre la connaissance et l'illusion de connaissance.
CQFD
Ah bon...si vous savez utiliser CSS avec un fichier externe vous devez savoir que le principe même de template n'a aucune utilité pour un site statique puisque vous pouvez(devez) utiliser CSS dans ce but: fournir un modèle de mise en page réutilisable(template) en tout cas en ce qui concerne la mise en page.
CSS permettant d'être repris sur plusieurs pages si vous voulez la même présentation il vous suffit de copier le HTML dans un autre fichier (avec la partie qui fiat appel au CSS).
Ce qui en revient au but de nos échanges, le mien était de vous apporter des bases de connaissances correctes qui vous permettent avec un travail personnel de faire grandir celles ci.
Et que le problème des sites statiques et (par définition) qu'ils ne peuvent être modifiés sans avoir à modifier le code. Cela devient impossible si le site est utilisé parce que ce travail à fournir devient exponentiel et humainement infaisable et rends les sites statiques obsolètes, les faisant presque entièrement disparaître depuis les CMS qui sont l'approche que je vous ai recommandé puisque qu'elle s'adresse à des non professionnels et permet des sites dont les contenus peuvent changer de manière automatisé à partir d'un modèle(template en anglais) donc sans avoir à refaire/réécrire la page ce qui devient ingérable quand les modifications deviennent fréquentes.
" Certains m'ont proposé de recréer mon site en Wix ou Wordpress."
Ce sont 2 CMS facilement accessible sans avoir de formation en développement informatique donc apprendre à les utiliser était la meileure solution bien que vous ne les ayez pas envisagé(je parle de manière générale, Wix étant une arnaque commerciale, un professionnel qui vous vends un site Wix est donc un escroc ou un incompétent)
Si "vous prendre de haut" c'est essayer de corriger vos conceptions erronées en création de pages web alors je plaide coupable et justement apprendre c'est aussi accepter que l'on ne sait pas tout.
"Et je garde ainsi la totale gestion de mon site, en comprenant le contenu html et CSS des templates. "
Euh oui mais cela a rapport à HTML et CSS et non à Dreamweaver qui n'est pas une bonne approche de création de sites de nos jours pour tout un tas de raison évoqué dans ma 1ère réponse. Ne me croyez pas sur parole et vérifiez chaque point c'est une bonne façon d'apprendre aussi :)
Si vous connaissez HTML et CSS vous êtes donc capable de faire un site web statique avec un éditeur de texte et utilisez DW pour cela est un point de détails(un éditeur de texte édite du texte).
Je n'ai jamais nié (au contraire) les qualités de DW pour l'édition(l'autocomplétion étant particulièrement efficace en effet) mais bien la façon d'aborder la création de pages en WYSIWYG donc par l'aspect visuel et non l'écriture des langages HTML, CSS ou autres qui sont possibles par n'importe quel EDI ou éditeur de textes comme bloc notes de windows.
Vous n'êtes pas obligé de le croire mais je suis un professionnel de la création web et de la formation dans ce domaine et suis régulièrement confronté à ces problèmes qui vous expliqueront mon envie de vous aider, de vous éviter de tomber dans des erreurs de principes et des mélanges de notions fausses qui ont un impact sur la qualité du résultat d'une page web et font perdre du temps à son auteur et/ou administrateur.
Encore une fois faites comme vous le voulez mais si vous comprenez mes explications vous éviterez certaines erreurs qui auront un impact dont l'un d'eux est une perte de temps et un apprentissage d'une mauvaise méthodologie(le WYSIWYG).
Et la méthodologie est le plus important pour ce domaine technique, plus que savoir écrire du code puisque le code est l'aboutissement de cette méthodologie.
Content que vous ayez fait une formation et se confronter aux problèmes et être capable de les résoudre par vous même devrait être le but d'une formation.
Les formations il y en a beaucoup, à commencer pour HTML et CSS par un cours/tuto gratuit comme ceux bien connus (et mis e avant par F. Hollande lors de sa présidence) fournis par Open CLass Room. Si vous avez fait des recherches sur la création web vous pouvez voir qu'il y a peu de cours sur l'approche du WYSIWYG qui est par définition intuitive, hélas tout ce qui est intuitif n'est pas toujours correct ni vrai et ne permet pas d'obtenir un résultat de qualité. C'est cela que j'ai voulu mettre en avant aussi dans mes explications, c'est la différence entre la connaissance et l'illusion de connaissance.
CQFD
Bonjour Artos,
Merci encore une fois de vous être donné la peine de répondre. Je me rends compte à présent que nous sommes vraiment dans un malentendu et qu'il persiste, concernant le concept de "template". Le template dont il est question ici est celui que propose Dreamweaver, et ce n'est pas du tout le même concept qu'un template tel qu'on le conçoit classiquement. Le principe de base est le même mais cela va plus loin dans son exploitation via Dreamweaver.
Donc je vais réexpliquer pour tenter de dissoudre ce malentendu. J'avais cru en fait que vous connaissiez les templates de Dreamweaver, mais il apparaît dans votre dernier message, que vous en ignorez le fonctionnement.
Et c'est important à mes yeux d'expliciter un peu plus, car le cas de figure de mon site n'est très certainement pas isolé, et si ce que je viens de réussir pour mon site peut servir à d'autres, autant le réexpliquer trois fois.
Mon but est que tout lecteur concerné par la même démarche que moi puisse avoir une réponse plus rapidement à la question que je me posais. C'est le but même du site Comment Ca Marche, que j'applaudis des deux mains. J'y trouve régulièrement des réponses à mes questions, que je ne trouve nulle part ailleurs.
Je vais donc commencer par rectifier ce qui suit :
Quand vous dites:
"Ah bon...si vous savez utiliser CSS avec un fichier externe vous devez savoir que le principe même de template n'a aucune utilité pour un site statique puisque vous pouvez(devez) utiliser CSS dans ce but: fournir un modèle de mise en page réutilisable(template) en tout cas en ce qui concerne la mise en page. "
Ecrire cela m'a fait comprendre que vous ne connaissez pas les templates de Dreamweaver. J'ignorais en posant la question de départ (et c'était d'ailleurs l'objet de ma question) que Dreamweaver est le seul programme Wysiwyg permettant grâce à son template particulier, de figer la totalité de la page-template (du code html), et de défiger uniquement les parties qui seront modifiées dans chaque page différente du site. Le CSS, lui, fige les formats, pas le contenu. Les templates de Dreamweaver n'ont en commun avec le mot template utilisé dans d'autres Wysiwyg, que le nom, ou quasi. Et ma naïveté me faisait espérer qu'un autre Wysiwyg proposait cette fonctionnalité.
En sauvant un template Dreamweaver qui a été modifié de fond en comble au niveau de son contenu (tant que de sa forme via le CSS), mais qui garde intacte la plage défigée, et qui est lié à 150 pages de site : en un seul clic, on modifie de fond en comble les 150 pages du site, en maintenant intact tout le contenu qui leur était propre. A chaque fois qu'on sauvegarde un template, tous les fichiers qui ont été créés à partir de lui sont également modifiés et sauvegardés.
J'avais d'ailleurs tenté de créé un tout nouveau template, et l'avais sauvegardé sous le nom de l'ancien template - donc en écrasant le template d'origine. Ca coupe une partie des liens entre les fichiers qui en dépendent. Tout fichier nouvellement ouvert sera sauvé selon le template nouveau. Mais en sauvegardant des modifications du nouveau template (qui a donc repris le nom de l'ancien), la sauvegarde automatique des autres fichiers qui en dépendent est perdue.
Dès lors, si, sur toutes mes pages, j'ai par exemple:
- une photo, toujours la même, en haut à gauche,
- un titre de site, toujours le même, en haut à droite,
- une barre de navigation, toujours la même, sous le titre,
- et une colonne d'info, toujours la même, sous la photo, contenant par exemple une liste de liens (internes et externes);
- et que seul un tiers (relatif) de la page (sous le titre et la barre de navigation) contient du texte qui est différent d'une page à l'autre :
le template permettra de garder les mêmes données pour toutes les pages, excepté la partie texte défigée, personnalisable pour chaque page distincte. Et si je décide de modifier ces données figées, peu importe lesquelles (la photo, ou la barre de navig, ou le titre du site, ou tout à la fois, ou en le rendant responsive) : au moment de l'enregistrement du template : les 150 pages du site sont elles aussi réenregistrées avec les nouveaux contenus.
Il y a même mieux : je peux créer un template2 à partir du template1, et qui reste dépendant du template1. Si dans le second template, je défige la colonne d'info (à gauche, sous la photo) qui donne des listes de liens, en plus de la partie texte déjà défigée - il y a donc deux régions modifiables, plus aussi celle des propriétés de la page dans la partie "head" - et que je la remplace par un sommaire du texte de la page (avec plein de liens internes vers les ancres disséminées dans le texte de droite), de manière à publier par exemple, via ce template2, un bouquin entier en X pages. En faisant les modifs dans le template1, elles seront enregistrées également dans le template2, et donc toutes les pages du bouquin seront modifiées automatiquement lors de l'enregistrement du template1.
J'ai tout à fait conscience que le CMS permet de faire la même chose de manière différente et plus facile. Mais dans mon cas précis, déménager tout mon site (créé en Dreamweaver il y a belle lurette) vers un CMS, impliquait du recopiage de texte pour 150 pages, et du réencodage en masse de liens internes : avec toutes les distractions que cela implique, et donc toutes les vérifications que cela impose; et le côté abrutissant sur une durée énorme pour le faire.
Je me suis épargnée tout cela, et je me suis amusée à recréer mon template, avec les infos et la guidance du coach (4 heures ont suffi). De plus, psychologiquement parlant, je n'ai pas jeté à la poubelle tout le travail que j'ai fait pendant toutes ces années pour construire mon site. J'ai tout gardé. Ca ne m'a pas pris trop de temps, presque pas d'argent, et j'ai conservé mon site d'origine sur mon disque dur.
En réalité j'ai dû pratiquement reconstruire la page template de base, car pour rendre le site responsive, il ne suffisait pas de faire passer les formats du html dans un fichier CSS externe, il fallait que le contenu html change de forme. La barre de navigation qui était un tableau est devenu un ensemble de div structurés en grid. L'ordre des div présenté dans l'ancien template, a été complètement chamboulé, et encore d'autres changements ont dû être apportés. Donc c'est bien le contenu html qui devait à tout prix être modifié pour rendre possible que le site devienne responsive. Un fichier CSS externe n'aurait, et de loin, pas suffi. Et pourtant la page obtenue ressemble tout à fait à la page d'origine.
Or, si j'avais suivi tous les conseil reçus, le déménagement vers le CMS aurait impliqué un nouvel apprentissage (ce que j'ai dû faire partiellement aussi pour le CSS en apprenant à utiliser l'éditeur, les meta queries et les grids) et donc, à cela je ne me serais pas opposée. Mais cela aurait impliqué surtout ce ré-encodage en masse. Non seulement, j'aurais dû recopier le contenu des 150 pages (la partie texte des régions modifiables); ce qui est long, mais aurait été acceptable si les formats étaient respectés. Mais tous les liens internes : renvoi vers d'autres pages de mon site, ou renvoi vers d'autres paragraphes sur la même page, auraient dû être réencodés un par un. Même si le CMS permet de le faire de manière plus simple et ludique qu'un copy colle d'une <aref....> (en tout cas Dreamweaver le permet de manière plus ludique); cela aurait impliqué des centaines ou milliers de manoeuvres à effectuer + les vérifs, et corrections. Bref, un travail de malade, que je me suis épargnée.
Quand j'ai sauvegardé mon template modifié et que toutes mes pages l'ont été en un clic, j'ai eu le miracle sous mes yeux.
J'espère à présent que cela va pouvoir tenir entre 3 et 5 ans, voire plus. Ensuite, j'envisagerai peut-être autre chose. L'évolution allant tellement vite, il sera peut-être nécessaire de créer tout à fait autre chose dans un autre environnement, car les CMS seront alors peut-être eux aussi devenus obsolètes. Ou à l'inverse, les CMS deviendront capables d'intégrer un site html existant pour le rendre gérable via le CMS; ce qui me permettra de garder mon site et le faire évoluer en CMS.
En tout cas, pour des non professionnels qui ont un vieux Dreamweaver sur leur pc, qui ont un site statique avec de nombreuses pages créées à partir d'un (ou plusieurs) template(s), et qui n'ont pas envie de débourser des mille et des cents, qui n'ont pas des dizaines ou centaines d'heures disponibles, pour rendre leur site responsive, ou pour modifier de manière importante la présentation de leur site : je conseille vivement de garder leur programme, de trouver une aide extérieure pour apprendre un peu plus de code (html et css) et d'exploiter la veine "template de Dreamweaver" à volonté. Elle en vaut la peine. Et surtout ne vous laissez pas influencer par ceux qui veulent se faire de l'argent sur votre dos, ou par ceux qui vous disent que rester sur Dreamweaver n'en vaut pas la peine. C'est parce qu'ils ignorent l'avantage réel des templates proposés par Dreamweaver et les confondent avec ce qu'on appelle couramment des templates dans d'autres programmes.
Et je me permets d'insister : pour le référencement. Car je ne doute pas une seconde, que quelqu'un qui posera une question du genre dans un moteur de recherche pourra tomber sur ce message.
Merci encore une fois de vous être donné la peine de répondre. Je me rends compte à présent que nous sommes vraiment dans un malentendu et qu'il persiste, concernant le concept de "template". Le template dont il est question ici est celui que propose Dreamweaver, et ce n'est pas du tout le même concept qu'un template tel qu'on le conçoit classiquement. Le principe de base est le même mais cela va plus loin dans son exploitation via Dreamweaver.
Donc je vais réexpliquer pour tenter de dissoudre ce malentendu. J'avais cru en fait que vous connaissiez les templates de Dreamweaver, mais il apparaît dans votre dernier message, que vous en ignorez le fonctionnement.
Et c'est important à mes yeux d'expliciter un peu plus, car le cas de figure de mon site n'est très certainement pas isolé, et si ce que je viens de réussir pour mon site peut servir à d'autres, autant le réexpliquer trois fois.
Mon but est que tout lecteur concerné par la même démarche que moi puisse avoir une réponse plus rapidement à la question que je me posais. C'est le but même du site Comment Ca Marche, que j'applaudis des deux mains. J'y trouve régulièrement des réponses à mes questions, que je ne trouve nulle part ailleurs.
Je vais donc commencer par rectifier ce qui suit :
Quand vous dites:
"Ah bon...si vous savez utiliser CSS avec un fichier externe vous devez savoir que le principe même de template n'a aucune utilité pour un site statique puisque vous pouvez(devez) utiliser CSS dans ce but: fournir un modèle de mise en page réutilisable(template) en tout cas en ce qui concerne la mise en page. "
Ecrire cela m'a fait comprendre que vous ne connaissez pas les templates de Dreamweaver. J'ignorais en posant la question de départ (et c'était d'ailleurs l'objet de ma question) que Dreamweaver est le seul programme Wysiwyg permettant grâce à son template particulier, de figer la totalité de la page-template (du code html), et de défiger uniquement les parties qui seront modifiées dans chaque page différente du site. Le CSS, lui, fige les formats, pas le contenu. Les templates de Dreamweaver n'ont en commun avec le mot template utilisé dans d'autres Wysiwyg, que le nom, ou quasi. Et ma naïveté me faisait espérer qu'un autre Wysiwyg proposait cette fonctionnalité.
En sauvant un template Dreamweaver qui a été modifié de fond en comble au niveau de son contenu (tant que de sa forme via le CSS), mais qui garde intacte la plage défigée, et qui est lié à 150 pages de site : en un seul clic, on modifie de fond en comble les 150 pages du site, en maintenant intact tout le contenu qui leur était propre. A chaque fois qu'on sauvegarde un template, tous les fichiers qui ont été créés à partir de lui sont également modifiés et sauvegardés.
J'avais d'ailleurs tenté de créé un tout nouveau template, et l'avais sauvegardé sous le nom de l'ancien template - donc en écrasant le template d'origine. Ca coupe une partie des liens entre les fichiers qui en dépendent. Tout fichier nouvellement ouvert sera sauvé selon le template nouveau. Mais en sauvegardant des modifications du nouveau template (qui a donc repris le nom de l'ancien), la sauvegarde automatique des autres fichiers qui en dépendent est perdue.
Dès lors, si, sur toutes mes pages, j'ai par exemple:
- une photo, toujours la même, en haut à gauche,
- un titre de site, toujours le même, en haut à droite,
- une barre de navigation, toujours la même, sous le titre,
- et une colonne d'info, toujours la même, sous la photo, contenant par exemple une liste de liens (internes et externes);
- et que seul un tiers (relatif) de la page (sous le titre et la barre de navigation) contient du texte qui est différent d'une page à l'autre :
le template permettra de garder les mêmes données pour toutes les pages, excepté la partie texte défigée, personnalisable pour chaque page distincte. Et si je décide de modifier ces données figées, peu importe lesquelles (la photo, ou la barre de navig, ou le titre du site, ou tout à la fois, ou en le rendant responsive) : au moment de l'enregistrement du template : les 150 pages du site sont elles aussi réenregistrées avec les nouveaux contenus.
Il y a même mieux : je peux créer un template2 à partir du template1, et qui reste dépendant du template1. Si dans le second template, je défige la colonne d'info (à gauche, sous la photo) qui donne des listes de liens, en plus de la partie texte déjà défigée - il y a donc deux régions modifiables, plus aussi celle des propriétés de la page dans la partie "head" - et que je la remplace par un sommaire du texte de la page (avec plein de liens internes vers les ancres disséminées dans le texte de droite), de manière à publier par exemple, via ce template2, un bouquin entier en X pages. En faisant les modifs dans le template1, elles seront enregistrées également dans le template2, et donc toutes les pages du bouquin seront modifiées automatiquement lors de l'enregistrement du template1.
J'ai tout à fait conscience que le CMS permet de faire la même chose de manière différente et plus facile. Mais dans mon cas précis, déménager tout mon site (créé en Dreamweaver il y a belle lurette) vers un CMS, impliquait du recopiage de texte pour 150 pages, et du réencodage en masse de liens internes : avec toutes les distractions que cela implique, et donc toutes les vérifications que cela impose; et le côté abrutissant sur une durée énorme pour le faire.
Je me suis épargnée tout cela, et je me suis amusée à recréer mon template, avec les infos et la guidance du coach (4 heures ont suffi). De plus, psychologiquement parlant, je n'ai pas jeté à la poubelle tout le travail que j'ai fait pendant toutes ces années pour construire mon site. J'ai tout gardé. Ca ne m'a pas pris trop de temps, presque pas d'argent, et j'ai conservé mon site d'origine sur mon disque dur.
En réalité j'ai dû pratiquement reconstruire la page template de base, car pour rendre le site responsive, il ne suffisait pas de faire passer les formats du html dans un fichier CSS externe, il fallait que le contenu html change de forme. La barre de navigation qui était un tableau est devenu un ensemble de div structurés en grid. L'ordre des div présenté dans l'ancien template, a été complètement chamboulé, et encore d'autres changements ont dû être apportés. Donc c'est bien le contenu html qui devait à tout prix être modifié pour rendre possible que le site devienne responsive. Un fichier CSS externe n'aurait, et de loin, pas suffi. Et pourtant la page obtenue ressemble tout à fait à la page d'origine.
Or, si j'avais suivi tous les conseil reçus, le déménagement vers le CMS aurait impliqué un nouvel apprentissage (ce que j'ai dû faire partiellement aussi pour le CSS en apprenant à utiliser l'éditeur, les meta queries et les grids) et donc, à cela je ne me serais pas opposée. Mais cela aurait impliqué surtout ce ré-encodage en masse. Non seulement, j'aurais dû recopier le contenu des 150 pages (la partie texte des régions modifiables); ce qui est long, mais aurait été acceptable si les formats étaient respectés. Mais tous les liens internes : renvoi vers d'autres pages de mon site, ou renvoi vers d'autres paragraphes sur la même page, auraient dû être réencodés un par un. Même si le CMS permet de le faire de manière plus simple et ludique qu'un copy colle d'une <aref....> (en tout cas Dreamweaver le permet de manière plus ludique); cela aurait impliqué des centaines ou milliers de manoeuvres à effectuer + les vérifs, et corrections. Bref, un travail de malade, que je me suis épargnée.
Quand j'ai sauvegardé mon template modifié et que toutes mes pages l'ont été en un clic, j'ai eu le miracle sous mes yeux.
J'espère à présent que cela va pouvoir tenir entre 3 et 5 ans, voire plus. Ensuite, j'envisagerai peut-être autre chose. L'évolution allant tellement vite, il sera peut-être nécessaire de créer tout à fait autre chose dans un autre environnement, car les CMS seront alors peut-être eux aussi devenus obsolètes. Ou à l'inverse, les CMS deviendront capables d'intégrer un site html existant pour le rendre gérable via le CMS; ce qui me permettra de garder mon site et le faire évoluer en CMS.
En tout cas, pour des non professionnels qui ont un vieux Dreamweaver sur leur pc, qui ont un site statique avec de nombreuses pages créées à partir d'un (ou plusieurs) template(s), et qui n'ont pas envie de débourser des mille et des cents, qui n'ont pas des dizaines ou centaines d'heures disponibles, pour rendre leur site responsive, ou pour modifier de manière importante la présentation de leur site : je conseille vivement de garder leur programme, de trouver une aide extérieure pour apprendre un peu plus de code (html et css) et d'exploiter la veine "template de Dreamweaver" à volonté. Elle en vaut la peine. Et surtout ne vous laissez pas influencer par ceux qui veulent se faire de l'argent sur votre dos, ou par ceux qui vous disent que rester sur Dreamweaver n'en vaut pas la peine. C'est parce qu'ils ignorent l'avantage réel des templates proposés par Dreamweaver et les confondent avec ce qu'on appelle couramment des templates dans d'autres programmes.
Et je me permets d'insister : pour le référencement. Car je ne doute pas une seconde, que quelqu'un qui posera une question du genre dans un moteur de recherche pourra tomber sur ce message.
Modifié le 7 nov. 2021 à 04:56
https://openclassrooms.com/forum/sujet/editeurs-wysiwyg-vs-hand-coding-21710
Bien sûr le contexte(besoin, cahier des charges/nécessités et exigences de qualités ou pas, persistence ou non dans le temps-auquel vous êtes confronté ) sont aussi à prendre en compte mais bon en général un site c'est un outil de communication donc l'un de ses buts fournir des informations/documents et cela de façon durable et en permettant la modification.
Statistiques (aussi article peu récent: d'il y a 3 ans) sur la façon de faire un site web, vous remarquerez que la part avec un queconque WYSIWYG n'est même pas évoqué et pour cause :
https://web.developpez.com/actu/311494/Le-CMS-WordPress-est-desormais-utilise-sur-39-5-pourcent-des-sites-web-seuls-38-4-pourcent-des-sites-Web-n-utilisent-pas-un-CMS-selon-les-statistiques-de-W3Techs/