Pages :
J'ai qq pages HTML et une feuille de style CSS. J'utilise aussi du PHP pour faire afficher certaines pages HTML à côté du menu.
Je suis satisfait de ce travail.

Maintenant, j'aimerais passer à la vitesse supérieure et créer des pages XHTML à partir de XML+XSL. J'ai commencé à faire un fichier XML et une feuille XSL. Le formattage sous XSL me semble plus compliqué que pour une feuille CSS. Par exemple, lorsque je veux faire afficher un même élément (<item>) repris à plusieurs endroits de XML, sous un certain format, je crois que je suis obligé de refaire <xls:template...> alors qu'avec une feuille de style CSS, on le fait une fois pour toute.

Peut-être que je m'y prends mal? Pourrait-on me guider, svp?
Modifié par brunocaccio (26 Jan 2006 - 15:53)
Bonjour, Smiley smile
brunocaccio a écrit :
Je suis satisfait de ce travail.
Bon c'est un bon départ.
brunocaccio a écrit :
j'aimerais passer à la vitesse supérieure et créer des pages XHTML à partir de XML+XSL
Bravo, je ne peux que t'encourager.
brunocaccio a écrit :
Le formattage sous XSL me semble plus compliqué que pour une feuille CSS
Les 2 langages n'ont rien à voir, il ne peuvent en aucun cas être comparés, puisque leurs objectifs respectifs ne se situent absolument pas sur le même plan. Malheureusement les 2 sigles font tous les deux apparaître le terme "stylesheet", ce qui prête à confusion. Au contraire, XSLT et CSS sont totalement complémentaires, et pour atteindre le but que tu te fixes tu dois impérativement utiliser les deux :
- XSLT permet de définir de façon souple et riche la structure de XHTML
- CSS, comme d'habitude, permet de styler ce XHTML
Chacun dans son rôle, l'un ne pouvant pas remplacer l'autre.
brunocaccio a écrit :
lorsque je veux faire afficher un même élément (<item>) repris à plusieurs endroits de XML, sous un certain format, je crois que je suis obligé de refaire <xls:template...>
Je n'ai pas bien compris, mais <xls:template...> permet de définir une structure ou paterne que l'on peut ensuite utiliser autant de fois que nécessaire en fonction de conditions éventuellement complexes. Donc au contraire je dirais que la définition d'un template est une excellente façon de factoriser efficacement du code pour éviter la répétition...
Ok, merci pour ces précisions Xavier.
Alors, si j'ai bien compris, la démarcher à employer serait la suivante:
1/ on code du XML pour struturer l'information,
2/ on code du XSL pour placer l'information sur la page XHTML,
3/ on transforme le XML par XSLT,
4/ on ajoute une feuille de style CSS pour formater la page XHTML?

Si c'est bien ça, j'ai qq questions:
1/ comment faire la transformation la plus naturellement possible. J'ai vu qu'on pouvait utiliser PHP ou un code JAVA. Malheureusement, je n'ai pas les deux outils qui permettent de le faire. Y'a-t-il une autre méthode?

2/ Une fois qu'on a ce fichier XHTML, on peut alors la visualiser pour construire sa feuille de style CSS. C'est bien comme ça?
a écrit :
Alors, si j'ai bien compris, la démarcher à employer serait la suivante:
1/ on code du XML pour struturer l'information,
2/ on code du XSL pour placer l'information sur la page XHTML,
3/ on transforme le XML par XSLT,
4/ on ajoute une feuille de style CSS pour formater la page XHTML?
Oui c'est une bonne description technique. Dans la pratique les différents points ne sont pas forcement séquentiels lorsqu'on réalise un site web.
a écrit :
comment faire la transformation la plus naturellement possible. J'ai vu qu'on pouvait utiliser PHP ou un code JAVA. Malheureusement, je n'ai pas les deux outils qui permettent de le faire. Y'a-t-il une autre méthode
Une transformation XSL nécessite un processeur XSLT. Je n'en connais qu'un qui soit standalone. C'est xsltproc. Tu trouveras des liens sur cette page pour le téléchargement de binaires en fonction de ta plateforme. Cet outil en ligne de commande est peu pratique (mais standalone). Tu peux également utiliser les navigateurs dotés d'un processeur XSLT comme Firefox ou IE6. De mon point de vue ce n'est pas pratique non plus. Je préfaire l'utilisation d'éditeurs disposant d'un plugin XSLT. Il y a par exemple Xemacs ou Jedit. Dans les 2 cas les plugins passent à main à Saxon ou Xalan 2 processeurs XSLT bien connus qui nécessitent une machine virtuelle java. Personnellement j'utilise aussi beaucoup PHP avec l'API XSL fondée sur la librairie libxslt (même code que xsltproc).

