Geckozone

Merci pour la remarque Do-IT, Mais l'inconvenient, c'est que quand on habite la campagne reculée,on n'a pas toujours l'ADSL... Et actuellement, je ne suis pas très patient. Et ne connaissant rien de rien à Php, easyphp va m'obliger à essayer de comprendre

même si c'est disproportionné. Je suis plus patient pour apprendre quelque chose de nouveau que pour attendre qu'une page se charge ou s'affiche en 46 kb/sec!

Do-IT a écrit :S'installer un serveur sur son pc, pour previsualiser ces include, c'est un peu disproportionné.

C'est net ! Mais ça a des avantages :

le site en ligne est moins longtemps "en travaux" ;
on peut faire les pires bourdes sur son site local, on peut toujours le restaurer à partir du site en ligne ;
c'est beaucoup plus réactif qu'un hébergeur gratuit, même avec l'ADSL : on teste une modif, [Ctrl+S] [F5] et on voit le résultat ;
ça permet d'apprendre à configurer un serveur LAMP sans risque (et sans quitter Windows).

C'est le débat synchronisation / enregistrement simultané...

Installaton de easyphp sans problème qui me montre que les include marchent bien

Je viens de trouver le moyen d'ajouter un en-tête PHP avant le DOCTYPE dans l'affichage "source" de Nvu.
Idem pour éditer un fragment HTML : il est possible de faire en sorte que l'affichage "source" ne montre que le fragment, sans les DOCTYPE, <html>, <head> et <body>.
Il est même possible de conserver l'indentation de Tidy dans l'affichage "source"...

Du coup, les fichiers temporaires deviennent inutiles, et SciTE devient facultatif ; je pense que c'est une bien meilleure façon d'adapter Nvu aux sites qui utilisent le PHP. J'implémenterai tout ça dans la version 0.4.0.

D'ici là, il y aura probablement une ou deux versions 0.3.x avec quelques petites modifications. Notamment, je voudrais mettre en ligne une version de HandCoder qui permette d'inclure des menus en PHP sans passer par un éditeur texte, conformément au post-it d'Ymai.

Du coup ca va bouleverser ton pack Xmas.
En plus j'ai pas fini de m'arracher les cheveux avec la config de scite.
Pouvoir editer du php et du html (je le fais deja) dans l'onglet source, le tout avec l'indentation de tidy, c'est que du bonheur. Je t'avais demandé ca il y a pas longtemps, c'est toujours payant ?

Et le cas du code considéré pourri ?

Do-IT a écrit :Du coup ca va bouleverser ton pack Xmas.
En plus j'ai pas fini de m'arracher les cheveux avec la config de scite.

Non, ça risque d'être trop juste pour figurer dans le Xmas pack.
L'intérêt de ce pack c'est justement que je me prenne la tête sur la configuration de SciTE à ta place !

Do-IT a écrit :Pouvoir editer du php et du html (je le fais deja) dans l'onglet source, le tout avec l'indentation de tidy, c'est que du bonheur. Je t'avais demandé ca il y a pas longtemps, c'est toujours payant ?

Ah ça c'est une bonne idée ! 10, ça t'irait ?

De mémoire, ce que tu souhaitais (et que j'aimerais avoir pour mon usage personnel), c'est d'avoir Scintilla (le coeur de SciTE) comme affichage "Source". J'ai toujours ça en projet comme extension payante, car ça permettrait un tas de choses que l'éditeur de Nvu ne permet pas (auto-complétion, pliage de code, aide dynamique, etc).

Pour être tout-à-fait franc, c'est le Xmas pack que je mettrais volontiers en shareware à la rentrée... si ça pouvait me permettre de bosser sur Nvu à temps plein, et de ne faire que des extensions open-source, c'est sûr que ça me plairait !!!

Do-IT a écrit :Et le cas du code considéré pourri ?

Je ne sais plus si je l'ai déjà écrit... Si tu parles du code du type

Code : Tout sélectionner

<body <?php if ($test) echo "onLoad='init();'" ?>>

il y aurait une solution, en utilisant un attribut bidon le temps d'éditer avec Nvu, du genre :

Code : Tout sélectionner

<body null="<?php if ($test) echo "onLoad='init();'" ?>">

puis en remettant le code d'aplomb lors de la sauvegarde (ou pour l'éditer en mode "source").

