Orpheus, mon framework PHP Open Source

[niahoo]

Mais ton permanent object en gros c'est ActiveRecord en fait ?

---

Moi aussi j'ai fait un framework pour m'amuser, je m'en sers sur des petits projets, il faudra que je te montre ça oxman j'aime bien les commentaires désobligeants moi.

[Myrina]

... pour ne pas paraitre trop désobligeant/méchant

Moi si! :mauvais:

Le pattern MVC est devenu incontournable aujourd'hui dans le développement surtout Web; mais pas que Web, en effet même Microsoft respecte ce pattern avec ces MFC qui servent à développer en C++ des applications pour Windows.

De plus, le minimum pour faire de l'orienté objet, c'est d'instancier des classes donc utiliser la commande new pour manipuler une instance de la classe et non utiliser, via des méthodes statiques, un tableau externe à celle-ci sensé contenir les membres de celles-ci.

Bref, que de très mauvaises pratiques, ce qui devient extrêmement gênant si on propose à des personnes de s'appuyer dessus (c'est le principe même du framework).

Le seul point positif que je trouve ici, c'est que c'est un excellent exemple de ce qu'il ne faut pas faire concernant les framework et la POO.

[niahoo]

concernant l'ORM je trouve qu'au niveau de l'API c'est tout à fait correct :

$tid = DemoTest::create($_POST['data']);

$test = DemoTest::load($tid);

DemoTest::delete($tid);

Avec des surcouches de Redbean (un ORM) j'arrive souvent à ce genre de code.

Seule remarque, je préfère qu'une méthode 'create' me renvoie l'objet plutot que son id.

Avec Redbean:

$demo = R::dispense('demo');

echo $demo->id; // -> 0

R:tore($demo);

echo $demo->id; // -> "42"

[Cartman34]

@ Oxman & Myrina Vous êtes libres, il ne revient qu'à vous d'assumer vos pensées/paroles.
Pour moi, on m'a toujours appris "Quand t'es pas satisfait de ce que font les autres alors fais le toi même" (qui découle du fait qu'on est jamais mieux servi que par soi même).
J'ai fait un framework qui convient à mes besoins et je l'ai partagé avec tout le monde car je ne veux pas garder mon travail que pour moi.
Imparfait soit il, au moins, je peux dire que je l'ai fait.

Myrina, je n'ai pas compris toutes tes remarques, pour le new, tu parlais de quoi ?
Je n'avais aucunement besoin d'un patron MVC complet pour le site de démonstration, hormis pour une partie qui concernera spécifiquement le MVC, l'optimisation est d'utiliser ce qu'on a besoin quand on a besoin, et de suivre ses envies (si on a envie de respecter totalement le patron MVC alors respectons le, il le permet).

@niahoo Merci pour ton intérêt.
Pour ActiveRecord ce n'est qu'une question de termes, il m'est malheureusement impossible de connaître tous les patrons de conception qui existent, surtout qu'à la fac, au cours qui aurait du y consacrer une bonne partie, on en a appris 3... Donc le Singleton... hmmm...
C'est un tort quand c'est sur quoi je travaille mais s'il n'y a personne pour me dire que ce patron existe, je cherche pas tous les modèles possibles que j'utilise pour en trouver un patron. ;-)
Bref, apparemment, tu as raison.

Pour le reste, j'ai appris en même temps le rapprochement avec ORM mais ça ne part de rien, je voulais juste qu'on puisse agir directement sur l'objet.
Pourquoi ça retourne un ID au lieu de l'objet... je me suis posé la question, je n'avais aucun besoin de récupérer l'objet immédiatement, par contre l'ID, c'était fréquent, pour l'utiliser avec d'autres objets notamment, car en base de données, les objets sont liés par l'ID et non... eux-même (même si certains SGBD permettent de manipuler des objets, ce ne sont pas les objets PHP).
Pour conclure, ce choix fut pour des raisons d'optimisation et de besoin.

[srm]

Pour ne parler que de ce choix, je dirais plutôt qu'il a été fait par manque d'expérience.
Si tu retournes l'objet il est simple après de faire $obj->id, et ça te donne bien plus de souplesse pour travailler, car tu peux plus facilement avoir tous les cas d'utilisations. Tandis que toi avec l'id, si tu veux l'objet tu fais quoi ?

De plus, on ne peut pas parler d'optimisation d'avoir $id plutôt qu'avoir à faire $obj->id, car d'un côté l'intérêt niveau optimisation est très minime, par contre tu perds grandement en souplesse d'utilisation.

[Cartman34]

Ha... par manque d'expérience... Tu supposes donc tout savoir et avoir la science infuse...

Pour ma part, je choisis de laisser le choix au développeur de faire selon son besoin, il peut très facilement load() l'objet ensuite comme je l'ai fait.
ça évite d'avoir une requête SELECT qui soit faite systématiquement alors que la très grande majorité du temps, on n'a besoin que de l'ID de l'objet.
De plus, c'est un objet qu'on n'aura pas à créer pour juste ça (un objet de ce type, ça peut être très lourd, selon les attribut de l'entité), je rappelle aussi qu'il faut toutes les données de l'entité pour créer l'objet.

[srm]

Parce que je sais que tu manques d'expérience implique que je sais tout et que j'ai la science infuse ?
Non ça ne n'implique pas.
Exemple : Si quelqu'un dit : "Y am Oxman", tu peux dire que la personne connais pas très bien l'anglais sans pour autant savoir le parler couramment.

Mais je vais te tourner le problème exactement.
A ton avis pourquoi tous les frameworks retourne l'objet et pas l'id ?

[niahoo]

la personne connais pas très bien l'anglais sans pour autant savoir le parler couramment.

ben en même temps ...

Moi je ne sais pas faire du cheval mais ça ne m'empêche pas de ne pas participer à des courses d'équitation, si tu vas par là :p

---

aaaaaaaaaaaaaaah c'est moi l'observateur qui ne sais pas le parler courament.. ok !

(je sors du sport !)

[srm]

Sauf que d'un exemple tu ne peux pas faire une généralité, mais d'un exemple tu peux contrer une généralité.

[Cartman34]

Ce sont les développeurs de chaque framework qui décident pour le leur, ce n'est pas une généralité, il n'y a pas de fait qui dit "ça c'est mieux".

Ils le font pour leur modèle objet, pour eux, il est hors de question de manipuler des IDs.
Mon framework impose des directives et des architectures mais en aucun cas il n'est fait pour dicter comment un développeur doit développer.

De plus, s'il n'y avait aucune différence avec les autres frameworks, Orpheus ne servirait à rien et il ne serait pas davantage optimisé.

Je préférerai nettement des critiques du système de Hooks ou d'update des PermanentObject.
Il y a surement des choses à redire à leur sujet et je ne pense pas avoir de solution parfaite.