Et, là, l'éléphant dit : « Ne t'inquiète pas, j'ai retiré la table ! »

Question de noob : c'est quoi l'intérêt de faire une couche d'abstraction de base de données? (...c'est une vrai question, hein. :) Si tout le monde l'utilise, je suppose que c'est pour une bonne raison, mais perso je ne l'ai jamais comprise... Remplacer ce bon vieux SQL par une nouvelle syntaxe à chaque framework, j'ai du mal à voir l'intérêt...)

Tiens j'ai la même question pour Twig. On sait déjà très bien séparer les templates sans avoir besoin d'un "moteur" de templates. (Oui je sais ça ne répond pas à ta question --> [])

Moi perso j'ai tendance à écrire ma petite classe Data ou DBAccess (enfin un truc du genre quoi ^^) pour chacun de mes programmes qui s'occupe des initialisations de connexion, de transaction, des singleQuery, execQuery, etc... Comme ça tu la fais une fois pour toute et tu n'as plus qu'à l'appeler partout...

En général, pour effectuer ses requêtes en respectant les paradigmes du langage utilisé.
Exemple pour le couple Java/Hibernate, tu n'as (quasiment) plus besoin d'écrire les requêtes à la main, tu peux les décomposer en Spécifiations et objets liés les uns aux autres.

Ca rend le programme plus modulaire et maintenable, et ajoute aussi sans doute quelques bonus exotiques en background dont je n'ai pas idée. Cela revient à passer du mode manuel au mode industriel en quelque sorte.

Enorme :D
Tout à fait mon sentiment à la lecture de la chute de ce PEBKAC.

Deuxième lecture : faut-il y voir un message sensé avec l'éléPHPant et les tables SQL ? Le doute m'habite.

La couche d'abstraction, ça permet essentiellement de ne pas écrire les requêtes "à la main" : on dit le type de requête qu'on veut faire (insert, update, select), les paramètres utilisés (à insérer, le where, le from, ...), les jointures, bref tout ce qui est utile. Le système d'abstraction génère alors la requête qui va bien et te retourne les infos utiles (le recordset, le lastid, le nombre de lignes impactées).
Ca a deux avantages:
- le système d'abstraction (la plupart du temps) protège la requête (ça permet de lutter contre les injections),
- c'est facilement portable d'un SGBD à un autre. La couche d'abstraction est toujours utilisée de la même manière et te ressort toujours les mêmes types de données.

Captain Obvious à la rescousse?

Très clair comme explication, merci. :)

L'ElePHPant n'aime pas les frameworks et les couches d'abstractions.

Tu pourrais creuser davantage ton point de vue ? Je ne suis pas forcément en contradiction mais j'aimerais bien connaître les raisons qui te font dire ça (c'est une vraie question hein, c'est pas un sarcasme)

heu ici c'est le pebkac français, pour le chinois c'est à côté! :/

Disons que je (pardon, l'ElePHPant) préfère construire moi-même mon environnement PHP, adapté à chaque projet, plutôt que d'utiliser un énorme framework "tout-en-un" dont je ne me servirai que très peu. Le dernier exemple en date est l'utilisation forcée que j'ai eu à faire de CodeIgniter, qui enferme l'utilisateur dans des choix de conception avec lesquels tous les développeurs (moi y compris) ne se sentiront pas forcément à l'aise. De plus je trouve que pas mal de frameworks deviennent très vite un véritable foutoir niveau organisation (MVC ultra-méga-strict oblige) et du coup tu perds plus de temps que tu n'en gagnes.
Quant au couches d'abstraction, pas besoin d'en rajouter 50 000, ya PDO et tout ce qui va bien derrière, on écrit une classe pour éviter de se taper toutes les commandes et voilà, réglé.
Dernier point, le débugging. Quand on est face à un bug comment être sûr de sa provenance (mon code ou le framework ?), surtout si la version est ancienne ? Sans parler des heures de débuggage du code qu'il faut se taper quand on fait une mise à jour (doctrine est un expert dans le domaine, et vas y que je change totalement mon modèle d'une version à l'autre, t'as le droit de refaire ton projet).
Moralité : codez vous-mêmes votre environnement, PHP lui-même est déjà bien assez rempli de fonctions nous simplifiant la vies, surtout dans ses dernières version.
Ceci étant, je n'ai pas du tout le même point de vue sur le JS (jQuery + jQueryUI + plugins pawa)

Je suis d'accord avec toi sur le point de vue.
Sur PEBKAC par exemple, c'est un Framework MVC inspiré de CodeIgniter, mais qui est 100% maison...

