Couplage SQL/HTML avec PEAR DataGrid et DataObject

deux avis :

- DB Data Object : beurk!

- Structure Data Grid : wow ! pas mal !

de facon plus construite :
laisser la main pour les requetes a un automatisme (limité en plus) ne
me sied guere, mias en plus, il devient vite plus compliqué que le SQL
pour certaines requetes.
enfin, ne pas controler l'accés aux données que est le socle de la
plupart des applications moderne me semble... a oublier (avis perso)

pour dataGrid : ca m'a l'air pas mal, mais le PB que j'ai avec PEAR est
le suivant :
reutiliser du code c'est bien, mais a moins de se plonger dans les
sources, on ne conanit jamias leur limitation... et se retrouveer
bloquer en plein milieu d'in dev. ca me fait plutot flipper...
donc pour moi PEAR est a oublier... du moins tous les projets se
placant trop "haut" au niveau de l'architecture d'un programme. gérer
sa connexion par PEAR pourquoi pas (mais quelle utilisté c plutot
simple... (dans la plupart des cas)), mias lui confier des taches
complexe qui par nature sont ... complexes... pour moi c'est non, je
prefere perdre du temps masi matriser mon outil... quitte a me créer
mon propre framwork, moins performant mias que je saurait remanier a
souhait...

voila, donc joli ton bijou, mais je prefere ceux artisanaux :) dsl

Salut Bruno,

bruno wrote:

deux avis :

- DB Data Object : beurk!

C'est une question de goût ;-)

- Structure Data Grid : wow ! pas mal !

Merci

de facon plus construite :
laisser la main pour les requetes a un automatisme (limité en plus) ne
me sied guere, mias en plus, il devient vite plus compliqué que le SQL
pour certaines requetes.
enfin, ne pas controler l'accés aux données que est le socle de la
plupart des applications moderne me semble... a oublier (avis perso)

C'est effectivement un bon point. N'empêche qu'il y a bien des applications
"modernes" qui utilise les DataObjects. Tu peux très bien les faire à la main,
d'ailleurs, tes DO. C'est un design pattern en quelque sorte.

Et si tu respecte un minimum l'interface de DB_DataObject (quelques méthodes à
exposer) tu peux brancher ton DO maison dans Structures_DataGrid.

Soit dit en passant, je pense depuis un certain temps à un pilote DataGrid du
type SqlAdaptor(). Il suffirait lui passer un objet respectant une interface
très simple (3/4 methodes se chargeant de récupérer les données, les compter,
etc...).

pour dataGrid : ca m'a l'air pas mal, mais le PB que j'ai avec PEAR est
le suivant :
reutiliser du code c'est bien, mais a moins de se plonger dans les
sources, on ne conanit jamias leur limitation... et se retrouveer
bloquer en plein milieu d'in dev. ca me fait plutot flipper...
donc pour moi PEAR est a oublier... du moins tous les projets se
placant trop "haut" au niveau de l'architecture d'un programme. gérer
sa connexion par PEAR pourquoi pas (mais quelle utilisté c plutot
simple... (dans la plupart des cas)), mias lui confier des taches
complexe qui par nature sont ... complexes... pour moi c'est non, je
prefere perdre du temps masi matriser mon outil... quitte a me créer
mon propre framwork, moins performant mias que je saurait remanier a
souhait...

Ouais, attention cependant à pas donner dans le syndrôme du NIH (Not Invented
Here). Et puis avec des raisonnement comme le tien, le logiciel libre
n'existerait peut-être pas...

voila, donc joli ton bijou, mais je prefere ceux artisanaux :) dsl

Beaucoup de logiciels libres sont artisanaux. Ils sont le fruit de petites
équipes, de contributeurs diverses, qui quand ils se servent d'un outil le
modifient suivant leurs besoins. Concernant PEAR, quand tu connais un peu, tu
modifies ce que tu veux rapide, pour une raison très simple : les PEAR Coding
Standards. Ce sont des règles de codage qui garantissent une certaine uniformité
d'un paquet à l'autre.

--
og

