Forums : Extensions

tiens, d'ailleurs, j'y pense, ça ne revient pas au principe des applis webs classique HTML ton truc ? HTML ~ ton format XML, et PHP/JAVA, les programmes qui font tout coté client, evenementiel et traitement metier

Si mais personnellement, je préfère partir de l'existant et tenter de compléter/fiabiliser/normaliser un fonctionnement déjà existant que d'innover a partir de 0 pour se rendre que finalement oups... on avait oublié des choses...

Ce que je voulais dire, c'est qu'apprendre un langage ou un format XML, c'est kiff kiff, surtout pour un informaticien

l'apprentissage à la limite : quoi d'apprendre une structure de données XML est du ressort d'un informaticien comme d'a peu pres n'importe qui disposant de bon outil xml du marché.

Mais je voudrais surtout parler de la mise en oeuvre. Avec un langage tu as 10 00 facons de faire la meme chose tandis que lorsque tu dois fournir des données dans un format XML précis et bien tu ne te poses pas 36 000 questions. Là est la différence philosophique a laquelle tu sembles etre volontairement insensible ;-P.

hum... XHTML = format XML pour stocker les données d'un document XML. As ton avis, c'est inutile d'avoir des formats standardisés ? Pourquoi crois tu que le W3C, l'OASIS, ou encore l'ECMA existe ? Pourquoi crois tu que certains veulent que XUL soit normalisé ? Pourquoi crois tu que SOAP, RDF, DOCBOOK et plein d'autres formats pour des données industrielles ou autres, sont normalisés ?

Oui tout a fait je suis entierement d'accord. C'est d'ailleurs bien que tu le dises toi meme pour montrer que je ne fais pas de pub raccoleuse.

C'est pas par hasard que je suis venu ici chercher des personnes interessées mais parceque je cherche des personnes sensibilisées a tous ces aspects ;-P

C'est dans les formats XML que la notion de norme prend toute sa valeur et beaucoup moins pour un langage. On comprendra ainsi pourquoi je préfère préciser qu'il n'y a pas de nouveaux langages a apprendre mais seulement un format XML, alors oui, comme tu le dis qui devra etre normalisé.

Je tiens tout de suite a vous rassurer : ce problème de norme a bien entendu été anticiper depuis longtemps mais ne devrait pas poser de problème bien au contraire...

Tout ce qui concerne les évènements fait bien entendu déjà l'objet de normes par le W3C, le contraire serait inquiétant et voudrait dire que pas grand chose dans firefox n'est finalement normalisé.

Effectivement dans firefox il y a aussi des evenements des gestionnaire d'evenement etc, etc .... le projet n'a pas du tout besoin d'une autre norme, nous utiliserons donc la meme que firefox pour la liste des évènements possibles et inimmaginables :

http://www.w3.org/TR/DOM-Level-2-Events/

et une norme supplémentaire très légère pour le gestionnaire des évènements XML Event du W3C :

http://www.w3.org/TR/xml-events/

De plus si certaines petites choses ne seront pas normalisées le principal le sera, d'ailleurs tu le dis toi meme XUL non plus n'est pas normalisé.

Par manque de temps c'est vrai que j'ai fait pour l'instant ma propre structure mais bien sur il va de soit qu'il faudra changer ca. Je vous rapelle que c'est quand meme un nouveau projet c'est normal qu'il ne soit pas parfait alors qu'il n'a pas vraiment encore commencé.

Je prendrais un exemple assez simple. Imaginons une liste d'information, déjà récupérée via un web service, placée dans un <tree> en XUL, sur plusieurs colonnes. Imaginons que l'on veuille pouvoir trier sur une colonne quand on clic sur l'entête.

Très bon exemple regardons ca de plus pret ...

Dans ton cas, quand on clique, il faudra envoyer l'évènement sur le serveur,

oui allé 2k de données a tout cassé ...

recuperer les données triées (donc requete SQL et tout le bazar),

déjà pas besoin de requete SQL, il suffit de travailler sur les données déjà affichées, si tu n'as pas besoin de remettre a jour par rapport a ce qu'il y a en base c'est complétement inutile.

Donc oui un tri effectué sur le serveur.

les reintegrer dans le <tree>, et réafficher.

oui le serveur renvoie par exemple une liste triée des id des items; le client reclasse les lignes du tableau... Parfait tout roule parfaitement...

Je te laisse deviner, pour une liste de 3000 items par exemple

il est vrai que présenter comme ca, il y a un probleme, mais dans du 100% client il y a aussi un gros probleme. Effectivement on va vite proscrire de telles pratiques : imagine la situation ou toutes les applications webs dans tes différents onglets firefox faisaient ca et bien les utilisateurs seront obligés de fermer toutes les applis autres que ton navigateur pour pouvoir travailler correctement... un peu limite quand meme, non tu trouves pas... ?

