Discussion :

[FremyCompany]

Bon désolé de m'être laissé emporté, mais il est vrai que .NET est une véritable avancée dans le monde du développement, et je trouve vraiment mal-venu de le critiquer... C'est un peu comme critiquer les fenêtres quand on est sous DOS... Sous DOS aussi on sait éditer un fichier texte, et on avait pas besoin de tout le FrameWork de windows pour ca
Sans rancune aucune, mais veille à ne pas critiquer une technologie juste parce qu'elle ne tourne pas sur les anciennes machines

_________________________________________
Pour ce qui est du cryptage de script, même si je ne suis pas pour, personnellement, je crois que tu peux demander à publier le résultat de tes recherches dans la FAQ JavaScript, ca pourrait aider d'autres gens qui cherchent à faire la même chose.

Pour ce qui est des raccourcis à ID, évite, ca risque de poser des problèmes Par contre je suis de ton avis document.getElementById c'est long à écrire Certains FrameWork javascript implémentent une fonction pour gagner du temps : $(id)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

function $(id) { return document.getElementById(id); }

Essaie, tu verras, tu vas l'adopter

[SpaceFrog]

oui certaines librairies appoertent tout de même un confort d'utilisation
la librairie prototype http://dcabasson.developpez.com/arti...ototype-1.4.0/

également le window prototype avec les effets de scriptaculous

[Hibou57]

