Etant donné que les cours ont repris et que les concours approchent pour moi, j'ai pas vraiment de temps pour revérifier tout cela...
Je le ferais donc bien tranquillement aux prochaines vacances scolaires.
En attendant, si tu veux bien, tu peux toujours tenir à jour ce topic en indiquant les nouveaux bugs ou problèmes (corrigés ou non).
@+
__________________________
Sujet résolu ? Pensez à mettre le tag
Un problème en C# ? Vérifiez celui-ci n'est pas déjà résolu dans la FAQ et que le sujet n'est pas traité parmis les tutoriaux ou les articles avant de poster dans le forum C#.
Pour les news d'entre temps, je repasserai. Mais je passais surtout pour parler d'une amélioration qui pourra interesser : les fichiers XML enregistrés sont maintenant formatés de manière à les rendre agréables à lires.
En effet, c'est bien beau d'avoir un format ouvert, si c'est pour avoir des format illisible à l'oeil. C'était donc concrêtement utile, et surtout cela va dans le sens du format concrêtement ouvert (car maniable et lisible).
C'est une sorte de XML beautfier, qui reformate le code de manière intelligente : il n'indente que certains éléments et pas d'autres, sans même avoir besoin du moindre modèle de document pour deviner le rôle des éléments.
Je ne lui donne cependant que 7/10 : il n'est pas parfait en certains points, mais devrait se montrer assez habile dans 95% des cas.
Note : le formatage XML n'est pas à prendre autant à la légère que que le reformatage HTML/XHTML, dut à l'importance de la présence/abscence d'espace qui doit absoluement être respecté pour preservé les données enregistrées (je ne parle pas de space="preserve".... mais du simple fait de l'abscence/présence d'espaces). A ce sujet, il reste quelque petite choses à corriger (des restrictions sur le formatage que se permet l'application), qui quand elle le seront, modifieront un peu l'aspect du code formaté, mais devrait tout de même le laisser encore assez bien formaté.
En l'état, ça n'a pas trop à envier au code XML écrit à la main... enfin, c'est au moins l'objectif.
Les commentaires sur cette fonctionnalité seront les bienvenues.
Il était fait réféfence dans le précédent post, au fait que l'on reformate pas du XML comme on reformate du HTML/XHTML (et ce, bien que XHTML soit en XML). Je me doit d'être plus précis à ce sujet : il existe un spécification qui défini formellement l'équivalence entre deux documents XML, de manière indirecte. Cette spécification, qui s'appelle "Canonical XML", définit la représentation canonique d'un document XML. Et deux documents XML sont dits identiques, si leurs représentations canoniques sont identiques.
Il n'existe aucune notion similaire en HTML/XHTML, et malheureusement, beaucoup de XML beautifier téléchargeables sur le web semblent ignorer cette notion d'identicité spécifique à XML. Alors si vous avez besoin d'un XML beautifier qui tente au mieux de respecter les règles, pensez à Lasidoré ;)
Ceci dit, et c'est le deuxième point, le stricte respect de l'identicité de deux documents XML, selon la règle du XML canonique, empêche certaines opérations de reformatage sur le code.
J'ai apporté aujourd'hui des modifications à l'algorithme, qui rendent le reformatage encore plus beau et pertinent qu'avec la version d'hier, tout en étant encore plus respectueux des règles précédements cités. J'ai ouvert et enregistré d'ancien sources XML, et j'ai eu le bonheur de voir qu'aprés êtres passé à la moulinette de cet embellisseur de code, ils étaient encore plus propres que tels qu'ils avaient été écrits à la main.
Mais malgré cela, afin d'obtenir un formatage agréable, le formatage par défaut se permet quelques entorses, tout en étant sufisament bien pensé pour les minimiser au maximum. Ces entorses, qui sont bien identifiées et isolées dans l'application, ne posent que rarement problème avec les documents destinés à être publiés comme des documents texte (ce qui est un des aspects centraux de Lasidoré).
Comme le respect des règles reste malgré cela important, et qu'il peut servir à certaines personnes (tout comme servir aussi à démontrer le fiabilité des applications derrières Lasidoré, c'est le genre de chose auxquels on attache de l'importace), il y a deux modes de fonctionnement possibles : l'un stricte, l'autre non.
Le mode par défaut est le fonctionnement non-stricte, pour deux raisons.
1) La plupart des personnes voulant tester l'application ne vont certainement pas manquer par curiosité de consulter le code produit, et comme le formatage non-stricte est à privilégié pour les cas où le code doit être consulter/édité dans un simple éditeur de texte brute ou éditeur de code, alors c'est une bonne raison de choisir ce mode comme mode par défaut.
2) Comme l'application est initialement orienté vers l'édition de document orienté texte et sémantique, et que c'est avec ce type d'application XML que le mode non-stricte ne pose pas de problème, c'était une deuxième bonne raison de choisir ce mode comme mode de fonctionnement par défaut.
L'option "stricte-canonical-xml" sera disponnible en tant qu'option des comptes personnelles, dès que la possibilité de s'inscrire et d'ouvrir un compte sera en service.
Il a été décidé que ce serait une option globale modifiable depuis un compte, parce que le fait pour une personne de souhaiter consulter le code source XML, et donc de préférer ou non l'un ou l'autre mode de formatage, ne dépend pas du document en cours d'édition, mais des habitudes de la personne concernée (l'enregistrement d'un compte offira d'autres fonctions interessantes.. mais ça, c'est surprise pour l'avenir )
Notez parmis ces commentaires, que Lasidoré effectue certaines certaines opérations sur un document, qui peuvent le rendre différent de l'original ouvert (toujours dut à la principale orientation de cet éditeur). Le respect de l'identicité, doit donc également être pensé sous ces reserves spécifiques (mais qui ne concerne plus le formatage).
Ces modifications pouvant être effectués par l'éditeur sur un document, feront l'objet d'une page spécifique de l'aide (quand cette partie de la documentation aura été écrite, je posterai un message ici pour l'indiquer).
Bon, beh voilà, à plus.... prochaines étapes : correction d'un bug dans la prise en charge des sections CDATA lors de l'ouverture d'un XML, ainsi que la correction deux détails de l'interface utilisateur, et une prise en charge plus intelligente à l'ouverte, qui donnera un meilleur rendu dans l'éditeur pour les documents sans modèle de document associé (sans annoncer de délais).
[...] et une prise en charge plus intelligente à l'ouverte, qui donnera un meilleur rendu dans l'éditeur pour les documents sans modèle de document associé (sans annoncer de délais).
C'est justement l'objet de la dernière fonctionnalité que je vous invite à essayer. L'effet s'exprime surtout encore une fois avec les XML fait pour le texte : si vous ouvrez par exemple une feuille XSLT, ça ne sera pas formidable (d'autant qu'avex XSLT, tout est enregistré dans les attributs). Ouvrir un fichier RSS est déjà plus interessant, mais le mieux c'est encore si vous ouvrez un document texte structuré par XML (Ex. docBook, pour prendre un exemple connu).
Concernant la prise en charge des XML n'ayant pas de modèle de document attaché, la structuration du texte apparaît maintenant plus clairement, et le confort pendant l'édition se rapproche mieux ce ce que l'on peut connaître avec un éditeur classique (l'objectif de cette éditeur, qui était de s'éloigner de la sensation d'écrire du code, commence à prendre forme).
Tout comme avec le formatage du code XML précédement présenté, l'application essai de deviner la meilleure présentation des différents éléments... mais cette fois ci cela concerne donc l'affichage lors de l'édition.
Au sujet d'XML, il est important de noter qu'il existe deux versions à ce jour : XML 1.0, et XML 1.1. Il y a bien dans la spécification XML 1.1 un chapitre intitulé "Rationales and list of changes", mais un peu de retour d'expérience peut être utile pour mieux prendre conscience des différences entre les deux versions.
Sans prendre aucun partie, je post ce message pour porter à votre connaissance cette page qui aborde cette question : XML 1.1: Dead on Arrival - september 2005.
.... à seul fin d'information (sans prendre partie, d'autant que je reconnais que le titre de cette page se veut frapper les esprits un peu fort).
Concernant Lasidoré, c'est l'occasion d'apporter une précision : l'application peut lire le XML 1.0 et le XML 1.1. Un détail d'implémentation est important à noter : le "parseur" (désolé, je ne connais pas le terme francisé) est conçu à partir des spécifications XML 1.1, et la prise en charge de XML 1.0 est implémentée par des dérivations dans un traitement basé sur XML 1.1. En conscéquence, la fiabilité n'est garantie formellement que pour XML 1.1, et non pas pour XML 1.0, bien qu'évidement l'objectif soit de le supporter au mieux.
L'une des différences les plus concrêtes et immédiates entre les deux versions, se situe dans les caractères autorisés. XML 1.1 est plus restrictif que XML 1.0 et introduit la notion de "restricted characters", qui oblige à utiliser des entités (eg. &#xnnnn;) pour certains caractères que l'ancienne version autorisait à apparaître directement. Cette différence est prise en charge.
__________________________ Lasidoré : Editeur XML orienté sémantique/Online XML editor- Alpha Utiliser le Compilateur Ada GNAT- Fiabilité professionnelle, Ada we trust Opera, Le navigateur- Léger, rapide, efficace, joli et source d'inspiration DragonFly, Le debugger JavaScript, CSS, ... et HTML- Only on Opera Exalead Search- Beceause Google is not a synonym of “ search engine ”
Le développement de l'éditeur XML en ligne, Lasidoré, à repris dernièrement. Récement : refonte du code pour le rendre plus solide et le préparer aux évolutions futurs de l'application, affinement de l'interface utilisateur pour la rendre plus jolie, ammélioration de la compatibilité avec les différents navigateurs (le curseur texte sous Fireox n'est pas encore parfaitement géré, et il lui arrive de disparraître dans certaines circonstances), accelération du temps de chargement d'une partie de l'application (un unique fichier JavaScript au lieu de plusieurs, et le JavaScript est maintenant compréssé... l'émmélioration est notable).
À bientôt pour d'autres nouvelles
Support : Le support pour FireFox 2, bien que maintenu, n'est plus une priorité, étant donné que la quasi totalité des utilisateurs/rices de FireFox ont migré vers FireFox 3. Le support pour Internet Explorer 6 est maintenu, car il représente toujpurs un grand pourcentage des utilisateurs de l'informatique et du web. Opera est supporté, mais il est vivement recommandé de s'en tenir à la version 9.5 au minimum : en efet, les versions précédentes souffrent d'un bug incontournable qui a comme effet du supprimer du texte dans les documents en cours d'édition, lors de l'insertion d'éléments. Safari n'est pas supporté, car les tests étant éffectués sous Windows, et Safari Windows étant malheureusement trop instable, il n'est pas possible de déscement valider Lasidoré sous Safari.
En résumé, le support est prévu pour : Internet Eplorer 6 minimum, Internet Explorer 7, Opera 9.5 minimum, FireFox 2 minimum (partiellement), FireFox 3
Rappel. Lasidoré n'ouvre que les fichiers XML valides. Exemple : un fichier qui commence par une déclaration <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> en première ligne, n'est que trés peu probablement un fichier XML valide. Au contraire, un fichier qui commence par <?xml version="1.0" encoding="utf-8"?> a de bien plus grandes chances d'être un fichier XML valide.
J'en parle, parce que j'ai des logs d'erreurs de l'application qui m'indiquent que l'application « a calé » (je vous rassure, pas planté quand-même) plusieurs fois aprés avoir eu à faire à des fichiers qui avaient l'extention .xml mais qui arboraient fièrement une déclaration HTML en guise de prolog.
Reference XML 1.1 dit :
2.1 Well-Formed XML Documents
[Definition: A textual object is a well-formed XML document if:]
Taken as a whole, it matches the production labeled document.
It meets all the well-formedness constraints given in this specification.
Each of the parsed entities which is referenced directly or indirectly within the document is well-formed.
Note. la version XML 1.0 ne fait pas exception, et attend le même prolog, même si XML 1.0 et XML 1.1 diffèrent en d'autres points, elle sont toutes les deux unanimes sur ce point.
Un fichier qui ne remplie pas ces conditions fondamentales, ne peut pas être un fichier XML valide.
Voilà, et encore désolé de m'être permis ce ton un peu sévère genre prof.