Je doute de plus en plus de leur efficacité. Pour créer des effet kikoolol Javascript par exemple, j'ai du développer pas mal de petites conneries en JS et les problèmes de comptabilité et de navigateurs buggés m'ont orienté vers des framework, pour éviter de "réinventer la roue".
Régler un problème qui à déjà été règlé recoder la même fonction qu'un autre gars etc..
Donc efficacité, rapidité.
Seulement je ne suis pas expert JS pour moi c'est nouveau de mettre du kikoolol dans les page web. Alors petit à petit je progresse non pas dans mes connaissance de JS, mais du framework que j'ai choisis.
Certes j'ai gagné du temps à éviter de résoudre certaine absurdité pour faire plaisir à IE.
Mais voilà qu'il arrive un moment où le framework ne peux résoudre un problème précis.
Et me revoilà à étudier JS pour trouver comment contourné le problème (où le résoudre on peux rêver) et je me sens beaucoup moins compétent d'un coup.
Si j'avais passer mon temps à résoudre les problème 1 à 1 au lieu d'utiliser "la solution", je serai peut-être devenu un expert JS et j'aurai mon propre Framework qui conviens à chacun de mes développement.
En temps que programmeur je trouve cela frustrant de ne pas maîtriser mon outils de travail, alors que je dois justement maîtriser chaque point un à un pour arriver à former un tout cohérent et peu buggé (ou pas).
PS: JS n'est qu'un exemple, pour le PHP j'ai eu le même problème un bon framework content jusqu'à la situation ou il faut l'expertise d'un développeur de framework que je pourrai être si je n'avais pas commencer avec un framework XD
Journal framework ou farmer ?
28
juin
2009
# C'est comme tout…
Posté par jeffcom . Évalué à 10.
en bref : ne pas oublier qu'un framework n'est qu'un outil. Aucun framework ne remplacera la maîtrise (aussi légère soit elle) d'un langage.
[^] # Re: C'est comme tout…
Posté par Franck Routier (Mastodon) . Évalué à 8.
L'intérêt d'un framework _libre_ c'est aussi d'avoir un ensemble de code cohérent qu'on peut étudier pour progresser le jour où ça devient utile. Et la trajectoire décrite dans le journal me semble plutôt saine et normale.
Ceci dit, développer en javascript est une galère... heureusement que firebug est là...
[^] # Re: C'est comme tout…
Posté par jeffcom . Évalué à 3.
[^] # Re: C'est comme tout…
Posté par Kerro . Évalué à 2.
Il ne lui reste plus qu'à proposer des patchs :-)
Yaka fokon etc.
[^] # Re: C'est comme tout…
Posté par ahuillet (site web personnel) . Évalué à 2.
# Et pourquoi diable
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 10.
Fais plutôt comme les gens bien, un site statique optimisé anybrowser. Moi, depuis que je fais ça, j'ai retrouvé du travail, ma femme est revenue, et on me paye des coups à boire au bistrot.
[^] # Re: Et pourquoi diable
Posté par Brioche4012 (site web personnel) . Évalué à 7.
A ce moment la, ce qu'on peut regretter n'est pas que ce soit du javascript, mais bien l'eternel troll du "Oh non, IE ne rend pas comme les autres!".
Apres, pour en revenir au probleme des frameworks en soit, avant d'utiliser un framework, il vaut mieux savoir comment ca marche. Un framework n'est qu'un raccourci, d'habitude les gens qui les utilisent savent comment faire la meme chose a la main.
[^] # Re: Et pourquoi diable
Posté par Ph Husson (site web personnel) . Évalué à 3.
Y a vraiment que ça ?
J'ai fait quelques petites expériences CSS (et je me débrouillais très mal, raison pour laquelle j'ai vite arrêté d'ailleurs.), et aucun browser ne rendait de la même manière, que ce soit IE, firefox, konqueror ou opera....
[^] # Re: Et pourquoi diable
Posté par Yth (Mastodon) . Évalué à 5.
Ce que tu dis est vrai, mais c'est assez facile de « corriger » ta CSS et ton javascript pour qu'ils passent à l'identique sous FF, Konqueror et Opéra. Je dirais que tu rajoutes environ 15% de temps en plus.
Mais pour faire un truc qui colle aussi avec IE, tu luttes beaucoup plus longtemps que ça, environ les 85% restant pour que tu aies passé la moitié de ton temps à régler des problèmes d'incompatibilités, et l'autre moitié à vraiment créer ta page.
Et au final pour avoir le même résultat partout, tu as dû « simplifier » ta page et virer quelques trucs qu'il aurait été bien sympa d'avoir, ou plus simple à faire.
C'était vrai au moins avec IE6, je n'ai aucune idée pour ce qui concerne IE7.
Les 15% de temps en plus sont supportables, mais IE énerve vraiment très rapidement...
Yth.
[^] # Re: Et pourquoi diable
Posté par wismerhill . Évalué à 3.
Par contre, pour le javascript, c'est très gênant que l'API de base soit implémentée suivant le bon vouloir des navigateurs (et en particulier le DOM qui est une vraie galère si tu veux faire un truc portable).
[^] # Re: Et pourquoi diable
Posté par Pierre Tramonson . Évalué à 2.
Au final on se retrouve avec un langage:
- avec une syntaxe trop permissive
- sans éditeur digne de ce nom (sauf si vous connaissez un éditeur ou plugin éclipse qui vous sort les warnings/erreurs d'exécution JS)
- difficile à débugger (super le débug à coup de alert)
- dont le comportement dépend du navigateur final
- dont le comportement dépend du niveau de sécurité du poste
La situation est même pire que celle de PHP :p
Pourquoi le W3C n'a pas pris les devants en proposant d'intégrer dans HTML quelques fonctionnalités "standard" supplémentaires ?
Actuellement on a déjà des onclick(), onmouseover(), etc...
Pourquoi n'aurait-on pas en natif HTML :
- des fonctions génériques du genre check() sur un champ d'un formulaire, pour vérifier par exemple que ce champ contient tel type de données (cf regexp).
- le même genre de fonctions mais qui t'empêcherait de saisir un caractère d'un type non autorisé dans un champ. Je sais qu'on peut le faire actuellement, mais il faut gérer en plus de la saisie au clavier, le copier/coller...
- une gestion des erreurs sur un formulaire entier, qui te sortirait par exemple la liste des champs ne validant pas la fonction check()
...
Les formulaires JS sont plus que courants actuellement, et ce genre de besoins existe sur tous les sites.
C'est dommage de se faire chier à devoir prendre un framework JS pour ça.
[^] # Re: Et pourquoi diable
Posté par lsmod . Évalué à 2.
essayer de faire fonctionner un scriptaculous et mootools et c'est la gallère par contre avec le yui de yahoo pas de problème puisque qui est cloisonner dans son namespace.
De plus certaine fonction sont désactivé par sécurité mais sur certain object dom seulement, parce exemple innerHTML sur ne fonctionne pas sous IE6 et 7 (pas tester sous IE8).
Mais je pense que si on reste dans de petite fonctionnalité il y a moyen de garder ces cheveux, le problème viens quand on mise tout sur JS.
[^] # Re: Et pourquoi diable
Posté par geb . Évalué à 2.
Scriptaculous est une bouse infame.
[^] # Re: Et pourquoi diable
Posté par kowalsky . Évalué à 6.
Je suis sur un projet ou je suis à 6000 lignes de code JS.
Il y a moins de 150 (je crois) lignes qui concerne un contournement de comportement different entre navigateur.
C'est surtout lié à des problèmes de listening. Mais un fois mis l'abstraction la dessus, je ne fais plus de code spécifique.
Tout est codé en objet, dans des (pseudo) classes à la Java, documenté grace à javadoc,etc...
D'ailleurs, mes classes java coté tomcat "discute" de manière quasi transparente avec le coté client, en JS.
Debuger avec la function alert... C'est un peu oldy, non ?
Au pire, firebug est magnifique pour ce boulot, au mieux, tu fais comme je fais :
Un system de log, qui sois affiche les logs dans un div, sois les envois dans POST en asynchrone. Comme ça tu peux les pousser coté serveur et faire mumuse avec.
Encore une fois, aucune différence avec un autre langage, c'est logs, ça se traite et c'est tout. C'est franchement très simple de se faire une fonction log(message) en javascript.
Je ne connais pas Eclipse, mais NetBeans integre le JS très bien. Il possede un explorateur de (pseudo) classes, completion, détection de certaine erreur, un peu de refactor, etc.
Ton problème de formulaire ne peut pas se regler avec des onblur="check(this.value)" onchange="check(this.value)" onkeyup="check(this.value)" ?
Le probleme de javascript, il est souvent assis sur la chaise. C'est un langage relégué au petite tache alors qu'il à un enorme potentiel si on pense l'application comme un tout. Le coté serveur ET la partie cliente. Et l'on gagne du temps.
exemple :
Un objet coté serveur de type user ?
on créer une fonction user.toXML().
On créer le même objet coté javascript.
on créer une fonction user.setByXML()
on créer une fonction user.toDiv(), et hop, a chaque fois que l'on veut afficher un user sur le site, y a plus qu'a.
ça reduit la charge, ça simplifie, etc...
Bien sur c'est un exemple bidon, mais ça s'adapte vite.
Il faut juste arreter de penser un site comme juste la partie serveur. L'affichage, c'est la partie client, c'est tout.
[^] # Re: Et pourquoi diable
Posté par lsmod . Évalué à 1.
C'est certain bugs qui me fatigue beaucoup par exemple j'ai du me casser la tête sans trouver de solution correct sur ça:
changer le contenu de pour ajaxifier un site. Via ajax je charge le nouveau contenu de la page et les éventuel nouveau css, et script, le problème viens sous ie quand il faut remplacer ou ajouter les script.
D'abord le innerHTML qui ne fonctionne pas sous IE pour head, bon maintenant je le sais mais avant de savoir si c'est mon code qui bug ou le navigateur...
Ensuite j'ai penser parser mon HTML en dom pour manipuler du dom plutot. Je cherche toujours un parser correct qui fonctionne sous IE.
J'ai finalement parser mon HTML au niveau de PHP pour renvoyer du JS à eval, mouarf.
Tous ça pour me rendre compte que il n'y avait pas moyen de remplacer les node "script" sous IE et que j'inclus plusieur fois les même script ce qui créer des problème.
De plus j'ai voulu appeller manuellement l'évenement onload, bon pas moyen, pas de problème via fireevent de mootools je peux l'appeller, mais bizarrement sous firefox pas besoin de le faire, mais sous IE oui.
Tous ce que j'ai réussis à faire c'est ajouter les nouveau css.
Bon j'avais préconnisé des le départ d'inclure tout les script et css nécessaire toute les pages, mais il faillait que ça reste modulaire.
firebug et compagionJS pour IE sans ça c'est vraiment la misère. Enfin c'est vraiment le début avec JS qui est compliqué.
[^] # Re: Et pourquoi diable
Posté par geb . Évalué à 5.
PEBKAC
Tous ça pour me rendre compte que il n'y avait pas moyen de remplacer les node "script"
idem
De plus j'ai voulu appeller manuellement l'évenement onload
Idem.
innerHTML
Idem, Dom tout ça. A chaque fois que tu l'utilises des morceaux de banquises fondent dans l'ocean.
Bref...
Tu devrais reprendre les bases, avant de crier au méchant framework.
[^] # Re: Et pourquoi diable
Posté par lsmod . Évalué à 0.
là c'était sans framework que j'ai codé ça. Et pour le innerHTML dans sous IE ça avait rien d'une erreur de provenant du composant situé entre le bouf et le plasma...
De plus j'ai voulu appeller manuellement l'évenement onload
je ne savais pas que c'était pas possible directement, mais qu'il fallait passer par l'abstraction pour arriver au même résultat.
Le problème est le comportement bizarre sous firefox qui execute le code sans fire domready.
J'expliquai juste la difficulté qu'il y a sous JS due aux bug des navigateur et au fonction imcomptabilité d'un navigateur à l'autre, ex: parser html->dom (rangenode ou je sais plus quoi) est sous firefox, opera, mais pas sous msie), d'où l'utilisation de framework parfois bugé/incompte d'ou le retour au source pour atteindre le connaissance nécessaire etc..
[^] # Re: Et pourquoi diable
Posté par geb . Évalué à 3.
Charger/décharger/modifier du code à la volée avant/pendant son éxecution.
Ca n'est pas vraiment typiquement en programmation.
Pour le dire autrement tu as intérêt à avoir un bon garbage collector,
qui du coup portera bien son nom :p
Donc il est normal que tu ne puisse pas le faire (en tout cas pas de manière triviale).
Tu devrais plutôt revoir ta conception plutôt que de chercher à contourner les protections
mises en place par les navigateurs. Après tout est ce vraiment illogique de charger les
scripts avant ? Pas moins que de lancer manuellement onload() pour moi.
Il y a en effet des manques dans le parser dom de IE (ou plutôt dans les fonctions que celui
ci expose) mais je doute que tu ai besoin de fonctions très évoluées pour charger tes scripts
(cadeau: http://cross-browser.com/x/lib/view.php?s=xLoadScript ).
[^] # Re: Et pourquoi diable
Posté par lsmod . Évalué à 1.
Mais du as sûrement raison c'est plutôt une erreur de conception si j'y arrive pas de cette façon il y a sûrement une autre façon pour arriver au même résultat.
C'était dans l'idée ajaxifier joomla sans modifier le résultat des page produite. Pour javascript activé ou pas on puisse naviguer et aussi que ça marche peux importe le contenu à charger.
Comme il y a beaucoup d'extension avec joomla que j'utilise à l'occasion il fallait que je trouve le moyen de pouvoir faire ça sans devoir inclure tout les css et script dès le 1er chargement au niveau du template pour une question de poid et aussi d'éviter d'avoir à étudier chaque extensions.
Bon c'est une vielle histoire mais ça m'intéresse toujours puisque j'ai jamais trouvé de solution valable, manque de temps à passer la dessus.
Voilà où en était le projet quand je l'ai laisser :
La méthode est la suivante:
- Le lien côté client sont modifier via javascript, pour que le contenu soit charger via ajax
Etat du projet:
Ce qui marche globalement (firefox, opéra, IE6 & 7):
- chargement de contenu (contenu + bloc + header)
- ajoute des nouveau header (les nouveau CSS ne pose plus aucun problème)
Les bugs:
- Sous IE remplacer les ancien header (uniquement le CSS et JS) par les nouveau pose problème, il sont ajouté pour le moment
- Bug avec l'appel d'événement domready pour executé les nouveau script
(bizarrement sous firefox je n'ai pas besoin de l'appeller, mais sous IE oui, et sous IE comme
n'est pas remplacer par les header de la réponse de ajax, les script s'accumule et sont dupliqué...
- bug avec certain formulaire le lien n'est pas correct
[^] # Re: Et pourquoi diable
Posté par kowalsky . Évalué à 4.
Mais plutôt, pour créer un div avec du texte dedans, par exemple :
document.createElement("div").appendChild(document.createTextNode( "Mon text" )) ;
Et du coup, tu va vite voir que JavaScript est un VRAI putain langage de programmation !
Sinon, je ne comprend pas ton problème de parser ? Tu n'a jamais à t'en soucier normalement.
[^] # Re: Et pourquoi diable
Posté par lsmod . Évalué à 1.
Voilà ce que j'avais trouvé pour firefox, mais cette fonction n'est pas disponible sous IE, j'ai tester plusieurs parser sans trouver quelque chose qui fonctionne correctement.
var range = document.createRange();
range.selectNode(document.body);
var parsedHTML = range.createContextualFragment(texte); // parse html to DOM
document.getElementsByTagName('head')[0].appendChild(parsedHTML);
J'ai penser renvoyer du XML ce qui serai plus adapter pour le transformé en dom. M'enfin comme j'ai dit c'est une veille histoire ma tête est plus très fraîche sur tout ce que j'avais tester.
J'ai finalement trouver une solution intermédiaire, ce qui m'a amener à un autre problème.
Le problème que j'avais c'était que je ne pouvais pas supprimer les ancien node de head sous ie.
Et comme le contenu de la page est différent certain script n'ont plus rien à y faire.
Et comme la plupart son appelé à l'event domReady si je fire domready j'appelle aussi les script qui n'ont plus rien à faire là.
Si j'avais pu supprimer les anciens header ou juste fire les nouveau script à la limite ça aurai fait l'affaire.
Sinon le résultat était concluant sous FF et opera.
[^] # Re: Et pourquoi diable
Posté par Puyb (site web personnel) . Évalué à 1.
J'ai du convertir mon application récemment de la création / manipulation du DOM à la génération de HTML puis utilisation de innerHTML...
Bien sur, ça ne m'empêche pas de quand même utiliser des objets pour générer tout ça (et donc de pouvoir revenir à l'ancienne méthode au besoin)...
Un petit lien pour illustrer mon propos : http://www.quirksmode.org/dom/innerhtml.html
Sinon, je suis d'accord avec toi le javascript est un très bon langage qui est (était) à tord classé dans la catégorie des gadget pour servant a faire tomber des flocon de neige sur la page à noël à coup de document.write() !
Sinon, moi non plus je ne comprend pas ce que cherche à faire lsmod.
Si il s'agit d'utiliser le javascript pour récupérer une page HTML, la parser, puis remplacer les scripts, le css et le contenu de la page actuel avec, pourquoi ne pas tout simplement charger la nouvelle page !
D'autre par pourquoi vouloir créer des balises script... Pourquoi ne pas tout simplement faire un eval du code ? Tu peux éventuellement empêcher le problème de double chargement des codes en tenant à jour une liste des scripts déjà chargé.
Pour l'événement DOMready, je comprend que ça ne marche pas, car à priori, ton DOM doit être prêt au moment ou tu modifie ta page avec le javascript. Il est donc normal que l'événement ne soit pas lancé.
Pour le liens des formulaire (je présume que tu parle de l'attribut "action"), je pense qu'il s'agit d'une erreur d'URL relative. Il fait que tu changes tous les liens et action de ta pages par une version mise à jours de l'url.
[^] # Re: Et pourquoi diable
Posté par lsmod . Évalué à 1.
Pour ça pas de problème, mais si je charge une gallerie d'image avec des ouverture animé en javascript par exemple, il faut que je charge les script qui vont avec et que je les executent une fois charger OK ?
Bon mais je n'ai pas la maitrise de ces script ma solution doit fonctionner avec n'importe quel site sous joomla.
Bon alors je charge mon contenu les éventuelle css de la galerie et les script qui vont avec, bon maintenant c'est script son programmer pour attendre domready avant de ce lancer.
Pas de domready puisque chargement via ajax. D'où le fireEvent('domready') pour appeller l'événement manuellement.
Ok j'ai mon nouveau contenu mes nouveau css et les script pour la page pas de problème normalement.
Mais comme j'ai dit le problème c'est que je ne peux remplacer les node de head sous ie du coup répétition des script, du coup bug à l'appel de domready.
Je pourrai faire une liste ouais ce serai pas mal ma ça résous pas le problème pour les script inclus a 1er chargement si il ne doivent plus ce trouver là après chargement via ajax.
[^] # Re: Et pourquoi diable
Posté par wismerhill . Évalué à 3.
Mieux vaut le laisser faire, il le fera bien mieux.
Si tu veux absolument que ce soit fait par javascript t'as qu'à lui demander de charger une nouvelle adresse.
[^] # Re: Et pourquoi diable
Posté par lsmod . Évalué à 1.
M'empêche que ça aurai fait plaisir à beaucoup d'utilisateur de joomla! et au boss lol. Si c'était pas ie j'aurai pu y arrive.
C'est faisable facilement pour du contenu sans JS et sinon il faut avoir la maîtrise des script utilisé dans les page qu'on charge, pour le css pas de problème.
[^] # Re: Et pourquoi diable
Posté par Pierre Tramonson . Évalué à 1.
Maintenant si ne m'abuse, il n'existe pratiquement rien pour faciliter la vie du développeur et assurer que le code soit un minimum propre.
Là où Java, C# ont des outils, frameworks et règles de code assez bien fournis (je ne parle pas de C, C++ pas vraiment adaptés au web).
Désolé, mais Javascript me semble trop fouilli pour être utilisable correctement, et je maintiens mon parallèle avec PHP d'il y a quelques années.
Mais je veux bien admettre ne pas être au courant de toutes les dernières nouveautés et outils JS :)
[^] # Re: Et pourquoi diable
Posté par kowalsky . Évalué à 3.
JavaScript n'est pas fouillis. C'est un langage très cohérent, mais forcement, si tu ne comprend pas le prototypage (sans vouloir t'offenser, je ne connaissais pas il y a peu aussi), tu va vite faire n'importe quoi. Si en plus, comme dans d'autre langage, tu ne te fixe pas quelques règles, ça va vite être n'importe quoi.
Mais je t'assure, je fais énormément de JavaScript. Au début je le considérait comme un sous langage tout juste bon à checker des formulaires. Mais suite au volume de code que j'avais à faire, je me suis renseigné et une fois que tu comprend que pour faire des trucs de plus de 100 lignes, tu va devoir gérer ton code comme en C++ ou en java, ça se passe mieux.
Et c'est pareil pour tout les langages en fait, si tu ne "prévoit" pas la façon dont tu va "organiser" ton code, t'es foutu.
Sinon, pour coder en JavaScript (et en HTML) je conseil netbeans.
[^] # Re: Et pourquoi diable
Posté par Pierre Tramonson . Évalué à 0.
Si on veut faire de l'objet, on instaure des règles pour définir proprement attributs, méthodes et héritage.
Je n'ai pas l'impression que ce soit le cas en Javascript.
On s'en sort avec des astuces et de la bidouille, mais le langage devrait être nettement plus propre.
[^] # Re: Et pourquoi diable
Posté par kowalsky . Évalué à 4.
function c'est un type.
Tu créer une function, et dans cette function, tu lui déclare des attributs avec this.attr=pouet ;
Et ton attribut aura le type de pouet. Et si pouet est une fonction, this.attr sera une fonction.
Donc, pour créer une PSEUDO classe :
var monObjet=function () {this.attr1=function (S_1) {alert(this.attr2+" "+S_1);} ;
//Voila, tu peux appeler this.attr2 qui n'existe pas :)
//Parce qu'en fait, tu ne l'appel pas, tu le déclare.
this.attr2="Minou" ;
}
Mais si tu veux le "voir" que tu créer un objet, tu fais :
var monObjet=new Object() ;La tu lui donne un attribut de type function
monObjet.firstMetho=function (P_Pa) { alert(P_Pa) ;}La tu appel ton attribut, qui est une fonction, puisque que tu lui a donné ce type.
monObjet.firstMetho("minou") ;La tu lui donne un attribut de type entier
monObjet.secondMetho=1 ;Et la, tu liste tout tes attributs, avec leur nom et leur valeur.
for (var i in monObjet) {alert(i+" "+monObjet[i]) ;}Quand on fait du javascript, il OUBLIER java, oublier PHP. Il faut penser prototype :) .
[^] # Re: Et pourquoi diable
Posté par lsmod . Évalué à 2.
Maintenant suis passer à autre chose mais ça ma fait me poser la question des framework, que j'utilisais pas avant.
# Les sirènes du marketing
Posté par gUI (Mastodon) . Évalué à 1.
- c'est plus efficace uniquement si tu fais une appli pour laquelle ton framework est dédié
- c'est un nouveau tru cà apprendre, rien n'est jamais immédiat
- ça ne sera jamais une réponse magique à n'importe quel problème que ce soit
- quelle que soit la version de ton framework, il en existera une suivante qui remettra en cause pas mal de trucs déjà faits
- je suis sûr qu'il existe d'autre règles, je laisse le fil de discussion compléter (-:
Une fois ceci bien assimilé, tu peux commencer à bosser !
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Les sirènes du marketing
Posté par lsmod . Évalué à 3.
Je pense que je vais me tourner vers des librairie pour les PHP, pour retrouver le MVC et continuer ma progression qui allais bien.
A moins ça m'a fait découvrir des méthode de développement que je connaissait pas même si je reproduisait plus ou moins la même chose comme le MVC.
# L'usage des frameworks: un transfert du savoir-faire
Posté par Miguel Moquillon (site web personnel) . Évalué à 3.
* tu ne connais pas bien le langage ou les techniques à utiliser et tu ne souhaites pas y investir du temps dedans ; et il existe un framework qui t'abstrait tout ça.
* tu connais bien le langage, la technique, la plate-forme sur laquelle tu développes et tu ne souhaites pas réécrire/copier à chaque fois la même chose ou passer ton temps à maintenir ton propre framework.
Dans les deux cas, j'ai constaté une chose : on s'accoutume à l'usage de frameworks et si on s'améliore dans la mise en œuvre et l'intégration de frameworks, on perd peu à peu la faculté (et la volonté) de faire par nous même. De plus, avec l'accoutumance, on perd aussi le recul suffisant pour apprécier l'intérêt d'utiliser ou non un framework ou même tel ou tel autre framework.
Pour prendre exemple de mon cas :
* je ne souhaite pas m'investir en JS et j'adopte facilement des outils comme scriptulous, puis maintenant de frameworks qui me génère le JS.
* sur plate-forme Java, j'ai tendance à abuser du framework Spring pour gérer le cycle de vie des objets de mes applis et assurer le découplage entre les interfaces et leurs implémentations ou entre les briques métiers et les briques techniques. Tout ceci pour éviter de gérer moi même à nouveau tout ça.
Toutefois, il ne faut pas se leurrer. Le temps passé à maîtriser ton code est transféré sur celui des mécanismes sous-jacent au framework. Bref, un framework n'évite pas d'apprendre ou de savoir-faire quelque chose, il ne fait, AMHA, que transférer l'apprentissage et le problème ailleurs.
[^] # Re: L'usage des frameworks: un transfert du savoir-faire
Posté par suJeSelS . Évalué à 3.
[^] # Re: L'usage des frameworks: un transfert du savoir-faire
Posté par thedude . Évalué à 1.
C'est un framework fabuleux, admirablement bien ecrit, qui permet tout simplement de ne pas perdre de temps sur des betises techniques.
Faire une appli J2EE sans framework pour gerer la base de la base, c'est quand meme particulierement pete couille et tu perds un temps monstrueux pour faire des trucs qui n'ont rien a voir avec le code metier (ce que tu es paye pour ecrire, ne l'oublions pas).
Un peu comme hibernate: tout ce que je veux, c'est lui dire que tel objet va remplir ses attributs dans telle table.
Le sql resultant, je m'en cogne.
Trier les udpates (delete/update/add) quand je modifie une liste, ca me saoule et j'ai autre chose a faire.
Ecrire la requete de join, ca me gonfle, mais tu peux pas savoir a quel point. Les tables sont designes, on lui dit que tel objet a sa foreign key dans telle table, demerde toi tout seul mon gars, nous on est occupe a autre chose.
Gerer mon pool de connexion, itou.
Le probleme ici, c'est qu'il part de 0.
Le framework l'aide, mais le framework ne peut pas tout faire. Va falloir qu'il apprenne comment ca marche sous le capot, ca va lui permettre de comprendre les entrailles de son framework, ce qui va lui permettre de comprendre ce qu'il se passe quand il utilise son framework.
Bref, il passe de debutant a mec qui connait son affaire.
[^] # Re: L'usage des frameworks: un transfert du savoir-faire
Posté par Miguel Moquillon (site web personnel) . Évalué à 1.
concernant spring, je suis pas trop d'accord.
C'est un framework fabuleux, admirablement bien ecrit, qui permet tout simplement de ne pas perdre de temps sur des betises techniques.
Heu, c'est où que j'ai écris que Spring n'est pas bien. Il ne me semble pas l'avoir écrit. J'ai juste écrit que j'en abusais, autrement dit que j'ai tendance à l'utiliser même dans des applications simples qui ne nécessitent pas nécessairement celui-ci.
Je ne sais pas si ça a un rapport avec la suite de ce que tu as écris, mais gérer la base de donnée n'est pas du ressort de Spring ; il n'offre que des accès à des frameworks tiers comme JPA par exemple (c'est d'ailleurs une de ses grandes forces ; ne pas être intrusif) mais ce n'est pas lui que va gérer ça.
[^] # Re: L'usage des frameworks: un transfert du savoir-faire
Posté par thedude . Évalué à 2.
C'est tellement bien ecrit, pratique, non intrusif, bref tellement bien fait que je ne vois pas une seule bonne raison de ne pas l'utiliser.
Meme dans un projet minuscule.
Quand a la base de donnees, je sais bien, c'est pour ca que j'ai precise hibernate.
Qui fait lui aussi un peu partie du b-a ba de toutes appli j2ee digne de ce nom, va falloir serieusement argumenter pour justifier de la non utilisation de hibernate dans un quelconque projet tourant sur une serveur d'appli java.
Ce que je veux dire par la, c'est que tous les frameworks ne se contentent pas de deplacer un probleme, comme tu le dit.
Ceux vraiment bien concu simplifient et reglent une enorme partie du probleme, apportant de legers problemes evidemment, mais bien plus simple a resoudre.
[^] # Re: L'usage des frameworks: un transfert du savoir-faire
Posté par Miguel Moquillon (site web personnel) . Évalué à 1.
Hum, je pense que tu veux signifier ici que Spring est très pertinent dans les applications Web Java (dont la spécification est une partie de J2EE, JEE maintenant), même s'il ne fait pas partie de J2EE.
Ce que je veux dire par la, c'est que tous les frameworks ne se contentent pas de deplacer un probleme, comme tu le dit.
Oui, ils ne se contentent pas de déplacer le problème, mais c'est un point à ne pas négliger ; leur objectif est tout de même d'amener le problème sur un autre terrain qui soit plus facile à appréhender. Par exemple, les outils déplacent en général la connaissance et le savoir-faire dans l'outil même. Et pour reprendre ton exemple d'Hibernate, point de salut si tu ne comprends pas comment il marche et plus particulièrement ses histoires de cache de premier niveau et de second niveau.
[^] # Re: L'usage des frameworks: un transfert du savoir-faire
Posté par thedude . Évalué à 1.
Spring, c'est un no brainer comme disent nos amis anglophone: a utiliser sans aucune moderation dans tout projet j2ee.
J'avoue qu'hibernate a plus de subtilite a connaitre, et est donc plus delicat, mais reste quand meme difficilement contournable (et oui, je me suis fait baise comme tout le monde le jour ou on a active le cache de second niveau, parce que j'avais assume qu'hibernate en faisait bien plus que ce qu'il fait reellement).
# framework bas niveau
Posté par Dreammm . Évalué à 1.
Ce que je dis en gros, c'est que l'utilisation et la lecture d'un framework plutôt bas niveau peut t'en apprendre long sur un langage, d'autant plus que le code est de qualité. Cela suppose un investissement en temps, comme souvent bien sur.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.