> Ca m'étonnerait que ça possible : on est sur le web, hein, pas dans une
> grosse appli locale...
- La première grosse limite, c'est qu'en général ce genre de chose te fait
perdre la main sans prévenir. Ce qui est, genre, insupportable.
Oh! Je me suis mal exprimée. L'autosave ne va pas écrire dans la base
spip, bien entendu, mais dans un fichier qqpart, dans le /tmp ou
un répertoire configurable, peut-être en local. Comme le font les
outils de mail, editeurs etc que j'utilise. Ainsi, si la connexion
se casse ou autre, peu est perdu.
- local = interdit : un navigateur n'a pas le droit d'accéder au disque
- distant = un post dans un coin, par exemple dans un fichier attaché à
ta session, pourquoi pas. mais dans ce cas, faut aussi un système pour
récupérer l'autosave.
Oh! Je me suis mal exprimée. L'autosave ne va pas écrire dans la base
spip, bien entendu, mais dans un fichier qqpart, dans le /tmp ou
un répertoire configurable, peut-être en local.
- local = interdit : un navigateur n'a pas le droit d'accéder au disque
Si, il le peut. Il y a une fonction (sous Netscape) qui fait s'afficher une grosse fenêtre compliquée, de demande d'autorisation...
Puis, le script peut continuer, les fichiers sont écrits sur le disque à partir du dossier de l'application.
Sur MSIE, je n'ai pas essayé à l'époque (il y a si longtemps...)
- distant = un post dans un coin, par exemple dans un fichier attaché à
ta session, pourquoi pas. mais dans ce cas, faut aussi un système pour
récupérer l'autosave.
Je vous met en garde: écriture de fichier par le PHp sur free.fr: c'est tellement lent....
risque d'erreur 500 (time out)... j'ai déjà essayé pour des tout petits fichiers.
Sur free.fr c'est vraiment pas bien.
C'est aussi ça qui rend l'inclusion d'image si problématiques, même les logo passent mal, il faut s'y reprendre à plusieurs fois, ou bien le faire en envoyant les fichier avec le bon nom. (faire le travail à la place du PHP de SPIP)