Donc je ne m'encombre pas du tout de ce qui est inutile dans beaucoup de frameworks lourds et dont on n'utilise que 15%, je n'ai que ce que j'ai besoin :)
Et ça répond à ce que tu soulèves, côté débug : connaissant bien mon FW, en cas de bug je vois tout de suite d'où ça vient.
Ce qui est beaucoup moins vrai quand j'utilise Zend ou autre :-P

P.S un peu trollesque : concernant jQuery, trop de plugins tuent le plugin ! (et la RAM client, et son navigateur, le temps de chargement de la page, et le poids total à charger)... :-)

Petite precision : le fichier en question contenait seulement une connexion PDO et une requete 'SELECT * FROM myTable' dans des balises php, recuperées sur un forum...

Donc oui, il a un peu de boulot avant d'attaquer Symfony.

Je fais exactement la même chose que toi, un FW léger, sans fioritures et que tu connais par coeur.
Pour ce qui est de Zend j'ai jamais eu le courage de regarder en détail j'avoue x)

Et pour jQuery, j'utilise jQuery, jQueryUI (pour l'interface) et 2-3 plugins après, style Qtip, une vraie tuerie :)

J'apprécie les plugins jQuery dans un back-end, mais j'essaie de les limiter dans un front... dans une optique de limitation du poids à charger (et aussi pour le mobile, qui a moins de power CPU qu'un PC)

J'utilise QTip et jQuery UI dans le back-end de PEBKAC d'ailleurs :)

Pour le mobile : http://jquerymobile.com/

C'est tip top :)
Question en passant : c'est possible d'avoir une notification quand on répond à un de mes commentaires sur un PEBKAC que je n'ai pas posté ?

C'est possible, mais pas au troisième niveau d'imbrication (comme on est ici). Sur les autres niveaux, tu constatera une case à cocher au moment du post de commentaire.

PS : jQuery Mobile c'est bien, mais jQuery Mobile ça ne va plus quand tu veux afficher de l'AdSense, avec la navigation full-Ajax (il faut désactiver la navigation Ajax, et c'est tout de suite quand même moins cool).

Pour avoir travaillé avec les deux, je suis plutôt partisan du desgin qui s'adapte en CSS3 (dit « responsive », comme ici-même), plutôt que d'avoir deux sites différents pour mobile & PC. Plus simple à maintenir (1 seul code), beaucoup moins lourd (pas de Javascript), et bien moins néfaste pour le SEO :-)

Même si je suis pas un expert, je trouve que ça rend pas trop mal sur mobile, avec ce site...

OK merci pour l'info :)

jQuery Mobile c'est sûr que ya des inconvénients mais l'avantage c'est qu'on se rapproche vraiment d'une appli native, surtout au niveau des boutons, parce que pour faire un like ou un +1 sur PEBKAC mobile faut soit bien viser soit zoomer ^^ Mais c'est tout à fait faisable sans jQM c'est sûr :)

Côté SEO je n'ai jamais eu à y avoir recours vu que je dev pour un intranet mais je pense que si la version mobile n'est pas prise en compte c'est pas si grave nan ? Point de vue totalement noob, c'est une vraie question :)

Et oui PEBKAC mobile rend bien, c'est juste dommage d'avoir laissé l'image "smiley" et le compteur de + à gauche du coup ça gaspille un quart de l'écran en navigation verticale. M'enfin c'est du détail ça m'empêche pas de le lire ^^

Pour le SEO le problème n'est pas tant la prise en compte de la version mobile, mais plutôt le fait d'avoir une duplication des contenus sur deux URLs (ou domaines) différent(e)s.
Google pas aimer ça du tout.

C'est vrai que je pourrais améliorer la lisibilité mobile en virant le smiley et en mettant le score ailleurs.

robots.txt ?

2eme question con : le smiley il est random ou j'ai loupé une FAQ qui explique à quoi ça correspond ?

Il est bien random le smiley.

(Robots.txt ça ira si tu veux bloquer l'accès de GoogleBot, mais la bonne solution est de servir la version mobile lorsque c'est « GoogleBot-Mobile » et la version normale quand c'est « GoogleBot »)

Troisième raison : si l'ORM est bien foutu (Eloquent, celui de Laravel, en est un excellent exemple si ma mémoire est bonne), tu peux construire un "bout de requête" qui sera stocké en tant qu'objet, et donc réutilisable sur plusieurs requêtes par la suite. Tu ne gagnes certes pas en performances (au final, ce sont toujours des requêtes SQL qui sont exécutées), mais niveau clarté et modularité du code c'est un gros plus selon moi.