Author: echatellier Date: 2009-08-28 16:56:14 +0200 (Fri, 28 Aug 2009) New Revision: 1634 Added: trunk/topia-ui/src/site/rst/UseCaseProblems.rst Modified: trunk/topia-ui/src/site/rst/index.rst trunk/topia-ui/src/site/site.xml Log: Ajout de la doc topia UI. Added: trunk/topia-ui/src/site/rst/UseCaseProblems.rst =================================================================== --- trunk/topia-ui/src/site/rst/UseCaseProblems.rst (rev 0) +++ trunk/topia-ui/src/site/rst/UseCaseProblems.rst 2009-08-28 14:56:14 UTC (rev 1634) @@ -0,0 +1,160 @@ +Différentes approches pour la reutilisation +=========================================== + +Solution simple +--------------- + +Réutilisation des vues +~~~~~~~~~~~~~~~~~~~~~~ +Cette approche consitait à produire un grand nombre d'états supplémentaires +qui utilise des vues en commun. + +Au sein de tapestry cela revient à un héritage de composants entre eux (un +composant sans vue hérite de la vue de son parent). +Le code produit devient tout de suite moins clair et on arrive vite +a un nombre exponentiel d'état. + +Note: Solution non envisageable. + + +Use case +-------- +Les use case paraissent nécessaire pour pouvoir réutiliser des états. Certaines +actions deviennent donc ambigues et doivent recuperer des informations pour +rediriger vers les bons états. + + +Nommage des uses case +~~~~~~~~~~~~~~~~~~~~~ +Chaque état du use case sait à quel use case il appartient. + +Donc a chaque entrée dans un nouveau use case, l'état de retour est empilé avec +le nom du use case correspondant. +A la sortie, la pile des uses case est dépilé jusqu'a retrouvé le bon nom +(gestion du "back") et ainsi, on retrouve le bon état de retour. + +Cependant, cela ne marche pas dans le cas ou un etat, apartient a deux use case +différent suivant son utilisation. (il devrait avoir 2 nom de use case +différents) + +Problème possible aussi dans le cas +UC1->UC2->UC1 (avec back navigateur) + + + + +Constat +~~~~~~~ +Cela ne marche plus dès que le client effectue des actions, sans envoyer des +informations au serveur. C'est le cas du "back" navigateur, ou le cas où il +dispose de plusieurs fenêtres sur la meme application. +Il faut donc ajouter de l'information coté client pour gerer proprement les uses +cases. + + +Parametre de page en page +~~~~~~~~~~~~~~~~~~~~~~~~~ +On peut envisager la possibilité de generer un identifiant aléatoire et de +stocker cet identifiant à la fois dans la pile et dans la page coté client. +Cela fonctionerais, cependant il faudrait transporter cet identificant de page +en page, a supposer qu'on ne le perdre jamais. +En plus, le mettre dans tous les liens et formulaire. +Donc beaucoup de travail pour le programmeur. + + + +Filtre de gestion des uses case +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +L'idée est de conserver l'état de la pile de use case, dans l'url client. + +:: + + +--------+ /uc1/uc2/Page.new +--------+ /Page.new +----------+ + | Client | ------------------------> | Filtre | -----------------> | Tapestry | + | | | | | (new UC) | + +--------+ <------------------------ +--------+ <----------------- +----------+ + /uc1/uc2/uc3/Page2 /Page2 + +:: + + +--------+ /uc1/uc2/uc3/Page3.cancel +--------+ /Page3.cancel +----------+ + | Client | ------------------------> | Filtre | -----------------> | Tapestry | + | | | | | (del UC) | + +--------+ <------------------------ +--------+ <----------------- +----------+ + /uc1/uc2/Page /Page + + + +À l'arrivée d'une requête, le filtre recupére l'état de la pile (/uc1/uc2) +et forward sur la page demandée (Page.new). +Tapestry, fait ce qu'il a à faire, dans ce cas, il entre dans un nouveau UC. + +L'appel revient vers le filtre. +Le filtre doit remplacer tous les liens de la page en les préfixant par la pile +de use case (en l'état après l'appel sur tapestry). + +Liens ++++++ + + - http://www.nuiton.com/* => pas à modifier + - /topia/PageForm => context + => /chorem/uc1/uc2/PageForm + - PageForm => ??? + + +Si on remplace tous les liens, les liens de menu (tout nouveau UC) auront l'état +de la pile. +La taille de l'url pourra grandir. Pour peu que les noms de UC soit grand, on +arrive à une url très grande. +(http://www.boutell.com/newfaq/misc/urllength.html) + +Si on ne les remplace pas tous, les nouveaux liens n'auront plus de pile de UC. +Mais on ne peut pas supprimer la pile coté serveur. +Le bouton back doit pouvoir marcher, et retrouver une ancienne pile. +On aurait donc dans ce cas, un mapping de pile dans la session. + +Problème +++++++++ + +On est quasiment obligé de conserver tous les use case dans la session, meme +si il fini un UC, il ne doit pas être dépilé, parce qu'il peut toujours faire +back et retomber dessus. + +La solution de remplacer tous les liens ++++++++++++++++++++++++++++++++++++++++ + +Mais juste avec l'identifiant du UC courant dans l'url (cet identifiant est +unique). + +Cas: + - nouveau use case : + empilage du nouveau use case à la suite du précédent + - fin d'un use case : + remplacement du use case par le précédent + +Note: dans ce cas on ne gère plus une pile, mais un arbre. + +Pour chaque noeud de l'arbre, on pourrait: + - ajouter un fils (new UC) + - connaire son père (fin d'un UC) + + +Nom des uses case static +++++++++++++++++++++++++ +Chaque état du model a un nom unique. + +Le nom de l'etat demandant l'execution d'un sous use case est utilisé comme +identifiant pour lui associer l'état de retour. + +Exemple: + -On est dans l'etat de use case ETATX_ETATY + -On est dans l'etat ETATZ + -on demarre un sous use case + -> identifiant ETATX_ETATY_ETATZ + -> dans la pile la sortie de ETATX_ETATY_ETATZ renvoie vers l'etat ETATZ + +Cet identifiant peut etre utilise dans l'url est gerer les bouton back et +doubles fenetres. + +Cette dernière solution a été utilisée. \ No newline at end of file Modified: trunk/topia-ui/src/site/rst/index.rst =================================================================== --- trunk/topia-ui/src/site/rst/index.rst 2009-08-28 08:16:38 UTC (rev 1633) +++ trunk/topia-ui/src/site/rst/index.rst 2009-08-28 14:56:14 UTC (rev 1634) @@ -1,4 +1,13 @@ Topia-UI ======== -Aucune documentation n'est disponible. \ No newline at end of file +Topia UI permet de generer le squelete des interfaces utilisateurs à partir +d'un modele état transition. + +Pour l'instant, seule une génération basé sur tapestry est disponible. + +Presentation des cas d'utilisation +---------------------------------- + +- `Reflexion sur les cas d'utilisation <UseCase.html>`_ +- `Problèmes sur les cas d'utilisation <UseCaseProblems.html>`_ Modified: trunk/topia-ui/src/site/site.xml =================================================================== --- trunk/topia-ui/src/site/site.xml 2009-08-28 08:16:38 UTC (rev 1633) +++ trunk/topia-ui/src/site/site.xml 2009-08-28 14:56:14 UTC (rev 1634) @@ -14,9 +14,13 @@ <menu ref="parent"/> - <menu name="Utilisateur" inherit="top"/> + <menu name="Utilisateur" inherit="top"> + <item href="index.html" name="Accueil" /> + <item href="UseCase.html" name="Cas d'utilisation" /> + <item href="UseCaseProblems.html" name="Cas d'utilisation (problèmes)" /> + </menu> - <menu name="Téléchargement"> + <menu name="Téléchargement"> <item href="${repository.home.url}/org/nuiton/topia/${project.artifactId}/${project.version}/${project.build.finalName}.jar" name="Librairie (jar)"/> <item href="${repository.home.url}/org/nuiton/topia/${project.artifactId}/${project.version}/${project.build.finalName}-javadoc.jar"