Si tu es sur du PHP5 , normalement ton hébergeur t'as donné les 2 : MySQL, mais aussi SQLite car il fait partie de la librairie native de PHP5.
Pour voir toutes les extensions installées avec PHP (SOAP, SQLite, XSLT etc... ) , tu dois créer un fichier php (info.php par exemple) et taper :
<?php
echo phpinfo();
?>

Lance cette page sur ton serveur, tu verras toute ta configuration php et les extensions proposées

Ce serait long de tout t'expliquer en détail et j'ai pas vraiment le temps.

en revanche petite précision :
tu as pris un hébergement PHP et SQL. En fait, je suis quasiment sur que ton hébergement est basé sur une base de données MySQL. c'est un SGBR, une base de données installée sur un serveur avec comme adresse de connexion : l'adresse d'un serveur, port, login et mot de passe.

Ici nous parlons d'une base de données SQLite dont les pilotes pour s'y connecter par php sont installés en natif. Ce n'est pas un SGBDR mais une base de données "fichiers" utilisée pour un faible volume de données et peu de demande en bande passante. Pour se connecter il faut : l'adresse du fichier de base de données sur le serveur, login et mot de passe.

Donc toi je pense que tu parles du 1er cas : MySQL.
Dans ton interface d'administration de ton hébergement tu dois avoir la possibilité de créer une ou plusieurs bases de données. Lorsque ce sera fait, on te donnera son adresse, son nom , login et mot de passe. C'est ça qu'il faudra utiliser en PHP pour s'y connecter.

Bref, la je te résume en gros.

Il faudrait que tu t'achètes un bouquin sur PHP/MySQL, ou que tu regardes des tutoriaux et il faudrait voir qui est ton hébergeur précisément pour pouvoir t'aider concernant la création des bases.

Il existe des extensions Firefox très sympa pour administrer du SQLite, à commencer par :
https://addons.mozilla.org/en-US/firefox/addon/5817

J'ai développé toute une application avec, vraiment bien...

Tu peux bien sur exporter toute la base ou toutes les tables, et lancer le script sql en ligne, enfin bref, je pense que ça évite un tel script

Comme je l'ai dit sur ta source, la solution la plus simple est d'utiliser comme je l'ai fait, une classe qui gère le zip de façon indépendante.
Quelque que soit la plateforme le code reste le même.

Donc on revient bien sur le problème de ZipArchive... et contrairement à ce que tu disais dans un commentaire sur ma source modifiée de odtphp, il n'y a pas de "hack" possible et l'utilisation d'une classe externe pour le zip reste le plus simple et le plus portable.

En fait j'ai essayé les 2 et même si je n'ai plus de message d'erreur , le fichier est corrompu.. je pense que c'est à cause d'OO 3.1. Ca marche chez toi avec cette version ?

Ta classe est-elle compatible avec OpenOffice 3.0 ? Mon problème d'utilisation pourrait venir de la ?
Si non, ce serait bien que tu fasses évoluer ta classe pour OO 3.X

Ca l'air vraiment très bien et en plus il gère du word.
Malgré tout, pour OpenOffice je préfère un truc indépendant comme ODTPHP car ta source dépend de tinyButStrong. Ca peut être toujours un peu inquiétant pour l'évolution mais c'est un avis perso.

Sinon après installation (PHP 5.2.9) :

Fatal error: Uncaught exception 'tinyDocException' with message '"zip" not executable' in D:\wamp\www\tinydoc\tinyDoc.class.php:919 Stack trace: #0 D:\wamp\www\tinydoc\executeBasic.php(9): tinyDoc->setZipBinary('zip') #1 {main} thrown in D:\wamp\www\tinydoc\tinyDoc.class.php on line 919

D'ou cela pourrait il venir ? le même problème que dans la version de base d'ODTPHP ?

Salut,
je sais pas ce que tu entends par "Office on Writer v7" . Il te faut OpenOffice avec Writer installé en version 2 minimum. Moi j'ai testé avec open office 2.0 et avec la 3.0 (la dernière donc) et ça marche.

Sinon le fichier "tutorial1.odt" est le fichier "modèle" pour créer le document OpenOffice. En fait tu dois lancer le script "test.php" qui va générer un fichier generate.odt et te le proposer en téléchargement.

Au niveau des extensions, sous Wamp normalement il n'y a que php_zip à ajouter.
Es-tu bien en PHP 5.2.X ?

Simple et efficace, en effet ce code fonctionne bien. Ca me fait penser un peu à ce que j'utilise régulièrement : Xajax. Mais bien sur ce dernier est plus poussé (tu devrais jeter un oeil pour t'en inspirer dans tes versions futures).

Par contre je ne pense pas que cette source soit accès pour de gros projets. Au contraire, si on veut faire une petite appli web sans un gros script tel Xajax & co mais que l'on veut tout de même de l'objet et de la propreté côté javascript/php alors cette source est intéressante.

Pour une grosse appli, il faut aussi prendre en compte des frameworks tel Prototype ou ExtJS côté client et un framework côté serveur tel Zend Framework ou Symfony implémentant le MVC et les contextes (contexte ajax, contexte json...etc).

Exemple simpliste ExtJS et mon propre framework :  
Ext.Ajax.request({url:'http://monappli/controller/action',success: fonctionOk});

Avec prototype c'était à peu près la même chose, donc pas besoin de ta source.

En fait ta source ou Xajax n'interviennent uniquement que dans 2 cas :

- Pas de moteur de templates
ou
- Pas de motif type MVC côté serveur

Donc nous avons besoin de générer du HTML dynamiquement par PHP, auquel cas Xajax donne ce genre de code (encore trèèèèès simpliste par rapport aux possibilités de ce dernier) :

$reponseXajax->assign('monDiv', 'innerHTML', '<span> Test </span>');

J'ai intégré Xajax dans mon propre framework et finalement je le regrette un peu... Etant donné que j'ai intégré Smarty pour la partie "Vue", Prototype m'aurait largement suffit pour le web.
Et dans mes actions appelées par ajax j'aurais demandé à Smarty de me construire mon résultat, j'aurais donc toujours gardé la séparation des couches.
Enfin bon, Xajax propose tout de même d'autres trucs intéressants, donc c'est pas trop grave ; ) .

Pour info, je développe une appli en ce moment "Full Ajax" avec ExtJS et Zend Framework. Mes codes d'appels sont encore plus simples qu'avec ton script et les possibilités beaucoup plus grandes (gestion des proxy par exemple, validation automatique de formulaire selon paramétrage... etc).

Pour finir : Arto_800 tu as fait une bonne source et pour moi son avenir réside dans ses possibilités à générer du code HTML et l'injecter très précisément par DOM à l'instar de Xajax.

A+

ps : ceci est ma vision personnelle, notamment basé sur des choix pris à un moment donné. Il y a d'autres possibilités de faire de l'ajax simplement...