Le 08/12/2010 15:42, Benjamin POUSSIN a écrit :
Les actions ===========
L'idée général est d'avoir quelques actions de base mappées sur un path (ex: /view/ -> action view) Devant cette action on détermine sur quel context on fait l'action (WikittyService). Le reste de l'url sont des arguments pour l'action.
Les actions de base sont:
* ''login'' * ''view'' * search * ''edit'' * ''raw'' * ''eval'' * ''admin''
Ca me semble pas trop mal, ça ressemble beaucoup aux actions de XWiki ;)
Format des URL ==============
la syntaxe complète d'une url est::
/[context]/[action]/[mandatory_args]?[args key=value]
* ''context'' est le context pour trouver le bon WikittyService * ''action'' est le nom de l'action à effectuer, la classe gérant cette action est trouvée dans le fichier de configuration * ''mandatory_args'' sont des arguments obligatoires pour l'action * ''args'' sont des arguments optionels pour l'action sout forme de paramètre de requête
Encore une fois ça ressemble beaucoup à XWiki
Développement d'application ============================
Le but est de pouvoir facilement développer des applications avec ces outils abituels (editor, svn, ...). Pour cela on utilise l'application d'extraction de WikittyPubText et WikittyPubData. Cette application permet de récupérer l'ensemble de ces types d'objet en fonction d'un Label qu'ils ont. Il faut donc que l'ensemble de ces objets pour une application donnée est un Label en commun.
Ok, donc tu les récupère, depuis un WikittyService sur ton système de fichier. Est-ce qu'il garde l'arborescence des Labels ? Tu fais comment pour les types d'objets que tu crées (tes extensions). J'ai pas vu comment tu comptais les créer dans le WikittyService. Si je comprends bien la logique du bouzin, tu as un serveur WikittyService sur lequel tu as pas forcément la main (ton serveur de prod). Tu crées ton appli dans des fichiers sur ton filesystem, tu te lances un serveur WikittyService à toi sur lequel tu peux tester ton appli. Comme tu as la main dessus, tu peux créer des extensions,..., par contre comment tu fais pour les créer sur ton serveur de prod (elles sont aussi stockées dans des fichiers ?) ? Et en fait idem pour tes données. Admettons que tu veux aussi copier des données d'un contexte à un autre (backuper une base de prod sur une base de test). tu passes par des fichiers ? Une réplication (comment on fait alors si on a pas la main sur le serveur de prod) ? En fait, ça ressemble beaucoup à XWiki, par contre, un des intérets de XWiki est que tes types d'objets sont aussi exportés en fichiers, tout comme tes données. Je n'ai pas vu ça dans ta description (mais j'ai peut-être mal lu...)
Déploiement d'application =========================
Il est bien sur possible d'utiliser l'application avec tous les sources dans Wikitty. Mais il est aussi possible d'utiliser l'application en extrayant les sources dans des fichiers et les packagers dans un war. Dans ce cas l'application est vigée et n'est plus modifiable à l'exécution. Pour cela on utilise la servlet WikittyPublicationExternalize qui au lieu d'aller chercher les WikittyPubText et WikittyPubData dans le WikittyService va les chercher sur le système de fichiers.
Dans le mode externalize les jsp et autres resources peuvent être précompilées.
On peut donc avoir deux modes de mise en production suivant la taille du site ou le moment de mise en production. Par exemple pour les sites à fort volume la solution externalizée sera privilégiée ou pour les sites qui souhaites mettre à deux endroit différent l'application et les données pour des raisons de sécurites.
Au contraire lors d'une phase de prototypage ou si l'on souhaite pouvoir modifier facilement l'application on utiilsera le déploiement avec l'application dans Wikitty.
Intéressant ça.
Statistique d'accès au pages ============================
RAS
Plugin Maven ============
Il serait intéressant d'avoir les goals suivant pour maven:
* ''wp-commit'' pour commiter les fichiers sur un WikittyService * ''wp-run'' lance un conteneur de servlet avec le war wikitty-publication, pousse les fichiers dans ce service pour tester en local * ''wp-verify ''essaie de compiler tout ce qui est compilable pour ressortir les erreurs * ''wp-package'' qui package l'application en mode externalize, et précompile les jsp et autres resources
*''wp-checkout'' pour checkouter un WikittyService Je dirais pas intéressant, je dirais impératif. Si tu as pas ton plugin Maven, je pense que les gens vont s'arracher les cheveux pour les commits et checkout (comment tu appelles ton service à la mano tout ça tout ça ?)
Application Wiki ================
A voir à l'usage mais pour moi ça se rapproche de XWiki, peut-être même plus simple car dans XWiki des templates n'étaient pas éditable depuis l'appli elle-même
Authorisation d'accès aux pages d'une application =================================================
Une application est en fait stocké dans des Wikitties, une page de l'application est un WikittyPubText, il suffit donc de mettre les bons droits sur le wikitty de cette page pour permettre ou non aux personnes d'y accéder. Les données ont déjà la possibillté d'avoir des droits et ne sont retournés à l'utilisateur que s'il en a le droit.
Du coup on peut même afficher uniquement des bouts de pages suivant les droits des utilisateurs (il faudrait que si t'as pas les droits, tu retournes une chaîne vide quand tu es dans une page). Ca permet de faire de l'affichage conditionnel sur des pages sans faire plein de checks de droits
[TODO] réflechir comment faire pour le mode externalize