>* gestion de la video par le plugin flash,

quand ils passeront à XulRunner 1.9.1/Firefox 3.1, z'auront plus besoin de faire ça :-) (enfin, pour les videos ogg en tout cas, pas sûr que le backend gstreamer soit inclus à temps)

Et sinon, quand ils passeront à XulRunner 1.9.2/Firefox 3.2 (pas sûr du numéro de version), ils pourront faire du SMIL pour les animations/présentations, plutôt que faire du Flash :-)

[ Répondre ]

Et pour ceux qui n'aiment pas S5 (parce que c'est plutôt lent et lourd, sous Firefox en tout cas), il y a la possibilité de faire des pages HTML toute con, avec quelques classes bien placées (et que tu choisi), et tu installes l'extension FullerScreen pour Firefox, et c'est tout.

https://addons.mozilla.org/fr/firefox/addon/4650

En plus, ça gère le media projection, et donc tu peux donner une apparence différente entre la visualisation traditionnelle et la visualisation en projection. Ça pourrait très bien être une page "normale" d'un site (donc c'est lisible "normalement", contrairement à S5, et par tout navigateur, même des vieux trucs), et quand on la met en projection, on vire par CSS les menus, entetes, tout ce qu'on ne veut pas en projection quoi, et avec un design adapté :-)

http://disruptive-innovations.com/zoo/fullerscreen/samples/p(...)

Et puis FullerScreen inclus un "navigateur" pour aller directement à une diapo donnée, en affichant une liste des screenshots de ces diapos. (merci la balise canvas)

[ Répondre ]

ouuuhh là... Tu devrais te renseigner sur ce qu'on fait en PHP. Juste un exemple parce que je connais des devs de ces deux sites : les deux plus grosses plateformes de blogs françaises sont en PHP. (oui oui, une plateforme de blog, c'est une grosse appli, voir complexe, parce que cela doit apporter plein de fonctionnalités d'une part, mais aussi répondre à d'énormes contraintes comme la charge d'autre part)

Et je ne parle pas d'autres gros sites comme tf1, libé, lemonde.fr et cie.. Tous en PHP. Je pense ne pas me tromper en disant que parmis le top 10 des gros sites en france, la grande majorité sont en PHP.

Et je ne parle pas non plus de toutes ces applis métiers, intranet, complexes à souhait, en PHP (là c'est mon expérience qui parle).

>Le php de par sa nature bordelique et scriptee, non typee etc me parait une heresie pour developper une grosse appli.

Un peu de rigueur, de la programmation objet, et ça roule. Des applis propres en PHP, ça existent, et de plus en plus, grâce à l'utilisation de frameworks notamment, et à la "professionnalisation" des devs PHP.

En java, on peut en faire aussi du code très crade.

[ Répondre ]

Tellement mal racontée, que ce n'était, à l'époque, pas le fils d'un président, mais d'un ministre..

(oui, je chipotte)..

[ Répondre ]

> Mais avant de pouvoir envoyer des données au serveur, le navigateur doit d'abord afficher un formulaire à l'utilisateur. Ce formulaire peut être vu comme une représentation de la ressource à modifier, au même titre que du HTML simple.

Pourquoi faudrait-il absolument un formulaire ?

Un navigateur (en tout cas Firefox 3 et IE), ont des possibilités d'édition d'une page web.

1) il est possible de spécifier avec l'attribut contenteditable les élements de la page qui sont éditable (tout les navigateurs ne prennent pas encore en charge cet attribut, Firefox3 et IE le font en tout cas) http://developer.mozilla.org/En/Rich-Text_Editing_in_Mozilla
2) on active l'édition en tapant sur la touche qu'il faut (F7 dans Firefox)
3) l'utilisateur peut alors modifier les parties de la pages qui sont éditables