J'avoue que ce genre de code est très pratique, notamment pour ajouter un attribut à la volée dans un menu (pour désigner l'item actif) ; je suis donc un peu plus motivé pour l'implémenter.
Le gros problème, c'est que c'est très gourmand en ressources, surtout sur des grosse pages. Il va probablement falloir que je fasse ça en C++ pour que ça soit acceptable.

Un New-Year pack alors, en shareware. Pourquoi pas. Faudra encore un peu tester, avec les fêtes ca va etre chaud. Puis les tests d'extensions sous l'influence de l'alcool, je l'ai deja dit, je vous laisse ca à toi et à chinon37.

Do-IT a écrit :Puis les tests d'extensions sous l'influence de l'alcool, je l'ai deja dit, je vous laisse ca à toi et à chinon37.

pas de probléme, je fournis les munitions

Sans alcool, le test d'extensions c'est d'un ennui...
C'est les fêtes ou bien ??? (avec l'accent dauphinois)

Je file, c'est l'heure du digestif.

Code detruit

Code : Tout sélectionner

<img src="image.php?code=<?php print $date; ?>" align="middle" />
<img <?php print "src=\"image.php?code=$date\""; ?> align="middle" />
<img src="<?php print "image.php?code=$date"; ?>" align="middle" />
<input <?php print "value=\"$date\""; ?> type="hidden" />
<input value="<?php print "date=$date; ?>" type="hidden" />

Code non detruit

Code : Tout sélectionner

<img src="<?php print 'image.php?code='.$date; ?>" align="middle" />
<input value="<?php print $date; ?>" type="hidden" />

Donc pour mettre du php dans une valeur il faut pas melanger valeur+php, ni mettre de " dans le php
ou alors il faut carrement faire

Code : Tout sélectionner

<?php print '<img src="image.php?code='.$date.'" align="middle" />' ?>

Par défaut, Nvu 1.0 reformatte tous les attributs, sauf ceux qui commencent par <?php (les caractères spéciaux sont échappés). Daniel a rajouté une préférence "ne pas encoder les caractères spéciaux dans les attributs", mais je ne comprends pas toujours comment elle fonctionne...

Sur mon poste windaube, seuls les codes suivants sont détruits :

Code : Tout sélectionner

<img <?php print "src="image.php?code=$date""; ?> align="middle" />
<input <?php print "value="$date""; ?> type="hidden" />
<input <?php print "value="$date""; ?> type="hidden" />

mais c'est encore le vieux problème de l'attribut nul (le code PHP doit être inclus dans un élément ou un attribut HTML, mais pas comme ça).

Do-IT a écrit :Donc pour mettre du php dans une valeur il faut pas melanger valeur+php

Je ne constate pas ça sur mon poste windaube ; les codes suivants sont conservés :

Code : Tout sélectionner

<img src="image.php?code=<?php print $date; ?>" align="middle" />
<img src="<?php print "image.php?code=$date"; ?>" align="middle" />

As-tu coché la préférence "ne pas encoder les caractères spéciaux dans les attributs" (paramètres avancés de Nvu) ?
Et dans ces préférences, quels caractères sont encodés comme des entités ?

Do-IT a écrit :ni mettre de " dans le php

C'est un problème un peu plus épineux, car Tidy ajoute des transformations...
Si l'attribut contient des guillemets ("), Nvu l'encode entre des apostrophes, et Tidy s'en débrouille bien (encore que ça dépende des versions de Tidy).
Mais si l'attribut contient des guillemets et des apostropes, alors Nvu échappe tous les caractères spéciaux, y compris les < et > qui délimitent le code PHP !

Pour moi le vrai problème c'est les guillemets dans le code PHP ; ça me gène particulièrement pour implémenter le hack de l'attribut nul. Le pire, c'est que là je suis en train d'implémenter Tidy sous forme de DLL, et la version de TidyLib que j'utilise fonctionne mal sur ces types de code...

J'ai perdu pas mal de lignes de code HTML en faisant ces tests !

