bonjour à tous,
j'ai un pti souci avec les déclarations protected ou private dans mes classes php.

version:PHP 5.2.0-8+etch7 (cli) (built: Jul 2 2007 20:43:26)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2006 Zend Technologies

je déclare comme ceci :

class maclasse{
	
	protected $toto;
	protected $tutu;
	protected $titi;
(...)
}

Alors il se trouve que la classe fonctionne normalement, les attributs ne sont disponibles pour une classe extérieure que via les getter/setter, donc ça va.
Le problème, c'est que jedit me les souligne, avec l'infobulle qui compose le titre de ce post. C'est agaçant et ça m'interpelle.
Vous avez une idée de ce que je dois faire ? si c'est un warning php ? si c'est un problème avec le parser php de jedit peut-être, qui comprendrait pas php5 ?

ps: n'est ce pas aussi comme ça qu'on déclare des champs protected en php4 ?

zut c'est encore moi, j'ai oublié de me connecter pour poster

Y'a pas de modifier de champs en PHP4, donc au pire si jedit ne sait parser que du PHP4 change d'éditeur.
Regarde ce post-it, si tu veux connaitre l'avis des forumeurs sur leurs environnements de dev.
a+

merci pour le lien ...
cependant, ça parle beaucoup trop d'éditeur pour windows. J'ai rapidement lu en diagonal, fait une recherche sur linux dans les 5 pages, aucun résultat: ça doit pas être pour moi
Merci quand même, pour l'instant je reste avec jedit, qui est somme toute assez fabuleux.

je vois pas d'où peux venir ce problème. Tu confirme que c'est correctement implémenté et que ce soulignement sur les champs que j'ai, ne peux pas être la conséquence d'erreur d'implémentation plus loin, lors des déclarations de fonctions, par exemple ? (que ça n'a rien à voir ?).

je vois pas d'où peux venir ce problème. Tu confirme que c'est correctement implémenté et que ce soulignement sur les champs que j'ai, ne peux pas être la conséquence d'erreur d'implémentation plus loin, lors des déclarations de fonctions, par exemple ? (que ça n'a rien à voir ?).

Tu as essayé ?

Sous linux, kate est un édteur vraiment pas mal, en particulier grâce à certains plugins (et kdevelop qui utilise les mêmes librairies doit avoir les mêmes qualités, quoique je ne l'ai pas testé pour du web).

D'une manière générale il faut bien comprendre que les indications fournies par ton environnement de développement ne sont que des indications, et peuvent tout à fait être fausses dans certains cas (configurations particulières notamment, ou bugs divers...).

essayé comment || quoi ?
disons que la classe, ses méthodes, fonctionnent correctement.
je rechigne un peu à installer kate pour faire une comparaison, parce que j'ai plutot un environnement xfce4, et puis ça va m'installer 20 pkg au moins ...

Le code de ma classe est une ébauche, je pourrais peut-être le mettre ici, ça me permettrait d'en venir à mon questionnement essentiel :
ne suis-je pas en train de casser la sécurité de PDO en implémentant une classe qui a un membre object PDO et dont les méthodes se spécialisent dans les requêtes propres à ma DB... je voudrais pas faire des failles là où il n'y en a pas

100 lignes on peut mettre en code ici ?

essayé comment || quoi ?
disons que la classe, ses méthodes, fonctionnent correctement.

No problemo donc

je rechigne un peu à installer kate pour faire une comparaison, parce que j'ai plutot un environnement xfce4, et puis ça va m'installer 20 pkg au moins ...

Pour te donner des éléments, kate n'est qu'un éditeur de code (mais très complet dans sa catégorie). Ce n'est pas un environnement de développement, il ne donne donc pas d'indications de ce genre, ne fait pas d'autocomplétion de variables, etc... C'est pour ça que je t'orienterai plutôt vers kdevelop si tu préfères les EDI (dans la même famille). Et si tu ne souhaites pas installer d'application KDE, Eclipse est peut-être ce qu'il te faut.

Sinon, peut-être que certaines options de configuration de jEdit peuvent t'aider à obtenir des indications plus adaptées à ta configuration, mais ne l'utilisant pas moi-même je ne peux pas te l'affirmer.

Le code de ma classe est une ébauche, je pourrais peut-être le mettre ici, ça me permettrait d'en venir à mon questionnement essentiel :
ne suis-je pas en train de casser la sécurité de PDO en implémentant une classe qui a un membre object PDO et dont les méthodes se spécialisent dans les requêtes propres à ma DB... je voudrais pas faire des failles là où il n'y en a pas

Tout dépend comment tu utilises PDO au sein de ta classe. Tant que tu t'astreins à utiliser les requêtes préparées, il n'y a aucun souci à se faire (quelle que soit la structure du code que tu utilises en amont), puisque l'échappement des données entrantes est réalisé de manière automatique.

merci ...

Tout dépend comment tu utilises PDO au sein de ta classe. Tant que tu t'astreins à utiliser les requêtes préparées, il n'y a aucun souci à se faire (quelle que soit la structure du code que tu utilises en amont), puisque l'échappement des données entrantes est réalisé de manière automatique.

C'est à dire que je débute plus ou moins en php, aillant des notions de POO, j'avance relativement vite, et je risque de faire des trucs qui me dépassent en fait.
Ce qui m'étonne, (c'est sans doute que je ne suis pas informé des méthodes d'injection et autres failles), c'est que l'objet de ma classe, si il est corrumpu/intercepté, qu'on peut y avoir accès, on a accès aussi au PDO, et on peut faire des requêtes du coup.
À titre indicatif : Tout ça je comprend pas bien ...

Autre question que je me pose, c'est quand je crée un PDO avec un attribut de connection persistante, pour toute la durée de la session de l'utilisateur :
- est ce que c'est toujours le même objet PDO (de connection à mysql) ou pour chaque session un autre ?
- est ce que je peux utiliser un seul PDO pour tout le monde ?
- dans ce cas, est-ce que je peux le ranger dans une variable $_SERVER ?
- est -ce que les variables $_SERVER sont en tous points inaccessibles à un utilisateur malveillants ?
Je crains que $_SERVER soit en corrélation avec $_SESSION, un tableau par utilisateur ...
N'y a t'il pas un moyen d'avoir une seule connection à la DB, toujours en cours ?
et si oui, quels problemes ça pose ?

hum ... hum ... (me suis laché là).

Ben voyons, c'est simple...
Le PHPParser de jEdit, pour une raison ou une autre, a une option pour activer/déactiver le support pour PHP5. Il n'y a qu'aller changer les options du plug-in PHPParser, et voilà, plus d'"erreur".

en fait, ça suffit de choisir 'php 5 support' en Plugins->Plugin Options -> PHP Parser.