Reprise du message précédent :
:?

nan

strop facile tu me laisses gagner

non

http://forum.hardware.fr/forum2.ph [...] =0&subcat=

 
non, faudrait demander à lorill (strasbourg, tu y es bien )
 
edit: j'avas pas vu le topic  

 
oui
 
secousse ressentie jusqu'à Paris, Grenoble, Besançon, Genève etc...

C'était pour pas faire une partie nulle  
Grincheuse va

 
pas à Zurich  

bon d'accord, merci

Ouais bin Paris 12ème, j'en ai pas bougé, j'ai rien senti

ni à Montréal
 
   Bon je sors  

fake

tiens -- si tu as pas oublié :
https://rife.dev.java.net/
 
edit: j'ai pas encore lu pour bien comprendre

ha oui j'y ai repensé tout à l'heure, pas encore allé voir
gt en train de lire des trucs sur xml-rpc.
 
si qqun peut m'expliquer l'interet de ce gros bouzin de soap par rapport à xml-rpc, je suis preneur parce que là

 
je vais lire ca aussi mais donc ca fais sensiblement la meme chose

oui mais en 400x plus simple

 
dire que l'an dernier j'ai betement fais du SOAP parce que c'etait 'a la mode' et qu'on m'a dit d'en faire

-- Moment CSS : IE me casse les couilles --
 
Vous avez un truc simple et efficace autre que de foutre href="#" pour que IE tienne compte des a:hover de CSS ? Nan passke là ça devient bien casse-burnes, mes liens qui font du JavaScript quand on clique dessus, chu obligé de foutre uun href="#" pour que le hover soit pris en compte

 
ah ben j'avais pas revé alors

 
un an et un jour pile poil après celui de l'année dernière

on fait la meme chose ici.
 
non mais bon, y'a ptet un truc qui m'échappe, je sais pas, mais à priori je vois pas l'avantage.
"on dit" que soap est orienté objet, mais je vois vraiment pas en quoi.
la difference, c'est qu'avec soap, tu peux définir des types complexes. avec xml-rpc, tu peux aussi, mais tu dois dans ton code (si je comprend bien) les "traiter", tu reçois pas directement un "objet" de la part de ta couche xml-rpc.. m'enfin bon, spa la mer à boire, pis jsuis pas convaincu qu'une majorité d'implementations soap gerent les types complexes correctement.. en tous cas avec l'impl sur palm, c'est pas gagné

Bin SOAP, c'est un truc pensé et spécifié par le W3C. Pas XML-RPC. Vala, c'est tout. Et c'est aussi pour ça que SOAP gardera la cote auprès des entreprises

 
les liens vides c'est mal
 
ils font quoi ces liens pour ne pas pouvoir avoir de vrai href ?

Un menu déroulant

euh ok, mais pq ils ont fait un truc si complexe? c'est quoi la difference qui m'échappe?

ils pourraient mener à une page qui presente ces differents liens sous la forme d'une bete liste. (penser accessibilité)

Ah ba ça, faut leur demander

hmmm http://ink.inkdroid.org/talks/soap/xmlrpc.html

Non, j'donne plusieurs options. Imagine que chaque lien corresponde à un fichier sur le serveur et je veux pouvoir effectuer plusieurs opérations dessus : voir les infos, effacer, éditer, déplacer, etc... sans avoir à surcharger ma page principale de liens en tout genre. Si j'dois changer de page ou présenter une popup à chaque fois, ça risque d'être bien relou.
Quant à l'accessibilité, je mise tout sur Moz/IE. Les malins qui voudront jouer avec autre chose iront se faire foutre

euh qd je te parle d'accessibilité, je te parle de personnes qui ne peuvent utiliser ces browsers (et donc js par exemple) pour des raisons physiques, et pas de nerdz qui surfents sous emacs

et ske je te dis c'est que le lien qui ouvre ton menu deroulant pourrait pê mener vers une sous page qui présente ces liens

mais nan, c'est le tram qui passe à côté
 

SOAP ne fait pas que du RPC (bien que en principe il soit utiliser quasiment que pour ca). Il est extensible (ajouts de types de données), etc ...
 
...
 
non, en fait aucun. Soap c'est sale (ce qui est quand même un comble)
 

Les WebServices c'est l'avenir !
 

 
"On" est vraiment un sacré comic  
 

Soap n'a pas la côte auprès des entreprises, sauf des entreprises qui essayent de te vendre du soap (Microsoft, IBM, etc ...) avec leurs supers serveurs e-kekchose.net

et xml-rpc t'en penses quoi?

 
En effet, ça coûte rien de mettre au lieu de href="#" un href="map.html" où map.html contient tout le menu déroulé par ex, ou une carte du site, ou je ne sais quoi d'autre pour ceux qui ne peuvent pas utiliser le menu.
Bon si par contre si les items du menu ne conduisent pas à des pages mais à des actions qui sont liées au contenu de la page actuelle, là ça pourrait justifier de laisser tomber la navigation pour les non-JS-enabled.

disons que y'a quand meme une certaine demande pour l'invocation de "machins" à distance. là ou je bosse on pourrait faire des trucs terribles avec ça (mais non ils ont préféré inventer leur propre "protocole" à la con à base d'urls - sisi, ils ont appelé ça "protocole" - qui renvoient de l'html tout pourri et préformaté )

taiche >> en fait y'a un truc qui m'échappe: pourquoi tu fais pas apparaitre ton menu justement avec du css au lieu du javascript?

c'est une techno simple qui répond à 95% des besoins.
 
de la même façon que du XML over HTTP (avec une DTD et un fromat d'intérogation spécifique) répond à 85% des besoins.
 
C'est pas pour rien que ces 2 méthodes restent utilisés alors que SOAP et WSDL sont standardisés () depuis des années ..
 
Je parle même pas d'UDDI qui mérite un Oscar pour la plus grosse fumisterie de la décénie

ca rejoint la 2e méthode que j'ai donné, sauf que quand on afit un truc propre, un XML en retour c'est quand même plus sympa ...
 
Ce genre de solution n'a rien de dégradant : Si ca répond au besoin, y a pas à s'embêter

je suis a strasbourg, et j'ai meme pas senti la terre trembler..  

Je l'ai pas ressenti J'étais dehors à ce moment là.
 
Et pourtant pas mal de gens ici l'ont ressenti...