Geckozone

lerouxjul a écrit :En effet, on ne peut pas se pleindre que la vérification et la constatation d'un fichier php pourri entraine sa non ouverture.
Pas contre si on ne le sait pas, on croit a un bug..il serait agréable d'avor un msg nous indiquant que le fichier php est corrompu...

En effet. D'ailleurs, Do-IT l'a déjà suggéré, c'est un signe !

lerouxjul a écrit :Pourrait tu me dire si pour éditer du code php comme je le fais j'ai plus interet a instaler Handcoder ou nsmcontext?

HandCoder.
Surveille ce sujet, je fais pas mal de betas en ce moment... et tu pourras participer au débug.

Le support PHP de NsmConText est moins avancé. La prochaine version de NsmConText ne disposera d'aucune fonctionnalité relative à PHP ou Tidy, mais sera compatible avec HandCoder.

lerouxjul a écrit :Bravo pour ton travail en tout cas, c'est remarquable...

Merci

J'ai testé handcoder marche nickel avec des fichiers php au code "propre"...

Il serait vraiment bien dans un futur plus ou moins proche de pouvoir trouver nvu 1.1 avec Handcoder intégré de maniére transparent dans nvu...

Je testerai les prochaines beta, si mon maigre avis peut aider au développement...
Joli travail et bonne continuation.

Kaze a écrit :ça n'est pas du code pourri (Nvu sait très bien l'éditer).

Oui, j'ai juste repris ta definition. Dans ma proposition de detection No5 je proposais de forcer l'editeur externe pour les fichiers qui contienent une 'pseudo-instruction' dans une balise html meme si nvu arrive a s'en accomoder. ( < ... < n'etait qu'une tentative de simplification extreme, pourquoi n'est-ce pas fiable ?)
En cas de doute et de risque de destruction vaut mieux etre prudent.

Il faut un savant melange de detection et de marquage humain. Une detection simple (Ai-je le droit de faire une Lapalissade : Plus la detection sera simple, moins elle sera compliquée). Un marquage par extension, dans options. Et un marquage dans les fichiers (a partir de la fenetre 'open with', case se souvenir du choix pour ce fichier) a defaut d'un marquage dans les parametres utilisateurs.

Ce qui nous donne pour l'ouverture d'un fichier :

Lecture du marquage dans le fichier, puis action en consequence.
sinon action en fonction de l'extension,
sinon, Detection puis action:
1)html pur: nvu
2)squelette: open with (2 cases se souvenir du fichier/de l'extension)
3)frag code: editeur
4)frag html: open with (1 seule case se souvenir de l'extension) (a moins que tu marques sous la forme de commentaire html)
5)pourri: open with (Message : Votre code risque d'etre mal interpreté par nvu, 2 cases se souvenir du fichier/de l'extension)

Dans les options, seulement deux zones de texte :
- extensions de fichiers à toujours ouvrir avec Nvu
- extensions de fichiers à toujours ouvrir avec l'éditeur

Do-IT a écrit : je m'y connais pas en template, ni joomla, ni autre. Alors je peux pas donner mon opinion. (j'ai bien réussi a installé typo3 sous mandrake et je l'ai testé pendant 3 mois avec le club de foot, puis quand je compris la complexité du template j'ai abandonné. Prochain essai Spip).