en fait ma reponse vient du fait que j'ai tenu a utiliser DataObject
dans mon projet, sans en conniatre les caracterisitques (et surtout les
limites) et je me suis retrouvé a devoir reprendre mon dev depuis le
debut...

c'est pas plus mal detruire pour mieux construire, mais je n'ai pas eu
cette experience qu'avec DataObject, donc je ne veut pas baser un point
central de mon dev sur quequechose de non maitrisé.
OK, tu peut me dire que pour les quelques petits point
d'incompatibilitée, j'aurais put utuliser des methodes differentes...
mais la lisibilitée n'est pas a oublier.

alors pourquoi j'ai ete chamré par dataGrid? et bien tout simplement,
il ne se place pas a la base de l'architecture du logiciel, au
contraire, il recupere des données pour les presenter, et c'est tout
ce qui fait son charme : il n'est pas incontournable... il est
complementaire... si tu voit ce que je ceut dire.
apres, je ne dit pas qu'il faut toujours oublier ce qui est "alien"
dans le code metier, mias il faut y faire tres attention.

concernat les pear coding standarts, certes, ils sont rigoureux, mais
la logique applicative est differentes de l'un a l'autre quand meme. Je
peut te dire que lorsque je suis allé trifouiller dans le code de data
object, j'ai mis un bout de temps a trouver la faille qui a fait qu'il
etait imcopatible avec mes besoins (je l'ai meme en partie rerecrit
pour essayer d'y palier, mais rien a faire...) et assez complexe a
aprehender, pour moi en tout cas...

voila, je ne suis pas un grand connaisseur, et je me suis brué les
ailes avec PEAR, d'ou mon avis assez dure, peut etre :)

Bonjour,

en fait ma reponse vient du fait que j'ai tenu a utiliser DataObject
dans mon projet, sans en conniatre les caracterisitques (et surtout les
limites) et je me suis retrouvé a devoir reprendre mon dev depuis le
debut...
Normal.

voila, je ne suis pas un grand connaisseur, et je me suis brué les
ailes avec PEAR, d'ou mon avis assez dure, peut etre :)

Je ne suis pas un partisan à tous crins de PEAR, que je prononce "pire",
c'est pas par hasard, car son nom même indique que c'est un fourre tout
dans lequel on trouvera du bon (il y en a) et du mauvais (il y en a
aussi) (R=Repository). Mais que ceci soit bien clair : on ne choisit une
librairie/un framework parce que untel ou untel dit "c'est bien". C'est
"bien" pour **ses** besoins, qui ne sont pas nécessairement les tiens.
Avant de choisir une librairie, on doit nécessairement s'assurer (allez,
parlons consultant) que "son périmètre fonctionnel englobe le scope du
projet" ou dit en langage normal, qu'elle fait tout ce dont tu as
besoin. Ceci est indépendant du langage/de la plateforme avec lequel on
travaille, c'est un éternel problème de gestions des équipes de
développement. Donc la partie de PEAR avec laquelle tu t'es battu est
probablement adaptée aux besoins d'autres projets. Et il y a peut-être
un autre bout de PEAR adapté aux tiens.

a++;
JG

bruno wrote:

en fait ma reponse vient du fait que j'ai tenu a utiliser DataObject
dans mon projet, sans en conniatre les caracterisitques (et surtout les
limites) et je me suis retrouvé a devoir reprendre mon dev depuis le
debut...

J'imagine asse bien la situation. Disons qu'il faut connaître. Mais en terme de
fonctionnalités et de souplesse, DB_DataObject me semble mieux placé que les PDO
de PHP5 par exemple.

alors pourquoi j'ai ete chamré par dataGrid? et bien tout simplement,
il ne se place pas a la base de l'architecture du logiciel, au
contraire, il recupere des données pour les presenter, et c'est tout
ce qui fait son charme : il n'est pas incontournable... il est
complementaire... si tu voit ce que je ceut dire.

Je vois très bien et ça me fait plaisir que tu soulignes ce point. D'ailleurs,
chez PEAR, on rappelle constamment qu'on donne dans les librairie et _pas_ dans
un framework. Il s'agit de faire des _composants_.