Pour ce qui concerne java, la plupart des OS intègre une machine virtuelle. Coté PHP, son installation est rapide (1/4 d'heure pour apache+php si tu as l'habitude, 1/2 journée la première fois).

Enfin je suis certain qu'il existe beaucoup d'autres solutions sur d'autres plateformes, telle que .NET par exemple.
Bonjour,

Xavier a écrit :
Alors, si j'ai bien compris, la démarcher à employer serait la suivante:
1/ on code du XML pour struturer l'information,
2/ on code du XSL pour placer l'information sur la page XHTML,
3/ on transforme le XML par XSLT,
4/ on ajoute une feuille de style CSS pour formater la page XHTML?
Oui c'est une bonne description technique. Dans la pratique les différents points ne sont pas forcement séquentiels lorsqu'on réalise un site web.
moi décidement j'ai du mal à comprendre cette logique ! Pourquoi coder du XML non XHtml pour ensuite le transformer en XHtml ? Parceque XHtml est du XML donc pourquoi inventer un nouveau langage XML (et au passage réinventer la roue) alors que XHtml est là pour ça ?
Si on a le contrôle sur le document de départ, alors autant le coder directement en XHtml, non ?

a+
a écrit :
Alors, si j'ai bien compris, la démarcher à employer serait la suivante:
1/ on code du XML pour struturer l'information,
2/ on code du XSL pour placer l'information sur la page XHTML,
3/ on transforme le XML par XSLT,
4/ on ajoute une feuille de style CSS pour formater la page XHTML?

Alors moi ce que je ne comprends pas c'est la différence entre l'étape 2 et l'étape 3, les différences dans les rôles de XSL et de XSLT. Pourrait-on me l'éxpliquer ?

a écrit :
moi décidement j'ai du mal à comprendre cette logique ! Pourquoi coder du XML non XHtml pour ensuite le transformer en XHtml ? Parceque XHtml est du XML donc pourquoi inventer un nouveau langage XML (et au passage réinventer la roue) alors que XHtml est là pour ça ?
Si on a le contrôle sur le document de départ, alors autant le coder directement en XHtml, non ?


Peut-être qu'on à besoin de mettre les données de notre document de départ dans un document XML pour d'autre applications que le web et que ayant le XML déjà fait, il est plus facile de produire ensuite du XHTML via les étapes ci dessus... sinon c'est vrai que je me pose un peu la même question que toi SirWam, pourquoi faire toutes ces étapes alors qu'on produire directement le XHTML...
Le problème surtout c'est que les gens sont convaincus qu'il faut du XML brut pour produire autre chose que du XHtml, alors qu'on peut très bien faire une transformation XHtml -> FO ou XHtml -> uneautreformatXML.

Xsl et Xslt sont la même chose (en simplifiant).

a+
a écrit :
Alors moi ce que je ne comprends pas c'est la différence entre l'étape 2 et l'étape 3, les différences dans les rôles de XSL et de XSLT. Pourrait-on me l'éxpliquer ?


Oui, c'est la même étape. Si j'ai dissocié les deux, c'est pour montrer qu'il y a d'abord l'écriture du fichier XSL et ensuite la transformation du fichier XML en XHTML par le biais du fichier XSL. Mais ce que j'ai fini par comprendre c'est que cette transformation se fait par un programme, c'est pr ça qu'on parle de XSLT. On pourrait croire que IE6 fait ça automatiquement mais ça marche pas aussi facilement. Du coup, on est obligé de passer par un programme java ou php. Et malheureusement, c'est cette étape qui me manque.
SirWam a écrit :

