Journal framework ou farmer ?

Posté par .
Tags : aucun
5
28
juin
2009
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
  • # C'est comme tout…

    Posté par . Évalué à 10.

    … avant de courir on apprend à marcher… pour le dev, c'est pareil : avant d'apprendre à utiliser un framework, on apprend à utiliser le langage et ses subtilités. De cette manière, en utilisant un framework, on sait ce qu'on fait, car on sait ce que fait le framework…

    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 . Évalué à 8.

      Je modérerais un peu... avant le grand bain, on fait un peu de pataugeoire, mais la première fois qu'on va dans le grand bain, une petite bouée ne nuit pas. Donc apprendre un langage, certes, mais toutes ses subtilités, peut-être pas tout de suite.

      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 . Évalué à 3.

        Lorsque je parle de subtilités, évidement, nul besoin d'être un gourou hein ! Par contre pour ce qui est du javascript, je maintient qu'il est besoin de connaître pas mal des subtilités et autres bizarreries avant de pouvoir utiliser pleinement un framework. Si on fait l'impasse, on se retrouve immanquablement dans la position de l'auteur de ce journal.
        • [^] # Re: C'est comme tout…

          Posté par (page perso) . Évalué à 2.

          C'est bel et bien la situation qu'il explique: utiliser un framework (mal fait ou incomplet je suppose) nécessite d'apprendre le framework ET ce qu'il est sensé abstraire.

          Il ne lui reste plus qu'à proposer des patchs :-)
          Yaka fokon etc.
      • [^] # Re: C'est comme tout…

        Posté par (page perso) . Évalué à 2.

        La bouée c'est un peu dangereux. Si tu te retournes, c'est dur de se remettre dans le bon sens.
  • # Et pourquoi diable

    Posté par (page perso) . Évalué à 10.

    Et pourquoi diable fais-tu un site avec des javascripteries kikoolol ?
    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 (page perso) . Évalué à 7.

      C'est vrai que les javascripteries kikoolol ne sont pas tres utiles. Par contre, javascript peut parfois se montrer tres pratique, comme dans des formulaires particulierement tarabiscotes.

      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 (page perso) . Évalué à 3.

        "Oh non, IE ne rend pas comme les autres!"

        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 . Évalué à 5.

          J'ai été un peu plus loin que toi dans l'étude de HTML/CSS/JS et des (in)compatibilités de navigateurs.

          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 . Évalué à 3.

          Pour les CSS c'est normal, c'est le principe de base tel qu'il était déjà du temps du HTML pur: les navigateurs supportent ce qu'il peuvent/veulent et ça donne un rendu plus où moins dégradé. (Bon, après que les navigateurs interprètent de façon différente les même propriétés c'est un autre problème, mais il y y a des cas où la recommandation est foule et laisse la place à l'interprétation)

          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 . Évalué à 2.

            C'est vrai que le faut que le javascript se comporte tellement différemment entre différents navigateurs n'aide vraiment pas.

            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 . Évalué à 2.

              et c'est sans parler de l'incompatibilité produite par les framework eux mêmes. Meanning certain librairie/framework JS rajoute un surcouche à JS et sans namespace.
              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 . Évalué à 2.

                Je pense que le problème vient plus du code qu'on choisit d'integrer ou non.
                Scriptaculous est une bouse infame.
            • [^] # Re: Et pourquoi diable

              Posté par . Évalué à 6.

              Je pense, sans vouloir t'offenser, que tu es resté sur une image de JS d'il y a 5 ans.

              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 . Évalué à 1.

                Js d'il y a 5 ans ou pas il y toujours de quoi s'arracher les cheveux.
                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 . Évalué à 5.

                  le problème viens sous ie quand il faut remplacer ou ajouter les script.
                  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 . Évalué à 0.

                    lol

                    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 . Évalué à 3.

                      As tu reflechies un poil à ce que tu essayes de faire ?

                      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 . Évalué à 1.

                        thx pour le lien mais j'ai pas de problème pour charger les script, mais plutot supprimer les anciens pour éviter de changer 2 fois le même code, sinon je connaissais pas ce site merci il y a des truc qui on l'air pas mal.
                        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 . Évalué à 4.

                  N'utilise pas, jamais innerHTML et innerText ! Jamais jamais jamais !

                  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 . Évalué à 1.

                    pour le parser c'était pour parsé du HTML (résultat de ma requete ajax) en dom pour remplacer le contenu de ou du moins rajouter les nouveau css.

                    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 (page perso) . Évalué à 1.

                    Et du coup tu aura des performances de merde !!!

                    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 . Évalué à 1.

                      je cherche à ajaxifier complètement un site basé sur joomla. Bien sur je récupère la page entière mais seulement le contenu qui change, (contenu de la texte et les bandeau de doit éventuellement).
                      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 . Évalué à 3.

                        Vu ce que tu décrit, il me semble que tu tente de réécrire en javascript tout ce que fait le navigateur (y compris le head de la page!) quand on clique sur un lien et qu'il charge la page.
                        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 . Évalué à 1.

                          en gros ouais c'est ça, ça marche avec firefox et opera en tout cas. Perso je m'en fous de mettre du ajax sur partout, c'était les consigne un peu "extravagante" du travail.
                          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 . Évalué à 1.

                C'est tout à fait possible.

                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 . Évalué à 3.

                  Pour comprendre JavaScript, il faut comprendre le PROTOTYPAGE.

                  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 . Évalué à 0.

                    Désolé, mais créer des classes avec le mot clef function, et des méthodes avec maclasse.prototype{ methode: pouet() }, je trouve ça illisible et fouilli.

                    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 . Évalué à 4.

                      Ba parce que les classes n'existe pas en JavaScript.

                      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 . Évalué à 2.

      suis d'accord avec l'inutilité du kikoolol sinon je dirai pas kikoolol, mais c'était le principal objectif de mon boulot précédent, des site dynamique avec gestion des utilisateur des petit composant spécifique à la commande (se qui était le plus intéressant), mais l'interet du boss était sur le kikoolol uniquement.
      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 . Évalué à 1.

    Je pense que tu es malheureusement tombé dans les sirènes du marketing. Il ne faut pas oublier que quel que soit le framework :
    - 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 !
    • [^] # Re: Les sirènes du marketing

      Posté par . Évalué à 3.

      Marketing ouais, ça commencer avec les slogan du boulot ne pas "réinventé la roue" et un framework imposé (pas mal d'ailleurs).
      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 (page perso) . Évalué à 3.

    Pour être en écho avec les autres commentaires, je dirais qu'un framework est utile dans deux contextes particuliers :
    * 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 . Évalué à 3.

      Faut voir aussi qu'un framework est un outil très puissant à partir du moment où on travail à plus d'une personne sur le projet. D'une part il permet de garantir dans une certaine mesure que tout le monde code avec la même structure et en théorie permet d'aider à rentrer dans le code pour un nouvel arrivant sans avoir à tout comprendre parce que le truc bidouillé maison n'a jamais été documenté.
    • [^] # Re: L'usage des frameworks: un transfert du savoir-faire

      Posté par . É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.

      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 (page perso) . É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 . Évalué à 2.

          Ben en fait, spring fait partie du truc de base J2EE.
          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 (page perso) . Évalué à 1.

            Ben en fait, spring fait partie du truc de base J2EE.

            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 . Évalué à 1.

              tout a fait pour le premier point.
              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 . Évalué à 1.

    Un élement à considérer est le degré d'abstraction que fournit ton framework. J'utilise jQuery pour ma part, et c'est un framework assez bas niveau. De nombreux plugins existent pour rajouter plein de fonctionnalités, et en fait j'ai beaucoup appris de javascript en lisant le code de ces plugins. Mais je pense que cela ne serait bien sur pas possible si le framework était de plus haut niveau.
    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 à ceux qui les ont postés. Nous n'en sommes pas responsables.