Juste un petit détail, désolé pour le HS avec Handcoder, je te déconseille SPIP par rapport aux progrés extraordianaires de mambo (Maintenant renomé Joomla) effectués ces derniers temps.
J'ai essayé tous les plus gros CMS (Tous, c'est impossible car il y en a des miliers) et je rejoins l'avis de kaze sur le CMS mambo.
Si l'on veut aller plus loin que le simple Blog avec plug in, c'est Joomla qu'il faut que tu essaye. Tu verra, ça n'a rien a voir avec le reste. Interface admin remarquable et simplicime, concept plug-in de module,bot & composant (c'est les 3 types de plus in pour joomla) vraiment génial.
Bref, il offre un pannel de possibilité inimaginable, une quantité de plug in dont tu n'aura même pas idée..bref tout ce que tu voudras faire, tu pourra le faire sous Joomla...
Surtout que la version Définitive 1.1 de JOOMLA qui doit pas tarder a sortir va encore tout déchirrer...(on est a la 1.03 la)
A bon entendeur et dslé pour le HS...

Enfin une nouvelle beta : HandCoder-20051120-fr

La réécriture de la détection m'a donné pas mal de boulot. La détection est désormais basée sur le DOCTYPE (cf. précédents posts) ; elle permet un découpage plus fiable des fichiers, mais détectera moins bien les fichiers "pourris" (ex: pages contenant plusieurs balises <html> ou <head>).
Attention, il faut maintenant aller dans la fenêtre d'options pour activer la détection ASP/JSP/PHP. Une fois activée, la fenêtre "Open with" affiche en titre le type de fichier détecté : Code template, Code fragment, HTML fragment.

Do-IT a écrit :Ce qui nous donne pour l'ouverture d'un fichier :

Lecture du marquage dans le fichier, puis action en consequence.
sinon action en fonction de l'extension,
sinon, Detection puis action[...]

Je n'ai pas encore implémenté le marquage des fichiers "éditables" avec Nvu, mais je suis dessus.
Par contre, pour les extensions de fichier, j'ai acquis quelques doutes sur le bien fondé de cette idée :

le filtre par extension de fichiers est déjà inclus dans NsmConText, il suffirait que je le rende paramétrable ;
si un utilisateur clique sur "Ouvrir" et sélectionne un fichier PHP, on peut légitimement supposer qu'il veut l'ouvrir avec Nvu, non ?

En attendant, j'ai mis trois cases à cocher dans les préférences, pour lancer Nvu sur les code templates / code fragments / HTML fragments.

Nota: conformément à ce qui a été demandé par Do-IT, tout fichier (même HTML) contenant du code ASP/JSP/PHP est désormais considéré comme un squelette (code template). La fenêtre "Open with" apparait donc plus souvent qu'avant... de quoi me motiver pour implémenter le marquage des fichiers.

Bonus: j'ai ajouté une fonctionnalité pour transformer toutes les URLs locales (file:///) en URLs relatives ; la phase suivante sera de proposer un onglet "Source" dans CaScadeS...

PS: il reste un bug, à savoir que les scripts PHP qui contiennent un "?" ne seront pas "désindentés" par Tidy. Il n'y a pas vraiment de moyen simple de contourner ce bug ; je pense que je vais plutôt patcher Tidy pour qu'il traite les scripts ASP/JSP/PHP comme les balises <pre>.

HandCoder-20051120-fr

Ca m'a l'air bon (pour les temp php, frag php, frag htm).
Pour le code pourri les tests dependent beaucoup des erreurs humaines. (un frag html ex: ><h1>test</h1> ) donne type inconnu. Donc on se limite au code non-pourri ?
Pourquoi pouvoir desactiver la detection ? (le message d'alerte va vite devenir agaçant). (Et plus moyen d'ouvrir un fichier css sans la detection).

Logiquement il faudrait tout précocher, detection + les 3 types. Puis a l'usage, décocher les types qu'on veut definitivement éditer avec nvu (surtout les frag html ?). (Le futur marquage devant accelerer l'action)

------------------------

Hors sujet CMS
Merci Kaze et Jul. Je testerai donc Joomla (la version 1.1 a le temps de sortir). En fait j'ai deja edité un temp dotclear, testé a titre perso (mais je vais attendre la version 2 pour m'y mettre serieusement). Mes besoins cms c'est pour le boulot, 200 pages 20 redacteurs 2000 lecteurs intranet (avec une liste des utilisateurs dans un ldap).

Do-IT a écrit :(un frag html ex: ><h1>test</h1> ) donne type inconnu. Donc on se limite au code non-pourri ?

Dans les vérifications du code "non-pourri", je vérifie que le fichier ou fragment commence par "<" et finit par ">" (ça élimine les scripts shell, les fichiers texte, image et autres)...
Dans le doute, je préfère lancer l'éditeur texte. Un fichier mal formé serait de toutes façons dégradé par Nvu.

Do-IT a écrit :Pourquoi pouvoir desactiver la detection ?

Pour plusieurs raisons :

meilleures performances pour ceux qui n'utilisent pas PHP (risques accrus pour les autres !)
pour pouvoir tester rapidement si le fichier s'ouvre sans HandCoder
pour proposer une release stable (sans PHP donc)

Do-IT a écrit :Et plus moyen d'ouvrir un fichier css sans la detection.

Non, effectivement (c'est le fonctionnement normal de Nvu)... à moins d'avoir NsmConText

J'essaye de distinguer les fonctionnalités qui sont relatives à la page courante (=> HandCoder) de celles qui sont relatives aux fichiers externes (=> NsmConText).

Do-IT a écrit :le message d'alerte va vite devenir agaçant

Je confirme !

Ca va dans le bon sens : par défaut, on n'ouvre pas directement un fichier PHP avec Nvu.
Et ça motive bien pour implémenter le marquage des fichiers...

Kaze a écrit :je vérifie que le fichier ou fragment commence par "<" et finit par ">" (ça élimine les scripts shell, les fichiers texte, image et autres)...

Un frag peu commencer ou finir par du texte. (je sais c'est chiant, on en revient aux extensions)

Do-IT a écrit :Un frag peu commencer ou finir par du texte. (je sais c'est chiant, on en revient aux extensions)

ah oui, c'est vrai ça...

Je n'ai jamais ce cas, mon texte étant toujours dans une balise "bloc" (<div>, <p> ou autre).
Et un fragment de code PHP commence nécessairement par "<?"...

Du coup ça remet effectivement sur le tapis la question des extensions de fichiers

Ou alors, il faut assouplir la détection de "code pourri".
Je pourrais botter en touche en disant qu'on peut toujours inclure le texte dans une balise bloc...
Je cogiterai la question ; je préfèrerais laisser la question des extensions de fichier à NsmConText qui est clairement codé pour ça.

Rien à voir, mais as-tu pu tester le coup des URLs relatives, notamment dans CaScadeS avec les feuilles de style externes ?

PS: pour le coup du code du type

Code : Tout sélectionner

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

une solution serait de transformer (lors de la détection) ce genre d'inclusion en :

Code : Tout sélectionner

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

et de rétablir le code d'origine lors de la sauvegarde. Resterait à trouver un bon algorithme de détection de ce genre de code...

J'ai pas encore testé les url, mais j'en fait deja la publicité.
Ok pour les extensions, c'est pas necessaire dans handcoder. (je disais ca pour enfoncer le couteau).
Mais un fragment reste un fragment. Théoriquement je voie bien un fichier.htm sans aucune balise html, uniquement avec du texte.
Dans la pratique (la mienne surtout), les fragments php ne contiennent que du php, donc commencent par < et finissent par >. J'ai aussi des pages 100% en php, qui ne genere aucun html. Ce ne sont pas des fragments mais seront considérer comme des fragments (ce qui n'est pas grave).
Pour le texte brut en debut et fin de fragment, humm, faudra bien en tenir compte. Ca doit etre moins compliqué que le php dans une balise ?

Kazé, ôtes moi d'un doute... L'installation de handcoder plante lamentablement nsmcontext, non?
C'est ce qui m'arrive. Désinstallation de Handcoder et miracle, nsmcontext re-fonctionne!!!
Le sujet a sans doute été évoqué, mais je n'ai pas suivi et je n'ai pas le courage de me "taper" 84 messages (et puis la redondance est à la base de l'enseignement

Chez moi l'installation des deux extensions. nsm 0.25-fr puis hancoder 1120
les options nsm sont accessiblent uniquement a partir de la fenetre extension, nsm semble fonctionner correctement.
Les options de handcoder sont accessiblent mais je peux parametrer ce que je veux, il ouvre toujours mes fichier php avec l'editeur externe de nsm.

Je t'ai oté le doute ? Moi j'ai suivi mais comme j'ai la memoire qui flanche, j'ai pas non plus le courage là. Ce soir peut-etre.

Ben j'ai toujours le doute, je m'explique:
nsmc...0.2.5 fonctionne depuis sa sortie sur Nvu.Ce matin, j'ai installé handcoder. Aussitôt, je n'ai plus eu accés à nsmcontext. un clic sur l'icone source et c'est le vide sidéral. un clic sur la p'tite flèche déroulante du même icone me donne un liste vide.
un clic sur le nsmcontext du menu outils n'apporte aucune réaction de l'ordi (nouveau vide sidérant).
Après désinstallation de handc..., tout redevient normal: les # éditeurs sont de nouveau affichés après clic sur la flèche de l'icone code source, un clic sur ce même icone me lance automatiquement Scite, je peux paramètrer nsm par le menu outils

nsmcontext.
Donc, je doute...

nsmcontext:version 0.2.5
handcoder: version 20051111b

chinon37 a écrit :Kazé, ôtes moi d'un doute... L'installation de handcoder plante lamentablement nsmcontext, non?

Je confirme

La cohabitation des deux extensions (NsmConText 0.2.5 et HandCoder beta) est complètement hasardeuse. Ma version de travail de NsmConText (0.3) cohabite plus intelligemment avec HandCoder, il faudrait que je poste une beta...

chinon37 a écrit :Le sujet a sans doute été évoqué, mais je n'ai pas suivi et je n'ai pas le courage de me "taper" 84 messages (et puis la redondance est à la base de l'enseignement

Le sujet à déjà été évoqué dans les deux sujets, mais je te laisse chercher où (la lecture est à la base de la sagesse).

Kaze a écrit :Le sujet à déjà été évoqué dans les deux sujets, mais je te laisse chercher où (la lecture est à la base de la sagesse)

Autant pour moi, désolé...

Kaze a écrit :Je confirme

Merci, je ne doute plus... je surveillerais l'avancement des travaux des 2 extensions d'un oeil attentif avant de réinstaller handcoder. Mais Nsmcontext fait déjà un super boulot...

Geckozone

HandCoder : extension Nvu pour Tidy et PHP