__Donc on n'affichera pas de toute facon jamais 3000 lignes, en tout cas pas sur des données qu'on est suceptible de trier. On sera donc bien entendu obligé de paginer comme ce qu'on le fait actuellement et c'est la d'ailleurs ou je veux maintenir en venir...

Il va y avoir là un problème dans ton architecture 100% client imagine que tu veuilles ... attention... effectuer un tri dans ta liste paginée (c'est le boomerang qui revient ;-P ) hé bien a moins d'avoir "downloader" tes 3000 lignes (présentées sous forme paginées) et bien tu seras de toute facon obligée de faire un petit tour du coté du serveur, je suis désolé mais on y revient toujours de toute facon...

non, je veux dire qu'à mon avis, il n'y a pas besoin de tes specs pour faire la même chose en plus simple et plus performant.

oui et bien tu vois que ce n'est pas sur du tout...

Bon, j'arréte là ma philosophie geekeste

ouais on en ait tous au meme point ;-)

Mais si tu penses le contraire, il n'y a pas de problème

oui j'avais déjà pensé a ce que tout ca mais ce débat etait nécessaire.

J'attend toujours une personne prete a se lancer et j'espère que ce message vous aura convaincu de rejoindre ce projet qui j'en suis sur a de l'avenir pour peu qu'on y croit... Je laisse mon email perso pour ceux interessés : mimounl@gmail.com.

Et bon week end a tous ;-)

Je trouve cette discussion surréaliste.

Pour commencer, deux remarques:

• À partir du moment où toutes les informations doivent transiter par le réseau tu perds toute garantie de sécurité, probablement même si tu cryptes tout (cf. Needham-Schröder et autres attaques man-in-the-middle).
• Une des raisons pour lesquelles on essaye de limiter les transferts réseau est que les communications sont fragiles, i.e. tu ne peux pas garantir que ta communication va vraiment arriver, encore moins combien de temps elle va prendre.

Ensuite, quelques questions:

• Je me trompe ou tu es en train de réinventer le Minitel, en plus compliqué ?
• Est-ce que tu es capable de citer trois "killer apps" différentes pour w-windows ? Par "killer apps", j'entends des applications utiles et impossibles à faire sans ou pour le moins vraiment facilitées par cette technique. Sans cela, je déconseille de te lancer dans l'expérience.
• Tu comptes mettre quoi exactement du côté client ? Juste l'affichage, sans aucune ligne de code ?

Tu comptes mettre quoi exactement du côté client ? Juste l'affichage, sans aucune ligne de code ?

Tiens, ça me fait penser à un système existant et qui a largement fait ses preuves depuis presque 20 ans : X-Window. w-window repose en fait sur les mêmes principes (tout évènement du client est transmis au serveur, enfin, c'est plutôt l'inverse dans X-Window, le serveur est appelé client, et client le serveur), sauf qu'avec w-window, tout est formaté en XML. Donc multiplication au moins par 10,20 ou 50 des données transmises. La bande passante va en patir ! Et donc la réactivité aussi. Quoique c'est peut être moins grave que je ne le dit, même si l'inflation sera tout de même présente : car dans w-window, il ne semble pas que les évènements souris soient transmis (le serveur ne peut pas être informé de la position de la souris par exemple). Mais cela va être un manque pour le drag and drop par exemple. (comment en effet dans ce cas, sans information de la souris, montrer à l'utilisateur qu'il peut lacher ce qu'il drag au dessus de tel ou tel composant ?)

Déjà qu'en réseau bien chargé, on ressent des ralentissements dans X-Window. Y en a même qui râlent même quand le serveur et le client sont sur la même machine ! (c'est un vieux troll parmis les linuxiens par exemple, pourquoi avoir X-window sur une machine desktop). En tout cas, à puissance égale, sur des machines moyennement puissantes, on voit bien une différence de réactivité entre un système d'interface à communication directe (genre windows) et une passant par le réseau (x-window). Pourtant le protocole x-window est super optimisé (les messages évènementiels se comptent en octet, et pas en dizaine/centaines d'octets comme ce sera le cas dans w-window). Et il n'y a rien de plus agaçant dans une interface utilisateur quand il faut attendre qu'un menu se déroule par exemple.