Il manque juste un bouton "sauver" pour sauver le contenu de la page (POST ou PUT). Il me semble que Mozilla Composer/Nvu permettent de le faire, mais à vérifier. Mais de toute façon, c'est simple à implémenter, même par le biais d'une extension (dans une extension, un coup de serialization du DOM.

Àprès, au niveau du serveur, sur un POST ou PUT, rien de plus simple que de récupèrer le contenu des éléments modifiés (tout ceux qui ont l'attribut contenteditable, avec l'aide d'un parser SAX ou DOM), et de les sauver en base dans différents champs si on veut.

Pour bien des choses, surtout quand il s'agit d'édition de contenu pure, on a utilisé les formulaire fautes de mieux. Les formulaires n'ont jamais été prévu pour ce genre d'utilisation à l'origine.

Cependant, c'est vrai que souvent les formulaires sont pratiques, surtout quand on veut limiter la saisie (afficher une listbox pour proposer des choix par ex). Mais plutôt que d'étendre le protocole HTTP, un truc plus simple serait d'implémenter un évènement dans le navigateur, qui permettrait à la page web de savoir quand est ce que l'on sort ou qu'on rentre en mode édition, et donc de permettre d'afficher/de faire disparaitre des élements de formulaire. Couplez ça avec les possibilités offline de certains navigateurs, ça peut en être sympa :-) http://developer.mozilla.org/en/Offline_resources_in_Firefox http://developer.mozilla.org/en/Online_and_offline_events

[ Répondre ]

Amaya aussi permet l'édition de pages distantes et sait faire du PUT, DELETE et cie.

>Après, il reste le problème de l'autorisation de modification de ressources Web ...

Il y a tout ce qu'il faut dans HTTP pour s'authentifier. Après au serveur web de savoir ce que l'utilisateur authentifié a le droit de faire. Par défaut, il me semble qu'apache se base tout simplement sur les droits systèmes des fichiers. Mais mettre un autre système de droit en place est possible aussi, puisque dans apache on peut utiliser une base de donnée mysql par exemple..

M'enfin un autre problème pour l'édition : ce sont les ressources "virtuelles", celles qui ne sont pas des fichiers physiques. c'est à dire le contenu généré à la volée. Là c'est au système de gestion de contenu de prendre en charge PUT, DELETE et cie... Malheureusement, tout les modules de langages ne prennent pas forcément correctement en charge ces méthodes. Dans PHP par exemple, pour PUT, il faut parser soit même le body de la requete, alors qu'il le fait très bien pour POST. Si du multipart/form-data, il met le contenu dans $_POST et $_FILES, si c'est du urlencoded machine bidule jesaisplusquoi, il met dans $_POST etc.. Et ça il ne le fait pas pour PUT, ce qui est embétant... Il me semble aussi que l'on ne reçoit pas les requêtes HEAD (à vérifier) dans PHP.

[ Répondre ]

consulter, oui, mais pas calculer.

Avoir une somme de contrôle correspondant à un fichier, c'est bien, mais il faut avoir le fichier pour calculer la somme et la comparer avec celle que l'on a récupéré, pour savoir si le fichier corresponds. Donc il faut nécessairement télécharger le fichier.

[ Répondre ]

Faudra m'expliquer comment on peut calculer une somme de contrôle d'un fichier que l'on a pas...

[ Répondre ]

Je n'ai pas dit que la AGPL interdisait d'apporter des modifications.

Ce que j'en ai compris de la AGPL :

- tu dois fournir les sources à tout les utilisateurs de l'appli web
- si tu fais des modifs, tu dois aussi les fournir

Ce qui veut dire que tout utilisateur de la boite, doit avoir accès aux sources, et donc même aux modifications qui pourrait concerner la gestion de données spécifiques et sensibles. Donc même aux utilisateurs qui ne sont pas habilités à connaître la présence/la gestion de ces données sensibles, car n'ayant pas de rapport avec eux ou le service dans lequel ils travaillent.

Si ce que j'ai compris est bon, je trouve donc ça très moyen de mettre un tel logiciel sous AGPL.

[ Répondre ]

Pas besoin d'une imprimante. Faut juste que tu branches un distributeur de billet sur ton laptop, via une prise USB, et un plugin flash gère la communication entre le navigateur et le distributeur.

C'est pourtant simple !!

Oui bon, faut se déplacer pour être à coté d'un distributeur de billet...

Mais il parait qu'ils vont améliorer ça, et bientôt les distributeurs pourront communiquer par wifi (parce que bon, se balader avec un cordon usb, c'est pas cool..).

