Reprise du message précédent :

 
En quoi un style architectural ne pourrait pas avoir d'explication claire ?

Parce que c'est plein de flou, et que ça demande de réfléchir à la correspondance entre ton problème et le style.

Voilà. C'est grosso modo du vent qui ne représente en fait rien de bien nouveau mais qui fait hype depuis un moment.

Dans ce cas faut expliquer clairement quelles sont les parties floues...
Ce qui se conçoit bien s'explique bien, flûte alors

Mais alors BenO, quand il demande ce qu'il y a de bien pour "faire du REST", il ne demande rien en fait ?

exactement

Il se branle la nouille comme les autres.
ça veut pas dire grand chose de concret, "faire du REST".

Non, c'est surtout des principes très "haut niveau", donc sauf à la limite à prendre un exemple précis et expliquer comment on va faire fonctionner le bordel dans ce cas précis, ben tu peux pas faire de la précision

Non mais les parties "floues", ce sont les parties qui correspondent à ton projet précisément.

Après si tu veux une overview à 10000 pieds qui ne sert à rien, REST est un style architecturel basé sur la prédéfinition de ressources (des types de médias) et leurs relations via des liens inclus à ces ressources.

Bah si

Après je doute très fort que BenO "fasse du REST", mais c'est un autre problème.

j'aimerais bien en faire

 
Je vois pas ce qu'il y a de concret là-dedans...ce ne sont que quelques principes très génériques avec à peu près autant de manière de les mettre en pratique que tu veux...

Non.
Tu veux faire comme tout le monde, ie faire le malin en disant que t'en fais.
Fais comme les autres, fais transiter tes données en JSON sur http avec un paquet de javascript coté client, ça suffira.

 
nan je voulais juste essayer http://code.welldev.org/django-roa/wiki/Home  (j'ai peut être pas besoin de "REST" d'ailleurs )
C'est pour communiquer entre deux serveurs donc du JSON ou autre (XML  ) tout court suffirait :x
 
Je cherche juste une solution pragmatique pour faire communiquer un serveur PHP/MySQL et un Django que je souhaite
utiliser comme interface d'administration de mon appli PHP.

 
Elle est censée faire quoi ton interface d'admin? stocker de la conf dans la bdd? Si oui, wtf? Si non, wtf?

 
rajouter/modifier des produits / news / user / etc

 
C'est des modifs dans la base de données, ça. Ton appli jango elle va pas "communiquer avec ton appli php", elle va mettre à jour la base.
Après si ça te fait plaisir de faire mumuse à coup de JScript/JSON rien ne t'en empêche.

J'espère que tu confonds pas REST avec CRUD

C'est quoi REST ? C'est quoi CRUD ? (google n'est pas mon ami )

REST c'est rien on a dit, et CRUD c'est Create-Retrieve-Update-Delete, les opérations de base d'une admin sur un type d'objet donné par ex.

Comment insérer du flash dans une page pour que ça fonctionne dans IE? J'ai mon code html qui marche FF/Safari, mais forçément IE a envie de faire chier.
 
J'ai mis une balise <object ...> avec un <embed ...> à l'intérieur. Y'a des pièges en particulier?

Utilise plutôt SWFObject.

Question Subversive :

Comment je pourrais mixer "svn export /test /prod" et rsync ?

Ie. faire un rsync des fichiers versionnés seulement
Ie. faire un export des fichiers modifiés seulement

une working copy sur le serveur, a un autre endroit que ce qui est visible par le serveur web.
 
svn update sur la wc, puis rsync de la wc vers le serveur web, en ignorant les .svn

Effectivement swfobect résoud le problème. Merci
 
Sinon Static VS Dynamic embed? En pratique qu'est-ce qui est le plus compatible, moins chiant à maintenir, etc?

Non, ça ça copie aussi les fichiers non versionnés

Si t'as Flash, t'as JS, en principe... Et en dynamique la syntaxe est plus courte, plus portable, plus simple, donc bon.

Tu fais un svn diff entre les 2 versions (l'option summarize rox), tu parses la sortie pour ensuite gérer les ajouts/suppression.

Ca marche ça, entre une WC (test) et une non-WC (prod) ?

On s'en fous de WC ou pas
Au niveau de la prod t'as bien un moyen de connaître la révision (ou un libellé de tag) de ce qui a été pushé ?
 
Si oui tu fais le diff entre la révision que tu veux pousser et celle de prod. Si tu la connais pas t'as un fail d'archi

Je la connais pas, car je déploie via un export de la WC de test (pas forcément commitée) vers prod

Je fais ça pour gagner en rapidité d'export (le repository est loin). Après je pourrais m'obliger à commiter la WC de test avant de déployer, certes...

ben non, s'ils ne sont pas versionnés, le svn update sur ta wc qui ne sert qu'a ca ne les aura jamais.

 
J'avais l'impression
 

 
Les deux serveurs sont sur deux machines différentes  
 

 
Je pense que si  

Et alors? Vos admins réseau et bdd sont trop cons pour ouvrir l'accès à la base sur une deuxième machine?

Ah ok, la WC n'est pas fonctionnelle quoi. C'est pas mal, ça pourra pas synchroniser les fichiers non commités mais tant pis. Toute façon vous allez me dire que c'est de déployer des fichiers non commités

 
c'est moi l'admin réseau et pis c'est pas mon métier le dev web toussa
 
Les deux machines sont sur deux réseaux différents (Google App Engine et serveur perso)
 
J'ai cru de bon usage de ne pas ouvrir ma BDD sur l'extérieur , me trompe-je ?

tu fais un filtrage par ip , en n'autorisant que les machines concernée à acceder a tes base et zou

C'est une idée faudrait que j'autorise la plage d'IP de GAE donc.

voilà.
Sinon il faudra :

1) Que tu développes une API/des webservices/un brol quelconque en php qui permette de faire la maj de tes tables.
2) Que tu trouves un moyen de sécuriser ça.
3) Que tu développes ton interface python qui fait appel à ton truc en php.

Au lieu de

1) permettre à ta machine hébergeant le python (et elle seule) d'accéder à ta base.
2) développer l'appli python en écrivant directement dans la base.

Sachant qu'en plus, un API HTTP protégée par un MDP pour accéder à la base, c'est pas foncièrement différent d'un accès MySQL sans restriction d'IP

Voilà.
Il peut aussi installer son API HTTP sur un second virtualhost avec un port différent, et il filtre coté réseau...mais ça reviens à filtrer l'accès à la bdd.