Je veux dire, c'est le principe d'un outil que d'avoir certaines conventions : ce que je critique, c'est le fait d'en avoir inventé une nouvelle.
Mais avec l'expérience, j'ai tendance à préférer le lourdingue mais standard, à du moins lourdingue mais « exotique ».
Les outils existants et les conventions qui venaient avec ne me satisfaisaient pas, donc j'ai en effet créé (encore) un autre outil avec (encore) de nouvelles conventions. C'est un choix qu'on fait tout le temps: utiliser un outil existant et s'y plier, ou bien développer son propre outil. J'ai toujours aimé développer mes propres outils (j'utilise mon propre éditeur de code, notamment), c'est une façon d'être indépendant des évolutions faites dans des outils "standard" et d'avoir un outil conçu par rapport à mes pratiques. Bien sûr je n'utilise pas que des outils que j'ai développés, mais je suis attaché à l'idée que chacun puisse choisir d'utiliser les outils existants ou de développer les siens; c'est aussi de là que vient la diversité, avec les outils comme "véhicules" pour communiquer des idées.
si tu places ton système dans le monde « hypertexte », les références relatives des URL doivent se faire par rapport à l'emplacement du document lui-même.
Ok. J'avais commencé un greffon dans ce sens, que je ne n'ai pas eu encore le temps de finir. Puisque c'est la norme de faire ainsi, je pourrais en faire le fonctionnement par défaut. Merci.
Pour info, dans Stog, un document peut faire référence à un autre en indiquant son chemin depuis la racine du site, mais comme ça peut vite devenir lourd, on peut aussi indiquer seulement la fin du chemin, tant que celle-ci est unique (voir un exemple ici).
Je n'ai pas tout à fait compris cette phrase : tu veux dire que les balises « processées » par Stog sont seulement celles filles du nœud racine ?
Oui et non. Le premier nœud permet d'indiquer des métadonnées (titre du document, date, ...) et le "corps" est dans les nœuds fils. Tout est donc utilisé par Stog, mais les attributs du nœud racine sont traités différemment: ils ne sont pas réécrits mais permettent d'enrichir l'environnement utilisé pour la réécriture. Plus précisément, tout le contenu du document permet d'enrichir l'environnement de réécriture appliqué au gabarit à utiliser (qui est celui indiqué par la balise racine), cf. mon exemple.
[^] # Re: Format des fichiers source ?
Posté par zoggy . En réponse à la dépêche Sortie de Stog en version 0.15. Évalué à 1.
Les outils existants et les conventions qui venaient avec ne me satisfaisaient pas, donc j'ai en effet créé (encore) un autre outil avec (encore) de nouvelles conventions. C'est un choix qu'on fait tout le temps: utiliser un outil existant et s'y plier, ou bien développer son propre outil. J'ai toujours aimé développer mes propres outils (j'utilise mon propre éditeur de code, notamment), c'est une façon d'être indépendant des évolutions faites dans des outils "standard" et d'avoir un outil conçu par rapport à mes pratiques. Bien sûr je n'utilise pas que des outils que j'ai développés, mais je suis attaché à l'idée que chacun puisse choisir d'utiliser les outils existants ou de développer les siens; c'est aussi de là que vient la diversité, avec les outils comme "véhicules" pour communiquer des idées.
Ok. J'avais commencé un greffon dans ce sens, que je ne n'ai pas eu encore le temps de finir. Puisque c'est la norme de faire ainsi, je pourrais en faire le fonctionnement par défaut. Merci.
Pour info, dans Stog, un document peut faire référence à un autre en indiquant son chemin depuis la racine du site, mais comme ça peut vite devenir lourd, on peut aussi indiquer seulement la fin du chemin, tant que celle-ci est unique (voir un exemple ici).
Oui et non. Le premier nœud permet d'indiquer des métadonnées (titre du document, date, ...) et le "corps" est dans les nœuds fils. Tout est donc utilisé par Stog, mais les attributs du nœud racine sont traités différemment: ils ne sont pas réécrits mais permettent d'enrichir l'environnement utilisé pour la réécriture. Plus précisément, tout le contenu du document permet d'enrichir l'environnement de réécriture appliqué au gabarit à utiliser (qui est celui indiqué par la balise racine), cf. mon exemple.