moi décidement j'ai du mal à comprendre cette logique ! Pourquoi coder du XML non XHtml pour ensuite le transformer en XHtml ?
Si on a le contrôle sur le document de départ, alors autant le coder directement en XHtml, non ?
Un procès d'intention ?
En tout cas dans mes propos "coder en XML" ne veut pas dire "coder du XML non XHtml". XML décrivant un cadre bien plus général que XHTML, parler de XML permet donc de désigner une classer de problèmes bien plus large que l'emploi du terme XHTML ne l'aurait permis.
Dans mon esprit "coder en XML" signifie respecter la syntaxe XML et choisir la DTD qui convient au contenu que l'on a à traiter, et il se peut que dans des cas particuliers (qui apparaissent fréquemment il est vrai) XHTML soit la bonne DTD.

Mais il y a aussi d'autres cas que je ne souhaite pas oublier :
- comme tu le sous entends, on a pas forcement le contrôle total du document
- même en cas de contrôle total, je peux choisir une DTD qui me semble plus appropriée, en particulier si je fais un usage multiple du document et non pas seulement web. Je pourrais citer en exemple : SVG, MAthML, Docbook...
SirWam a écrit :
Le problème surtout c'est que les gens sont convaincus qu'il faut du XML brut pour produire autre chose que du XHtml, alors qu'on peut très bien faire une transformation XHtml -> FO ou XHtml -> uneautreformatXML.
Je ne sais pas d'où tu tires cette généralité, et je ne vois pas où elle s'applique dans cette discussion. Enfin je vois mal quel obstacle "les gens" pourraient voir à XHtml -> FO ou XHtml -> uneautreformatXML puisque XHTML est du XML.
Slt,

j'ai souvent vu des gens sur des forums qui après avoir découvert Xslt, se mettaient à générer du code du genre :
<news>
<item date="17 Août 2005" auteur="Jojo">Bla bla bla</item>
<!-- etc etc -->
</news>

pour le retransformer ensuite en XHtml. Je croyais que c'était ce que tu préconisais mais je me trompais !

Cya
SirWam a écrit :
moi décidement j'ai du mal à comprendre cette logique ! Pourquoi coder du XML non XHtml pour ensuite le transformer en XHtml ? Parceque XHtml est du XML donc pourquoi inventer un nouveau langage XML (et au passage réinventer la roue) alors que XHtml est là pour ça ?
Si on a le contrôle sur le document de départ, alors autant le coder directement en XHtml, non ?

a+

Bonjour (premier post en ces lieux donc un petit boujour ne fait pas de mal Smiley murf ),

utilisant les formats XML, XSL(T), XHTML et CSS pour générer les pages de mon site je peux t'expliquer ce que cela m'apporte.
L'utilisation des couples XML, XSL(T) et XHTML-CSS me permettent de bien séparer contenu, format final et présentation :

- Le format XML gère le contenu du site : toutes les pages (plus exactement morceaux de pages) sont écrites en ce format ;
- via des feuilles XSL(T) ces blocs de pages XML sont transformés en XHTML (ou autres formats selon le besoin) pour au final être rassemblés en une page XHTML Strict 1.0 par PHP ;
- au final les feuilles de style CSS régissent la présentation graphique.

Cela me permet pour un seul et unique fichier XML de lui appliquer divers templates, ces derniers étant des feuilles XSL(T) mais aussi différentes feuilles de styles CSS. Ainsi même si le contenu reste inchangé je peux à ma guise fournir un format final ainsi qu'une présentation différentes.

L'emploie de ces technologies me procurent au final une grande souplesse de manoeuvre.

Aussi il n'est pas nécessaire de générer à la voler les pages XHTML par transformation XML->XHTML via XSL(T), il suffit de mettre sur pied un petit gestionnaire de cache et la génération ne se fait qu'une seule fois Smiley smile

En espérant avoir été assez clair dans mes propos ^^;
a écrit :
piouPiouM a écrit:
ces blocs de pages XML sont transformés en XHTML (ou autres formats selon le besoin) pour au final être rassemblés en une page XHTML Strict 1.0 par PHP

Je voudrais faire de la transformation XSLT mais je ne sais pas comment procéder. J'ai essayer ça :
<xsl:output ...>
mais ça ne marche pas. Pour le PHP, je ne vois pas comment tu fais. Tu as tes fichiers XML et XSL et ton bout code PHP est logé? Et il faut que le serveur dispose de PHP, comment la transformation se fait?

a écrit :
piouPiouM a écrit:
Aussi il n'est pas nécessaire de générer à la voler les pages XHTML par transformation XML->XHTML via XSL(T), il suffit de mettre sur pied un petit gestionnaire de cache et la génération ne se fait qu'une seule fois