Je te propose, free_zy, de jeter un coup d'oeil à la spec X-Window. Cela te donnera l'ampleur de la tâche, et tout ce qu'il te faut implémenter (car je pense que tu as oublié certains aspects). Je pense que tu verras alors que ta solution n'est pas super viable (en tout cas, je n'en suis toujours pas persuadé). À moins d'avoir comme poste de travail des machines dernières générations à 3ghz, et avoir un réseau en gigabit... Et encore..

Continuons à disgresser sur X-Window : pour une utilisation en local, typique d'un desktop Linux, X-Window n'utilise pas de couche réseau "lourde" sur socket IP, mais utilise un socket local beaucoup plus efficace (man socket, regarder PF_UNIX). Le plus gros problème avec X-Window, c'est la librairie XLib : bien que le protocole soit asynchrone, XLib est synchrone pour certaines fonctions, et ça n'aide pas pour les perfs... Voir par exemple http://www.rahul.net/kenton/perf.html pour des explications.

À partir du moment où toutes les informations doivent transiter par le réseau tu perds toute garantie de sécurité, probablement même si tu cryptes tout

oui mais c'est deja plus ou moins le cas, non ?

Une des raisons pour lesquelles on essaye de limiter les transferts réseau est que les communications sont fragiles, i.e. tu ne peux pas garantir que ta communication va vraiment arriver, encore moins combien de temps elle va prendre.

oui et j'espere bien qu'un jour cela évoluera un peu tout de meme ;-P

Je me trompe ou tu es en train de réinventer le Minitel, en plus compliqué ?

Je ne vois pas trop le rapport avec le minitel. En tout cas pour avoir un peu utilisé le minitel dans ma jeunesse ;-) (hé oui deja 15 ans...;-P) j'espere bien que le resultat ne sera pas le meme.

Est-ce que tu es capable de citer trois "killer apps" différentes pour w-windows ? Par "killer apps", j'entends des applications utiles et impossibles à faire sans ou pour le moins vraiment facilitées par cette technique. Sans cela, je déconseille de te lancer dans l'expérience.

je ne me rallie pas specialement a ce concept de "killer apps" pour déterminer la qualité d'une idée. En tant qu'argument marketing ou indicateur économique pour plus d'information, le document d'introduction et de spécifs donnent les avantages de w-windows.

Tu comptes mettre quoi exactement du côté client ? Juste l'affichage, sans aucune ligne de code ?

exact en fait en résumé, voici l'idée de base :

on ne peut jamais "tout" mettre coté client car il y a toujours des cas ou un aller/retour serveur sera bien plus pratique a réaliser pour mettre à jour la page du navigateur. Donc autant tout centraliser au seul endroit ou on peut le faire : sur le serveur

Quoique c'est peut être moins grave que je ne le dit, même si l'inflation sera tout de même présente : car dans w-window, il ne semble pas que les évènements souris soient transmis (le serveur ne peut pas être informé de la position de la souris par exemple)

oui tout a fait. En fait quand tu construis une page w-windows tu définies dans un ficher "XML Event" les évènements suceptibles d'etre trasnmis au serveur. Alors en théorie tu pourrais aller jusqu'a transmettre a tout instant la position de la souris (si tu définis cet évenement dans ton fichier "XML Event") mais là oui bonjour la bande passante. Nous sommes en protocole non connecté donc il ne faut pas tomber dans l'autre extreme non plus ;-P

Mais cela va être un manque pour le drag and drop par exemple. (comment en effet dans ce cas, sans information de la souris, montrer à l'utilisateur qu'il peut lacher ce qu'il drag au dessus de tel ou tel composant ?)

Pour répondre au besoin dans ce cas, (par exemple car il faudrait valider ce fonctionnement :) je pense que tous les composants graphiques seraient suceptibles de recevoir un objet qui a été "pris" par le curseur de la souris.

Puis au relachement de la souris a la fin du "drag and drop" on transmet l'évènement au serveur avec en paramètres, le composant source et target au serveur.

C'est bien sur au navigateur de mettre en oeuvre ce fonctionnement qui serait spécifié toujours dans le document de spécification W-Windows.

Déjà qu'en réseau bien chargé, on ressent des ralentissements dans X-Window

oui mais le but de w-windows n'est quand meme pas de faire du pur x-window en transmettant absolument toutes les actions sur l'interface. Alors meme si c'est vrai qu'on pourrait peut etre perdre un peu de fonctionnalités je pense vraiment qu'elles seront très mineures.

Mais tout cela est mon avis très personnel mais aussi tres sincère.

Cela montre en tout cas qu'il y a pas mal de reflexions interessantes sur le sujet mais qui pourrait aboutir sur un projet super sympa alors si cela vous interesse n'hésitez surtout pas a me contacter...

Bon week a tous

La version 1.5 de xwidglets qui sort ce mois ci me semble t'il ,propose désormais l'utilisation de code java behind. Plus de javascript, du java seulement. plus de code spaghetti une seule classe java est associée à une seule fenêtre xwidglets. xWidglets propose donc une solution cliente permettant également de faire ce que tu veux faire coté serveur ;-)) et le tout avec une environnement de développement rad complet. Il me semble que le site à également changé voir : http://www.xwidglets.com

mais la version 1.5 ne semble pas encore visible à ce jour sur ce site.

a+

p

mouais mouais mais on est tourjours coté client...

Bonjour je n'arrive pas a ouvrir un document XML. Comment faire merci de me repondre isabelle