Quelques corrections en vrac
Bonjour,
Serait-il possible de définir le delta à +01:00 par défaut ? (vu que Pluxml n'est que français pour le moment...)
Si un article est destiné à la page d'accueil, il ne faut afficher « Catégorie ». Idem en mode article (pas de |).
Il serait bien d'échapper le point dans les expressions régulières !
Par exemple :
Au niveau des images, peut-être faudrait-il rajouter l'extension « jpeg » en quatre lettres.
Je ne comprends pas pourquoi
Lors de l'opération
En outre, vous pouvez vous amuser avec les valeurs non nulles de $_FILES["userfile"]["error"] !
Deux petites questions pour finir :
pourquoi tout le temps utiliser des CDATA ?
et qu'en est-il de la rapidité de Pluxml lorsqu'il a quelques milliers de messages ?
Serait-il possible de définir le delta à +01:00 par défaut ? (vu que Pluxml n'est que français pour le moment...)
Si un article est destiné à la page d'accueil, il ne faut afficher « Catégorie ». Idem en mode article (pas de |).
Il serait bien d'échapper le point dans les expressions régulières !
Par exemple :
$admin->getMode('admin','/^[0-9]{4}\.([0-9]{3}|home|draft)(\.[a-z0-9-]*)*\.xml$/', $admin->config['bypage_admin']);
$admin->getMode('admin','/^[0-9]{4}.([0-9]{3}|home|draft)(.[a-z0-9-]*)*.xml$/', $admin->config['bypage_admin']);
if(is_dir($this->dir.'/'.$file) && !preg_match('/^(.|..)$/',$file)){
Au niveau des images, peut-être faudrait-il rajouter l'extension « jpeg » en quatre lettres.
Je ne comprends pas pourquoi
@chmod($uploadfile, 0777);
Lors de l'opération
move_uploaded_file($_FILES['userfile']['tmp_name'],$uploadfile);
En outre, vous pouvez vous amuser avec les valeurs non nulles de $_FILES["userfile"]["error"] !
Deux petites questions pour finir :
pourquoi tout le temps utiliser des CDATA ?
et qu'en est-il de la rapidité de Pluxml lorsqu'il a quelques milliers de messages ?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Je vais pas argumenter sur la plupart de ton message, Skyline le fera.
Mais pour réagir à tes questions : Parce que si tu ne le fais pas, tu es obligé d'échapper tous les « < », « > » et « " » de tes balises. Et si tu le fais, Pluxml ne verra pas la différence entre une balise « écrite » (<a>) et une balise « exécutée » (<a>).
MySQL est lourd car il doit ouvrir la connexion, faire une requête, l'envoyer et fermer la connexion. Le stockage dans des fichiers est un peu plus rapdide dans le concret.
Mais MySQL révèle ses capacités quand il s'agit de faire des requêtes extrêmement longues (des milliers de messages), alors que Pluxml en sera encore à analyser le contenu des balises XML.
Bref, l'avantage de MySQL niveau rapidité est indéniable quand il y a des milliers d'articles à charger.
Mais il n'y a pas à s'inquiéter : à moins d'être suicidaire, le nombre d'articles parsés par page ne dépassera pas les 15, et là c'est suffisant.
Franchement, la gestion du CDATA complique les choses pour rien. Et ne pas utiliser l'utf-8 aussi !
Pour ce qui est du temps d'excution, on n'est pas plus performant avec nos fichiers Xml, seulement le fait de réduire au maximum les calculs à faire permet d'avoir des temps d'executions semblables à un système type MySQL. Avec un très grand nombre d'article je ne sais pas ce que cela donne, théoriquement ça ne devrait pas poser de problème, après faut voir. Mais Pluxml n'a pas été créé pour les "gros blogeurs" car j'imagine bien que ces derniers utilisent des solutions plus completes.
Concernant les CDATA, sachez que l'on ne peut pas complement changer le format des fichiers Xml contenu compte de la compatibilité avec les versions précédentes.
Fait d'autant plus appréciable quand le serveur SQL de l'hébergeur est dans
Pourtant, ce n'est qu'une version bêta (le format n'est donc pas forcément fixé). Le format des fichiers Xml (utf-8 et CDATA) peut être facilement changé avec une petite fonction présente dans un fichier maj.php à exécuter lors de l'upgrade à une version supérieure de Pluxml. On pourrait même faire cela facilement en ajoutant dans le répertoire des Xml un petit fichier version qui contient le numéro de la version de Pluxml ayant généré les commentaires. En cas de mise à jour, la routine de conversion est automatiquement exécutée à la première utilisation.
Pour le utf-8, il faut voir ce qui est faisable en gardant php4.
Par expérience je sais que les petits fichiers "versions" se perdent tout le temps
Pour le format des fichier Xml c'est à discuter, on peut en parler plus en détail ailleurs si tu veux.
Mais bon, il est dommage d'obliger l'utilisation de php5. On pourrait faire un fichier d'index « artisanal » (lu et écrit à la main, ce qui serait de toute façon plus rapide qu'un listage de répertoire avec des milliers de fichiers). En plus, cela permettrait en même temps de gérer un deuxième fichier d'index par date
(facile à faire vu que tout aurait déjà été écrit pour le premier index !)
Il n'y a ÀMHA aucun problème pour faire cela en php4.
Il faut juste placer des utf8_encode() et decode au bon endroit et gérer les htmlspecialchars comme indiqué dans un de mes précédents messages (pour éviter le CDATA).
Et un petit coup d'iconv à ajouter à cause des navigateurs internationaux.
Bah le Xml est un format encodé par défaut en utf-8. Il est mal de vouloir forcer un autre encodage ! Surtout pour un script qui deviendra sans aucun doute international.
Question de facilité de mise a jour apres, parceke la relecture avec tous les accents en braille, merci le mal de crane
Au fait Iulius, qd tu mentionnes : "Il faut juste placer des utf8_encode() et decode au bon endroit " , tu parles de quel endroit ?
Mais je ne suis pas du tout d'accord avec Ilius sur le virage des <![CDATA[ ]]> !
Tiens, prends ce message là : $mess = "Bonjour, j'aime bôcoup la balise de citation que Skyline a implémenté !";
Maintenant htmlspecialchars-là et met là à la main dans un article. (sans CDATA)
Boum ca marche plus