Peux-tu nous dire exactement la procédure, stp?
Un post qui sera un peu long à cause des sources Smiley confused
(si cela gène, je pourrai les mettres à disposition en liens)

Pour répondre de manière plus claire, voici des exemples de sources XML, XSL et pour finir PHP pour montrer un exemple de transformation XML par XSL via l'extension DOM XML ainsi que la gestion d'un cache.

Le résultat de la transformation est un bout de code XHTML qu'il faudra inclure dans une page ayant une structure complète Smiley smile

Bon, là évidement il n'y a pas de gestionnaire d'erreurs, toussa, il ne sagit que d'un exemple ^^

XML :

<?xml version="1.0" encoding="ISO-8859-1"?>
<liens>
	<infos>
		<title>Titre de la page des liens</title>
		<introduction>
			Une introduction. On peut y retrouver des balises comme l'<strong>emphase forte</strong> ou encore des acronymes comme <acronym title="Internet Relay Chat" xml:lang="en" lang="en">IRC</acronym> par exemple.
		</introduction>
	</infos>
	<group name="Nom du groupe n°1">
		<item>
			<name>intitulé du lien 1</name>
			<loc lang="fr">http://www.perdu.com/</loc><!-- url + langue -->
			<description>Description du site.</description>
		</item>
	</group>
	<group name="Nom du groupe n°2">
		<item>
			<name>#gimp-fr</name>
			<loc>irc://irc.freenode.net/#gimp-fr</loc>
			<description>Canal <acronym title="Internet Relay Chat" xml:lang="en" lang="en">IRC</acronym> francophone dédié à GIMP (et plus si affinités).</description>
		</item>
		<item>
			<name>Gimp4you</name>
			<loc>http://gimp4you.eu.org/</loc>
			<description>Vous trouverez sur Gimp4you des tutoriels pour le logiciel The Gimp 2.</description>
		</item>
	</group>
</liens>



XSL :

<?xml version="1.0" encoding="ISO-8859-1" ?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
	<xsl:output method="xml" omit-xml-declaration="yes" encoding="ISO-8859-1" indent="yes" />
	
	<!-- RACINE DU DOCUMENT -->
	<xsl:template match="/">
		<xsl:apply-templates />
	</xsl:template>
	
	<!-- On traite la page -->
	<xsl:template match="liens">
		<h1 id="linksTitle"><xsl:value-of select="infos/title" /></h1>
		<xsl:apply-templates select="infos/introduction" />
		<xsl:apply-templates select="group" />
	</xsl:template>
	
	<!--
		J'applique un template pour que les éventuelles balises se trouvant
		plus bas soit traitées
	-->
	<xsl:template match="infos/introduction">
		<p id="intro">
			<xsl:apply-templates />
		</p>
	</xsl:template>
		
	<!-- Traitement des groupes et items -->
	<xsl:template match="group">
		<h2><xsl:value-of select="@name" /></h2>
		<xsl:for-each select="item">
			<dl>
				<dt>
					<a>
						<xsl:if test="loc/@lang">
							<xsl:attribute name="hreflang"><xsl:value-of select="loc/@lang" /></xsl:attribute>
						</xsl:if>
						<xsl:attribute name="href"><xsl:value-of select="loc" /></xsl:attribute>
						<xsl:value-of select="name" />
					</a>
				</dt>
				<dd><xsl:apply-templates select="description" /></dd>
			</dl>
		</xsl:for-each>
	</xsl:template>
	
	<!--
		Au tour des définitions.
		Comme pour /infos/introduction j'applique un template
	-->
	<xsl:template name="description">
		<xsl:apply-templates />
	</xsl:template>
	
	
	<!--
		Balises que l'on peut rencontrer dans une définition.
		On les recopies à l'identique.
	-->
	<xsl:template match="a | acronym | strong | em | i | b | span">
		<xsl:copy-of select="." />
	</xsl:template>
</xsl:stylesheet>


PHP :

<?php