Je suis donc convaincu qu'il y a un gros problème avec ces histoires de guillemets, mais j'ai du mal à le cerner précisément, et je n'ai pas de solution pour l'instant. Je crois qu'il va falloir que je fasse une version de TidyLib spécifique à Nvu, ça sera plus performant et plus sûr.

Config des tests ci dessu:

Caractères spéciaux
- Définir les caractères suivants en tant qu'entités : Uniquement & < > ' et les esp...
- (cocher) N'encode pas > sauf dans les val...
- (cocher) N'encode pas les caracteres speciaux dans les val...

Comme tu as pu le remarquer les fichiers sont en xhtml... Je referai des tests et te mettrait le code detruit. Mais j'ai quand meme trouver deux ecritures non detruite, suffit de s'adapter.

J'ai mis tidy en : avant edition avec le bouton editeur, pour deux raisons. Parcequ'il n'y a pas (plus) de bouton Tidy (Oui les menus c'est trop long et les touches trop loins). Et que comme ca je suis sur d'avoir tout de suite un code indenté et eventuellement detruit, ce qui evite les surprises ulterieures.

Toute ces peines (pour toi et tes testeurs) en attendant un onglet source editable et indenté. Je crois que je ne vais pas regretter scite si tu nous fais ce miracle.

Do-IT a écrit :Caractères spéciaux
- Définir les caractères suivants en tant qu'entités : Uniquement & < > ' et les esp...
- (cocher) N'encode pas > sauf dans les val...
- (cocher) N'encode pas les caracteres speciaux dans les val...
Comme tu as pu le remarquer les fichiers sont en xhtml...

Bizarre, j'ai exactement les mêmes options. La vérité est ailleurs.

Do-IT a écrit :J'ai mis tidy en : avant edition avec le bouton editeur, pour deux raisons. Parcequ'il n'y a pas (plus) de bouton Tidy (Oui les menus c'est trop long et les touches trop loins). Et que comme ca je suis sur d'avoir tout de suite un code indenté et eventuellement detruit, ce qui evite les surprises ulterieures.

Pareil. Je vais voir s'il y a moyen de lancer Tidy avec un "middle-click" (molette) sur le bouton "Editeur".

Do-IT a écrit :Toute ces peines (pour toi et tes testeurs) en attendant un onglet source editable et indenté. Je crois que je ne vais pas regretter scite si tu nous fais ce miracle.

Je ne vais pas renier mon éditeur fétiche, mais j'avoue que c'est pratique d'éditer son code directement dans l'onglet "Source".
Ma version de travail fonctionne assez correctement, il n'y a plus qu'à trouver comment garder l'indentation de Tidy... et à supprimer tous ces fichiers temporaires qui pourrissent les performances.

Après quelques heures de trop passées sur le support ASP/JSP/PHP, j'en suis arrivé à la conclusion qu'il fallait que je le refasse... encore.
La détection basée sur le DOCTYPE est une bonne idée, mais il faut encore implémenter une vraie détection de tous les scripts PHP (y compris ceux qui sont en "attribut nul"), et qui ne dépende pas du nombre de guillemets !

L'autre conclusion, c'est que les fichiers temporaires sont une véritable plaie.
En utilisant une librairie dynamique (DLL) de Tidy plutôt qu'un exécutable, non seulement les performances sont bien meilleures, mais ça permet surtout d'appeler Tidy sur n'importe quel bout de HTML, proprement et simplement (sans fichiers temporaires), et donc de faire ce genre de choses :

A terme ça devrait permettre de revoir quasi-totalement la façon dont Nvu interprète et génère le code source, et ainsi de mieux supporter les balises ASP/JSP/PHP.

Je vais tâcher de poster demain une 0.3.1 qui utilise Tidy sous forme de DLL... et qui devrait fonctionner sous MacOS X (enfin !).

Chouette. Ca tombe bien demain c'est mon anniversaire ! Comment tu savais ?
Mais ca va etre chaud, comme j'avais deja dit, pour tester tout ca avant janvier. Hips... Une bouteille ca va, trois bouteilles (de schnaps) bonjour les tests.

Geckozone

HandCoder : extension Nvu pour Tidy et PHP