Un peu en marge de ce sujet, mais tout de même lié d'une certaine manière : je ne sais plus où, quelqu'un m'avais environ dit que plutôt que de brouiller le code javaScript pour le protéger contre les modifications ou autre, une meilleur idée serait peut-être de coder en Java plutôt qu'en JavaScript (il me semblait que c'était dans ce fil, mais je ne retrouve pas le post... est-ce que j'ai rêvé ou c'était bien ici ?).

Je viens de récuperer un JDK 1.1 (le plus basique), en pensant essayer de remplacer certains code javaScript par des applets Java. Mais apparement il n'est pas possible d'accéder au DOM de la page en Java. Donc les applications web basée sur DHTML sont contraintes d'utiliser JavaScript. Mais c'est dommage, parce que le Java aurait put y a gagner à avoir une classe d'accès au DOM HTML. Surtout que si JavaScript le fait, Java devrait en être capable (je parle du Java-1, et non pas des mamouths que sont les dernières versions).

Il ne me semble même pas possible non-plus de faire s'échanger des données entre une fonction JavaScript et une applet Java. Alors il n'y a même pas de pont envisageable.

Tant pis alors, j'aurais bien aimé pouvoir appliquer cette alternative, ... mais apparement, es impossibile

[buzzkaido]

Surtout que si JavaScript le fait, Java devrait en être capable

Pour moi cette histoire me parait un peu bizarre...

Remplacer du javascript par du Java ?

L'un n'a STRICTEMENT RIEN à voir avec l'autre. Ni historiquement. Ni dans le langage lui-même. Ni rien du tout.

Le Javascript est un langage de script developpé pour le Web.

Le Java est un langage interpreté developpé afin de pouvoir concevoir des applications complexe tournant sur n'importe quelle machine physique dans les memes conditions grace à une machine virtuelle et en toute securité grâce à l'isolation de cette machine virtuelle para rapport à la machine physique.

Le Java n'a donc rien à voir avec le Web. Les applets ne sont qu'une facette de son utilisation.

Et pourquoi protéger du code javascript ? Il est à ce point incroyablement génial ? Un système de menu revolutionnaire ?

[Hibou57]

Alut Buzz Toujours aussi fidèle à ce fil je vois

Le Java n'a donc rien à voir avec le Web. Les applets ne sont qu'une facette de son utilisation.

Oui, c'est des applet que je parlais, seulement des applets.

Et pourquoi protéger du code javascript ? Il est à ce point incroyablement génial ? Un système de menu revolutionnaire ?

Non, rien de révolutionnaire. Mais plusieurs raisons. La première est que je trouve JavaScript un peu pénible quand le volume de code devient important. Alors ça m'aurais fait plaisir : Java, c'est quand-même mieux structuré et plus fiable. Ensuite, l'autre raison, c'est la vitesse d'execution qui est meilleur en Java qu'en JavaScript. Pour le code, tu me demande pourquoi il devrait être caché : je peux te renvoyer la même question... pourquoi ne le serait-il obligatoirement pas. Comme je disais, c'est pour éviter les modifications non-désirée, et la copie bête et méchante. En plus, je pense que pour ouvrir un source, il faut qu'il soit sérieusement documenté. Et pour l'instant ce n'est pas le cas, et plutôt que d'ouvrir un source qui n'est pas mûre pour ça, je préfère encore le fermer.

C'est incroyable comme ça peut déranger de vouloir empêcher la copie... à croire qu'il y en a qui ne vivent que de ça ? C'est quand-même pas un drame non si on empêche la coipie d'un code ? Aprés tout, on a pas non-plus toujours directement accés au code des binaires compilé.

De toute façon, je pense qu'un code n'est jamais fait pour être modifier comme ça. Modifier un code, équivaut pour moi à la reformulation de son architecture, et je constate que les code ouvert que l'on voit ça-et-là sur le web, ne sont pas assez documenté pour le permettre. Alors je me pose des questions sur les réelles motivation : par jeux ? Par volonté d'appropriation ? Posseder pour posseder ? Ou autre choses ?

De toute façon, les applications ne sont pas conçues que pour les développeur... alors même si cette volonté de protection gêne les développeurs (on se demande bien pourquoi), je sais que par ailleurs et pour certaine catégorie d'application, les utilisateurs/developpeurs ne représentent qu'une petite part.

Que des gens qui travaillent ensemble sur un projet s'échnage leurs codes, c'est normal... mais que n'importe s'approprie le produit de n'importe qui, c'est une autre histoire.

Même s'il y a des exception : comme le fait d'avoir le code source d'une librairie fourni avec un compilateur par exemple. Là c'est ok, mais rien, toujours dans cette exemple, n'oblige à ouvrir le code du compilateur lui-même par exemple. Il faut que ce soit justifier par le nature du code. Sinon, comme je disais, s'il y a collaboration étroite, c'est différent... mais là, il faut bien sûre se mettre d'accord, et savoir où on va ensemble (la personne avec qui ont décide de travailler)


Voilà,

[buzzkaido]

C'est incroyable comme ça peut déranger de vouloir empêcher la copie... à croire qu'il y en a qui ne vivent que de ça ?

C'est pas ça, mais bon, proteger le code C++ ou Java ou autre d'une application complete, bien sûr je suis pour dans la pluspart des cas.

Le code javascript n'est (en principe) qu'une faible partie du code d'une application Web. En general le code réélement interressant d'une telle appli est dans la partie serveur du code.

Et tout developpeur serieux preferera recoder le javascript plutot que d'utiliser du code qui vient d'on ne sait où, recupéré sur un site.

La question que je me pose n'est pas "Pourquoi proteger du code ?" mais plutot "Est-ce bien utile de dépenser du temps et de l'energie à proteger du javascript ?"

[Hibou57]

Le code javascript n'est (en principe) qu'une faible partie du code d'une application Web. En general le code réélement interressant d'une telle appli est dans la partie serveur du code.

Beh mon problème est justement là : même s'il y a une partie de le serveur, ce n'est qu'initiale et finale. Entre les deux, tout est entièrement en JavaScript. Mais bon, ça avance quand-même, et j'adapte (de toute façon, je veux quelque chose qui ne soit pas trop lourd)

Et tout developpeur serieux preferera recoder le javascript plutot que d'utiliser du code qui vient d'on ne sait où, recupéré sur un site.

Dans ce cas là, ça s'appel récupérer une information. Mais pour ça il y a mieux que les code : il y a des documentation de référence, les forums, etc. Protéger un code ne signifie pas qu'on ne communique pas.

La question que je me pose n'est pas "Pourquoi proteger du code ?" mais plutot "Est-ce bien utile de dépenser du temps et de l'energie à proteger du javascript ?"

Oh non, rassure toi, je n'y dépense aucune energie, et je n'y passe pas une seule seconde. C'est surtout qu'il y a des avantages connexes : réduction de la taille du code avec l'obfuscation et meilleur structuration avec Java.

Si cela avait des impacts négatifs, je n'y penserai même pas, ou alors je le ferais tout autrement. D'ailleurs je n'ai même pas encore appliquer les solutions que je donnais dans ce fil à mes propres codes... c'est dire... (de toute façon, ce n'est pas encore terminer, et ça avance trop doucement... plein de petit trucs tatillon et de choses de ce genre)

[buzzkaido]

Ben dans les impacts négatifs, si tu compte utiliser Java :

- dépendance vis-a-vis de la présence sur le poste client d'un machine virtuelle java
- dépendance vis-a-vis de la Machine Virtuelle utilisée (Sun ou Microsoft)
- dépendance vis-a-vis de la version de Machine Virtuelle utilisée (Sun ou Microsoft)
- le navigateur doit accepter les applet

La principale contrainte dans tout ça est la premiere, evidemment, les autres sont en general OK.

Mais il y a aussi la gourmandise : une VM Java est relativement lourde.

Il y a peut-etre une autre alternative au Java : le flash.

Pour en avoir fait un peu, il me semble que tu peux acceder au DOM de la page, mais je suis pas sûr. Et c'est plus utilisé que les applets, donc en général plus souvent installé sur les postes clients.

Après, evidemment, ça depend si c'est pour une utilisation grand public ou en interne dans ta boite.

Tout ceci etant dit, pourquoi des boites comme Google ou Yahoo qui ne font pratiquement que du web ont developpé leurs API en javascript et pas en Java ou en Flash ?

Probablement pour une histoire de coût : les tests sont bien moins lourds en Javascripts, la technologie est maitrisée par beaucoup de monde, la fiabilité est presque à 100%, la compatibilité aussi...

Car quand Sun (ou autre)sort une nouvelle version de sa VM Java, en général pas de soucis, mais les incompatibilité arrivent... et là, c'est le drame !

[Hibou57]

Ben dans les impacts négatifs, si tu compte utiliser Java :

- dépendance vis-a-vis de la présence sur le poste client d'un machine virtuelle java
- dépendance vis-a-vis de la Machine Virtuelle utilisée (Sun ou Microsoft)
- dépendance vis-a-vis de la version de Machine Virtuelle utilisée (Sun ou Microsoft)
- le navigateur doit accepter les applet

La principale contrainte dans tout ça est la premiere, evidemment, les autres sont en general OK.

Le problème est aussi que la JVM n'est installé en standard qu'avec Windows98, et non pas avec Windows XP (parce que Microsoft avait quitté le projet de Sun entre temps). Rien que pour cette raison, j'ai décidé d'abandonner l'idée d'employer Java.

Mais il y a aussi la gourmandise : une VM Java est relativement lourde.

J'ai abordé involontairement cette qestion sur la section Java du forum... et là, j'ai été plutôt mal acceuilli... la question est apparement tabou. Alors j'ai eu un sourire aimable en te lisant écrire cela

Il y a peut-etre une autre alternative au Java : le flash.

Pour en avoir fait un peu, il me semble que tu peux acceder au DOM de la page, mais je suis pas sûr. Et c'est plus utilisé que les applets, donc en général plus souvent installé sur les postes clients.

Flash est désactivé sur beaucoup de poste également, donc ça ne me convient pas. Sans compter qu'il y a chez flash une course à la version que je n'aime pas (mais ce ne sont pas les seuls, c'est pareil avec java... à part que Java-1 reste un standard à part-entière, malgré les versions qui ont suivi)

Après, evidemment, ça depend si c'est pour une utilisation grand public ou en interne dans ta boite.

C'est pour du grand publique... je ne travail pas pour une boite, mais je travail seul (j'essai, je vais créer une appli qui aura une version gratuite et une version payant... c'est un coup d'essais)

Tout ceci etant dit, pourquoi des boites comme Google ou Yahoo qui ne font pratiquement que du web ont developpé leurs API en javascript et pas en Java ou en Flash ?

Pour ne pas perdre de client, c'est-à-dire pour des raisons d'accessibilité. Comme tu le souligne, la disponibilité de Java sur la machine hôte n'est pas garantie, ... et la disponibilité de flash est loin d'être aussi automatique qu'on ne le pense. Et même javascript est désactivé chez un nombre non-négligeable d'internaute (mais bon là, on ne peut rien faire, il n'y a pas d'alternative)

Probablement pour une histoire de coût : les tests sont bien moins lourds en Javascripts, la technologie est maitrisée par beaucoup de monde, la fiabilité est presque à 100%, la compatibilité aussi...

... peut-être pas de cout... mais pour éviter des pertes, oui, c'est sûre. Je ne pense pas que le cout des testes d'une application flash fasse peur à Google c'est surement pas ça....

Car quand Sun (ou autre)sort une nouvelle version de sa VM Java, en général pas de soucis, mais les incompatibilité arrivent... et là, c'est le drame !

Oui, c'est pour ça que j'ai un faible pour les anciennes technologies, car plus stable et plus peireine.