function transformXML($xml,$xsl,$cache=true,$params=array())
{
	$xml_ = explode('.',$xml);
	$fichier_en_cache = './cache/'.$xml_[0].'.html';
		
	# cache demandé, vérification si besoin d'une maj
	if ($cache and file_exists($fichier_en_cache)
						 and filemtime($fichier_en_cache) > filemtime($xml)
						 and filemtime($fichier_en_cache) > filemtime($xsl))
	{
		# il n'y a pas eu de modifications des fichiers sources,
		# on lit le fichier présent en cache
		readfile($fichier_en_cache);
	}

	# une maj a été faite sur un des fichiers sources,
	# on transforme le fichier XML avec la feuille XSL
	else
	{
		// chargement de la feuille de styles XSL
		$objet_XSL = domxml_xslt_stylesheet_file($xsl);
		// Chargement du fichier XML
		$objet_XML = domxml_open_file($xml);
		// Transformation
		$objet_final = $objet_XSL->process($objet_XML,$params);
		// Sortie de la transformation
		$resultat = $objet_final->html_dump_mem();
		
		# La transformation XSL s'est bien déroulée
		if ($resultat)
		{
			// si le cache avait été demandé, on place la page générée dans
			// le répertoire ./cache/[répertoire_contenant/]
			if ($cache)
			{
				if (!file_exists('./cache/'.dirname($xml)))
				{
					$repertoire = './';
					$repertoires = explode('/','cache/'.dirname($xml));
					foreach($repertoires as $item)
					{
						$repertoire .= $item.'/';
						if (!file_exists($repertoire))
							mkdir($repertoire, 0755);
					}
				}
				// écriture du fichier en cache
				$f = fopen($fichier_en_cache,'w');
				fwrite($f,$resultat);
				fclose($f);
			}
			# on affiche l'objet
			echo $resultat;
		}
	}
}

/*
	Exemple d'utilisation.
		- Le dossier ./cache/bla est créé s'il n'existait pas ;
		- Le fichier ./cache/bla/liens.html est créé s'il n'existait pas ;
		- Le fichier ./cache/bla/liens.html est mis à jour si le fichier XML
		  ou XSL a été modifié.
*/
transformXML('bla/liens.xml','liens.xsl');

?>
Bonjour piouPiouM,

Je viens de prendre connaissance de ton code, et c'est vrai qu'au vu de cet exemple, j'aurais tendance à reprendre la remarque de Sirwam : si je comprends l'intérêt de XSLT pour assembler différents contenus et produire des pages XHTML à partir de sources "modulaires", je vois moins bien, en première approche, l'intérêt du choix de ta DTD propriétaire pour emballer ton contenu XML.
Il me semble après y avoir regarder rapidement qu'il y a un mapping 1 pour 1 entre les notions emmagasinées dans ton XML propriétaire et celles que l'on retrouve dans le XHTML résultat. Je ne crois pas que l'algorithmie XSLT apporte dans le cas présent de l'information, en retire ou en transforme de façon notable, si bien que tu économiserais cette transformation si tu stockais tout simplement tes contenus dans le XHTML.

XHTML est aussi un format dédié à structurer des contenus. La structure proposée par XHTML est assez convenable pour définir des contenus associés une page ou un fragment de page (titres, sous-titres, paragraphes, listes ... organisés séquentiellement). Or l'exemple de contenus que tu proposes ressemble exactement à cela...
Bonjour Xavier Smiley smile

Mon exemple ne reste qu'un exemple sur une page relativement simple.
Sur gimp4you il y a aussi des articles qui sont donc codés en XML ; la génération des sommaires et des barres de navigation (contenu provenant d'une autre source) est automatisée, la gestion des images est simplifiée, etc.
Certes, pour l'instant on pourrait dire que le format XHTML me conviendrait mieux (bien que personnellement je n'en soit aucunement convaincu), mais j'envisage dans un avenir proche 3 choses :
- supporter le format (ou une partie tout du moins) ODT afin de pouvoir tapper mes articles sous OpenOffice.org 2, la tranformation ODT->X(HT)ML sera alors prise en charge par une feuille XSL ;
- supporter les bbcodes, ce qui peut sembler être une ineptie étant donné que le texte formatté en bbcode n'a rien à voir avec de l'XML, mais il m'arrive de poster mes tutos sur des forums et je dois dire que formatter le tout à la main ne m'enchante guère... ;
- finalement développer un gestionnaire de contenu, somme toute simple, mais basé sur des templates en XSL.