Rien ne t'empèche d'utiliser DB_DataObject sporadiquement, de manière
complémentaire à des accès BD conventionnels.

apres, je ne dit pas qu'il faut toujours oublier ce qui est "alien"
dans le code metier, mias il faut y faire tres attention.

C'est clair.

concernat les pear coding standarts, certes, ils sont rigoureux, mais
la logique applicative est differentes de l'un a l'autre quand meme. Je
peut te dire que lorsque je suis allé trifouiller dans le code de data
object, j'ai mis un bout de temps a trouver la faille qui a fait qu'il
etait imcopatible avec mes besoins (je l'ai meme en partie rerecrit
pour essayer d'y palier, mais rien a faire...) et assez complexe a
aprehender, pour moi en tout cas...

Effectivement les pear coding standards, c'est juste pour le style. Mais c'est
déja ça.

Perso j'ai utilisé les DB_DataObject pour ce projet (en production sur
intranet): http://www.samalyse.com/portfolio/mercure

Il s'agit en gros de gérer des factures, etc.... J'ai adapté DB_DataObject avec
un arbre de classe du type :

DB_DataObject
|
Mercure_DataObject
| |
| Mercure_Document
| |
Mercure_Product |-Mercure_Facture
|-Mercure_BonAchat
|-Mercure_BonLivraison
|-etc...

voila, je ne suis pas un grand connaisseur, et je me suis brué les
ailes avec PEAR, d'ou mon avis assez dure, peut etre :)

Mon avis c'est que il faut pas penser PEAR comme un tout. C'est _pas_ un
framework. Tu dois pouvoir piocher les composants qui te plaisent, et laisser le
reste.

Concernant Structures_DataGrid, DB_DataObject c'est juste un des type de sources
de données supportées, il y a aussi : XML, RSS, CSV, DB, DB_Query, DB_Table,
Array, et bientôt PDO.

--
og

John GALLET wrote:

en fait ma reponse vient du fait que j'ai tenu a utiliser DataObject
dans mon projet, sans en conniatre les caracterisitques (et surtout les
limites) et je me suis retrouvé a devoir reprendre mon dev depuis le
debut...

Normal.

Oui, il vaut mieux bien connaître un composant comme DB_DataObject, surtout
lorsqu'on envisage de l'utiliser de manière intensive, et que l'architecture de
l'application en dépend.

Je ne suis pas un partisan à tous crins de PEAR, que je prononce "pire",
c'est pas par hasard, car son nom même indique que c'est un fourre tout
dans lequel on trouvera du bon (il y en a) et du mauvais (il y en a
aussi) (R=Repository). Mais que ceci soit bien clair : on ne choisit une
librairie/un framework parce que untel ou untel dit "c'est bien". C'est
"bien" pour **ses** besoins, qui ne sont pas nécessairement les tiens.
Avant de choisir une librairie, on doit nécessairement s'assurer (allez,
parlons consultant) que "son périmètre fonctionnel englobe le scope du
projet" ou dit en langage normal, qu'elle fait tout ce dont tu as
besoin. Ceci est indépendant du langage/de la plateforme avec lequel on
travaille, c'est un éternel problème de gestions des équipes de
développement. Donc la partie de PEAR avec laquelle tu t'es battu est
probablement adaptée aux besoins d'autres projets. Et il y a peut-être
un autre bout de PEAR adapté aux tiens.

C'est juste. Mais à mon avis, si beaucoup de logiciels libres sont aujourd'hui
aussi puissant et stables, c'est très certainement parce que des équipes les ont
utilisés en production (et pas juste pour faire joujou). A un moment ça a
bloqué, il y avait un bug/limitation. De là : modification _indispensable_ de la
librairie ou de l'application concernée, puis contribution (de qualité).

Ton raisonemment (nottament: "englobe le scope") est très adapté au librairies
propriétaires, mais avec le logiciel libre, il me semble qu'on peut prendre plus
de risques : on a la source, et on a le droit de la modifier.

C'est une compétence particulière, savoir modifier, c'est pas comme partir de
zéro. Et dans le logiciel libre, je dirais que c'est une forme de culture.

--
og