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.