Aussi l'emploi du format XML en tant que format natif me permet d'acquérir une plus grande souplesse. En effet, pour les articles par exemple, il me suffit d'apporter des modification sur une seule feuille XSL pour que les répercutions au niveau de l'XHTML se fassent sur toutes les pages. Si j'avais de l'XHTML en tant que format natif, il me faudrait modifier les pages une à une, quelle perte de temps Smiley sweatdrop (j'ai apprécié le fait d'employer le format XML et des templates XSL lors de la restructuration du code XHTML de gimp4you, quel gain de temps ^^ )
Le choix de XSLT parait tout à fait approprié pour réaliser l'agrégation de tes contenus, ce que tu appelles si je comprends bien un gestionnaire de contenus.
Mais l'application de ce principe ne présuppose rien sur le choix du langage XML utilisé pour décrire les contenus. Ce principe dit simplement :
(XML1 + XML2 + XML3 +...) + XSLT --> XHTML
Ensuite il est fort possible, et recommandé de choisir des DTD standards pour décrire XML1, XML2... et souvent XHTML convient. Ainsi il n'est pas péjoratif, au contraire, de réaliser :
(XHTML1 + XHTML2 +...) + XSLT --> XHTML,
et de temps en temps tu auras par exemple :
(XHTML1 + XHTML2 + SVG1...) + XSLT --> XHTML

Pour répondre à une de tes objections, il me parait tout à fait correcte de réaliser :
(XHTML1 + XHTML2 +...) + XSLT --> bbcode

J'ai réalisé il y a 3 ans une "sorte de CMS" qui ressemble exactement à ce que tu entreprends. Je me suis posé la question de savoir quelle était la bonne méthode pour entreposer les contenus. Notamment je me demandais quels formats XML adopter. J'avais envisagé :
- XML propriétaire
- XML openoffice (à l'époque en version 1)
- docbook
Je suis parti sur une sorte de mélange docbook+propriétaire. Je me suis rapidement rendu compte que ça ne tenait pas la route, en plus d'être parfaitement inutile. J'ai décidé d'en revenir aux DTD connues qui conviennent dans 99% des cas (j'ai de très rare exceptions) comme XHTML, MathML principalement. Pour éditer ton contenu, un éditeur de pages web (compatible XHTML) fait aussi bien l'affaire que openoffice. Pour l'instant je ne vois pas la plus value dont on pourrait bénéficier à faire des transformations ODT vers XHTML.

En revanche j'ai quand même du adopter une DTD propriétaire dans mon "CMS" pour obtenir une gestion globale d'un site web. En gros ce CMS est constitué de 3 étages :
- 1/ modélisation du site web
- 2/ contenus agrégés par page
- 3/ pages avec contenus structurés et mis en forme
entre chaque étage il y a transformation XSL. J'ai du adopté une DTD propriétaire pour la couche 1/ car je n'ai pas trouvé de standard adapté. XHTML modélise parfaitement une page, mais il manque vraiment la définition d'un standard pouvant modéliser un site web complet.
Entre 1/ et 2/ je génère certains contenus automatiquement qui peuvent être déduit du modèle, et/ou je recherche des contenus édités indépendamment, puis je les assemble par page.
entre 2/ et 3/ j'applique des templates comme tu l'as décrit.
Xavier a écrit :
Mais l'application de ce principe ne présuppose rien sur le choix du langage XML utilisé pour décrire les contenus. Ce principe dit simplement :
(XML1 + XML2 + XML3 +...) + XSLT --> XHTML
Ensuite il est fort possible, et recommandé de choisir des DTD standards pour décrire XML1, XML2... et souvent XHTML convient. Ainsi il n'est pas péjoratif, au contraire, de réaliser :
(XHTML1 + XHTML2 +...) + XSLT --> XHTML,
et de temps en temps tu auras par exemple :
(XHTML1 + XHTML2 + SVG1...) + XSLT --> XHTML
Tout à fait, c'est simplement que mon choix s'est porté sur le XML au lieu de l'XHTML : ma DTD comprend peu de propriétés, les balises employées sont simples et s'assimilent plus à un langage parlé, ce qui dans l'écriture de tutos m'évite de passer du temps à rechercher le nom de mes balises (même si le XHTML ne me pose aucun problème), bref j'optimise mon temps pour la rédaction Smiley smile

Xavier a écrit :
Pour répondre à une de tes objections, il me parait tout à fait correcte de réaliser :
(XHTML1 + XHTML2 +...) + XSLT --> bbcode
Merci pour la remarque Smiley smile
J'avais préféré présenter la chose étant comme une ineptie pour éviter des retours désagréables (expérience inside ^^; ).