Certains disent d'ailleurs qu'un jour peut-être, on n'aura plus besoin de prendre son laptop pour retirer de l'argent à un distributeur. Mouarf, y en a qui rêve quand même...

[ Répondre ]

>- la licence AGPL, c'est bien, mangez-en,

je trouve ça plutôt con, pour un logiciel utilisé en entreprise. Car cela veut dire que la boite ne peut pas apporter des modifications qui seraient propre à son fonctionnement, et donc des modifs qui ne sont pas forcément intéressantes pour les autres, encore moins si il s'agit de choses confidentielles.

Je n'aime vraiment pas la AGPL...

[ Répondre ]

Un peu de pragmatisme s'il vous plait.

"Bonjour, j'ai pris ma photo ici : http://www.openstreetmap.org/?lat=48.42924&lon=-0.86181&(...) "

Ouai.. super... vachement intéressant..


Je ne dénigre absolument pas le travail remarquable fait par les contributeurs à OpenStreetMap, mais en toute franchise, je ne pense pas que ce soit utilisable en l'état pour une application comme Vision2pixels..

[ Répondre ]

qu'est ce qu'on a à fiche de la somme de contrôle ici ? Le fichier a déjà été téléchargé avant de pouvoir vérifier cette somme. Et donc tu es déjà dans "l'illégalité" pour détention d'un fichier illicite.

(je dis pas qu'il faut pas vérifier la somme de contrôle hein... mais bon, dans le contexte...)

[ Répondre ]

>Sinon, pourquoi ne pas pomper le code de firefox ?

Le coeur de Wbekit/khtml est vraiment trop différent de celui de Gecko, pour pouvoir reprendre le code Mathml de Gecko.

[ Répondre ]

sauf qu'un test acid ne couvre qu'à peine 1% des specs. Et encore, mon chiffre est très certainement exagéré. (0.1% ?)

Bref, il va en falloir des tests acid ;-)

[ Répondre ]

Ça serait une chouette idée, mais c'est pas gagné. Apparement, le méthane semble se libèrer sur plusieurs centaines de kilomètre carré, et pas seulement à des points précis. Donc pour le récupérer...

[ Répondre ]

Non, je n'ai pas dit ça bien qu'en theorie ce serait possible (faisable même via une extension pour firefox si tu veux :-)). Webkit n'ont pas "triché" à ce point quand même (fort heureusement) :-)

Si j'ai bien tout compris, dans le test, il y a un truc dans le genre

if( element.laFonctionAnimationSmil !== undefined)
test ok.

Et dans webkit, cette fonction laFonctionAnimationSmil existe bien, mais elle ne contenait rien, elle ne faisait donc pas ce qu'elle était censée faire. (me rappel plus la fonction en question). c'est aussi un peu la faute du test de ne pas vérifier ce que fait la fonction, mais à la décharge de l'auteur du test Acid3 (Ian hickson), vérifier qu'une animation se fait bien, n'est pas très faisable en JS (puisqu'il faut vérifier le rendu..)..

[ Répondre ]

Je ne sais pas si webkit connait MathML, mais une page XHTML+MathML+SVG s'affiche très bien dans Firefox :-) ex: http://www.comfsm.fm/~dleeling/physci/ps83/energy.xhtml

[ Répondre ]

Oui et non. C'est en cours, et ce sera peut-être prêt pour la sortie de Firefox 3.1. En tout cas, y a déjà des trucs qui marchent dans une branche, mais c'est pas encore intégré dans le trunk. Le patch est entré dans le processus de review :-)

La page sur SMIL, (que j'ai moi-même crée :-) ), n'est pas tout à fait à jour, mais pour vous tenir informé, allez suivre le bug indiqué.

(je vais de ce pas d'ailleurs corriger cette page)

[ Répondre ]