Xavier a écrit :
Pour éditer ton contenu, un éditeur de pages web (compatible XHTML) fait aussi bien l'affaire que openoffice. Pour l'instant je ne vois pas la plus value dont on pourrait bénéficier à faire des transformations ODT vers XHTML.
La plus value à mes yeux est le conford (je suis chiant, n'est ce pas ? Smiley biggol ). J'ai en horreur de devoir tapper un long contenu, comprenant des images en plus, dans ces ridiculement petits textarea que je trouve fort inadaptés à ce genre de rédaction. Même si on utilise un éditeur JS WYSIWYG, je déteste =]
Ok je pourrai préparer mon texte puis le mettre en forme dans le textarea mais si je le tappe dans un éditeur de texte, pourquoi ne pas directement le formater aussi ?

Bon ensuite, le fait de vouloir exploiter le format ODT est un choix fait par curiosité et enrichissement personnel. En effet je suis relativement touche à tout ainsi qu'auto-didact et aime découvrir de nouveaux formats/technologies/etc.


Xavier a écrit :
En revanche j'ai quand même du adopter une DTD propriétaire dans mon "CMS" pour obtenir une gestion globale d'un site web. En gros ce CMS est constitué de 3 étages :
- 1/ modélisation du site web
- 2/ contenus agrégés par page
- 3/ pages avec contenus structurés et mis en forme
entre chaque étage il y a transformation XSL. J'ai du adopté une DTD propriétaire pour la couche 1/ car je n'ai pas trouvé de standard adapté. XHTML modélise parfaitement une page, mais il manque vraiment la définition d'un standard pouvant modéliser un site web complet.
Entre 1/ et 2/ je génère certains contenus automatiquement qui peuvent être déduit du modèle, et/ou je recherche des contenus édités indépendamment, puis je les assemble par page.
entre 2/ et 3/ j'applique des templates comme tu l'as décrit.

Je verrai quelle organisation j'adopterai, à vrai dire je ne sais pas encore exactement comment s'organisera tout ça, je suis justement entrain de plancher sur la chose Smiley ravi

Mes DTD évolueront certainement, rien n'est encore figé, il n'est pas exclu d'utiliser une DTD connue. Je n'envisage pas créer un système permettant de publier toute sorte de contenus, mais plus m'axer vers la publication de tutoriels, petite gestion de news, galerie. Bref, pas une uzine à gaz comme on en trouve à la benne aujourd'hui x_x
En effet, avant de coder mon site de A à Z je me suis penché sur la solution des CMS. Hors si l'on souhaite n'avoir qu'une petite structure il y a peu de choix (ensuite il faut que les possibilités offertes correspondent aux besoins, ce qui n'était pas le cas). Ok il est possible de n'activer que certains modules mais le noyau n'en reste pas moins lourd (et souvent accompagné d'un système de droits qui ne me servait strictement à rien).
Il y avait bien Dotclear comme beaucoup de sites utilisent mais désolé, je ne tiens pas un weblog qui est l'utilité première de cette solution... (en passant, bel outil Smiley cligne )

Pardon d'avoir détourné le topic Smiley confused
piouPiouM a écrit :
J'ai en horreur de devoir tapper un long contenu, comprenant des images en plus, dans ces ridiculement petits textarea que je trouve fort inadaptés à ce genre de rédaction
Pour la rédaction de contenus XML je pensais plutôt à Amaya ou NVU qui me paraissent très conviviaux pour créer un document structuré en XHTML.
piouPiouM a écrit :
vouloir exploiter le format ODT est un choix fait par curiosité et enrichissement personnel
Tu n'as pas tord.
Voilà un bel exemple d'architecture étrange dont je parlais !

Je voudrais justeajouter une chose : quid de la documentation ? C'est à dire, si quelqu'un d'autre que toi est amené à se servir de ton application, trouvera-t-il facilement toutes les informations nécessaires sur ton XML fait maison (sémantique des balises, attributs dispo, etc) ?

Par contre faire un truc un peu tordu par curiosité, ça je suis d'accord c'est formateur (j'ai fait des trucs vraiment tordus grâce à la curiosité !).

Cya
Modifié par SirWam (03 Feb 2006 - 20:15)
Pages :