Premiers retours sur l'utilisation de Wikitty en GWT 2.0. Je peux hériter du module Wikitty, pas de soucis, par contre je l'ai modifié pour n'avoir que le package entities dedans (sinon faudrait repackager toutes les dépendances pour gwt). Il me reste encore quelques problèmes avant de pouvoir charger une entité wikitty en gwt. JE rapporte ici les erreurs, elles apparaissent toutes plusieures fois, mais je rapporte seulement une fois par erreur. Dans WikittyAuthorisationAbstract (entre autres) : (l'erreur apparait à plein de lignes) 00:00:03,274 [ERROR] Line 83: The method getPropertyChangeSupport() from the type BusinessEntityWikitty refers to the missing type PropertyChangeSupport Dans WikittyTokenImpl (entre autre) : [ERROR] Line 37: The type WikittyTokenImpl must implement the inherited abstract method BusinessEntity.addPropertyChangeListener(String, PropertyChangeListener) Dans BusinessEntityWikitty (entre autre) : [ERROR] Line 28: The import java.beans cannot be resolved Dans WikittyCopyOnWrite : [ERROR] Line 78: The method format(String, Wikitty) is undefined for the type String Dans WikittyImpl : [ERROR] Line 44: The import java.util.logging cannot be resolved [ERROR] Line 142: The method format(String, String, String) is undefined for the type String Line 673: The method format(String, String) is undefined for the type String Et sinon il faudrait ajouter WikittyUtil avec les sources, donc le mettre dans le package entities, mais ça fait pas top, l'autre solution pourrait être de le mettre dans un package tout seul. Jean
La suite des évènements : En utilisant la librairie gwtx, on résouds tous les problèmes de getPropertyChangeSupport(), PropertyChangeListener,... En upgradant vers gwt 2.1, on résouds tous les problèmes de BigDecimal. J'ai créé un package utilities dans Wikitty dans lequel j'ai mis WikittyUtil et les exceptions (non commité, j'attends vos retours pour le faire) pour pouvoir ajouter les sources pour gwt. Ca résouds tous les problèmes de dépendances Wikitty, mais ça en introduit de nouveaux. En gros, il reste 6 classes de Wikitty qui ne passent pas dans GWT : - BusinessEntityWikitty : * Line 134: The method isAssignableFrom(Class<capture#1-of ? extends Object>) is undefined for the type Class<BusinessEntityWikitty> - Wikitty : * Line 226: No source code is available for type java.lang.CloneNotSupportedException; did you forget to inherit a required module? - WikittyCopyOnWrite : * Line 55: No source code is available for type org.apache.commons.logging.Log; did you forget to inherit a required module? * Line 78: The method format(String, Wikitty) is undefined for the type String * Line 77: No source code is available for type java.lang.CloneNotSupportedException; did you forget to inherit a required module? - WikittyImpl : * Line 139: No source code is available for type org.nuiton.util.ObjectUtil; did you forget to inherit a required module? * Line 140: No source code is available for type java.lang.CloneNotSupportedException; did you forget to inherit a required module? * Line 141: The method format(String, String, String) is undefined for the type String (plein d'occurences) - WikittyMetaExtensionUtil : * Line 43: No source code is available for type org.apache.commons.logging.Log; did you forget to inherit a required module? * Line 53: The method format(String, String, String, String) is undefined for the type String - WikittyUtil : * Line 77: The method toPattern() is undefined for the type SimpleDateFormat * Line 82: No source code is available for type org.apache.commons.logging.Log; did you forget to inherit a required module? * Line 85: No source code is available for type java.util.TimeZone; did you forget to inherit a required module? * Line 86: No source code is available for type java.util.Locale; did you forget to inherit a required module? * Line 89: No source code is available for type org.apache.commons.lang.time.FastDateFormat; did you forget to inherit a required module? * Line 105: No source code is available for type org.apache.commons.lang.time.DateUtils; did you forget to inherit a required module? * Line 122: Pattern.DOTALL cannot be resolved * Line 149: The method matches() is undefined for the type Matcher (plein d'occurences) * Line 191: The method format(String, String) is undefined for the type String * Line 639: The method forName(String) is undefined for the type Class * Line 644: The method isAssignableFrom(Class<capture#12-of ?>) is undefined for the type Class<BusinessEntityWikitty> * Line 650: The method newInstance() is undefined for the type Class<capture#13-of ?> * Line 673: No source code is available for type org.nuiton.wikitty.WikittyService; did you forget to inherit a required module? * Line 699: No source code is available for type java.lang.reflect.Constructor<T>; did you forget to inherit a required module? * Line 700: The method getConstructor(Class<Wikitty>) is undefined for the type Class<capture#20-of ?> * Line 708: No source code is available for type java.lang.NoSuchMethodException; did you forget to inherit a required module? * Line 763: No source code is available for type org.nuiton.wikitty.services.WikittyServiceEnhanced; did you forget to inherit a required module? * Line 783: The method cast(Object) is undefined for the type Class<E> * Line 814: No source code is available for type java.util.UUID; did you forget to inherit a required module? Pour les histoire de Clone : http://code.google.com/p/google-web-toolkit/issues/detail?id=1843 Pour les problèmes de UUID : http://2ality.blogspot.com/2009/01/uuids-for-gwt.html Pour ce qui est du String.format, il y a peut-être moyen de faire un utilitaire pour éviter les ""+"".... Ex : http://code.google.com/p/gwt-ext/source/browse/trunk/main/src/com/gwtext/cli... Pour le commons-logging, j'ai rien trouvé pour l'instant, j'ai peur qu'il faille soit virer les logs, soit passer par des System.out.println("") :(. Jean
Pour les histoire de Clone : http://code.google.com/p/google-web-toolkit/issues/detail?id=1843
Pour les problèmes de UUID : http://2ality.blogspot.com/2009/01/uuids-for-gwt.html
Pour ce qui est du String.format, il y a peut-être moyen de faire un utilitaire pour éviter les ""+"".... Ex : http://code.google.com/p/gwt-ext/source/browse/trunk/main/src/com/gwtext/cli...
Pour le commons-logging, j'ai rien trouvé pour l'instant, j'ai peur qu'il faille soit virer les logs, soit passer par des System.out.println("") :(.
Et pour toutes les méthodes de la JRE qu'on a le droit d'utiliser : http://code.google.com/intl/fr/webtoolkit/doc/latest/RefJreEmulation.html
On Sat, 06 Nov 2010 11:24:37 +0100 Jean Couteau <couteau@codelutin.com> wrote:
Pour les histoire de Clone : http://code.google.com/p/google-web-toolkit/issues/detail?id=1843
Pour les problèmes de UUID : http://2ality.blogspot.com/2009/01/uuids-for-gwt.html
Pour ce qui est du String.format, il y a peut-être moyen de faire un utilitaire pour éviter les ""+"".... Ex : http://code.google.com/p/gwt-ext/source/browse/trunk/main/src/com/gwtext/cli... Pour moi on doit jamais utiliser dans + sur les String, on préfère toujours utiliser du StringBuilder (ou StringBuffer). Je suis peut-être pas hors context...
Pour le commons-logging, j'ai rien trouvé pour l'instant, j'ai peur qu'il faille soit virer les logs, soit passer par des System.out.println("") :(. Vraiment pas acceptable comme solution :) C'est quoi exactement le problème ? Tu parles auparavant d'un import java.util.logging ? Et ça c'est le système de logging de la JDK :) A savori que si log4j est pas embarqué, alors par défaut commons-logging utilise ce qui est dipo à savoir le système de la jdk. Je sais pas si ça un lien avec ton problème ?
Et pour toutes les méthodes de la JRE qu'on a le droit d'utiliser : http://code.google.com/intl/fr/webtoolkit/doc/latest/RefJreEmulation.html _______________________________________________ Wikitty-devel mailing list Wikitty-devel@list.nuiton.org http://list.nuiton.org/cgi-bin/mailman/listinfo/wikitty-devel
-- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
Le 06/11/2010 11:34, chemit a écrit :
Pour ce qui est du String.format, il y a peut-être moyen de faire un utilitaire pour éviter les ""+"".... Ex : http://code.google.com/p/gwt-ext/source/browse/trunk/main/src/com/gwtext/cli... Pour moi on doit jamais utiliser dans + sur les String, on préfère toujours utiliser du StringBuilder (ou StringBuffer). Je suis peut-être pas hors context...
Non non tu as raison, c'était surtout pour illustrer en fait..
Pour le commons-logging, j'ai rien trouvé pour l'instant, j'ai peur qu'il faille soit virer les logs, soit passer par des System.out.println("") :(. Vraiment pas acceptable comme solution :) C'est quoi exactement le problème ? Tu parles auparavant d'un import java.util.logging ? Et ça c'est le système de logging de la JDK :) A savori que si log4j est pas embarqué, alors par défaut commons-logging utilise ce qui est dipo à savoir le système de la jdk. Je sais pas si ça un lien avec ton problème ?
Là en fait le problème vient du fait qu'on a pas commons-logging :( Line 82: No source code is available for type org.apache.commons.logging.Log; did you forget to inherit a required module?
Le 06/11/2010 12:08, Jean Couteau a écrit :
Là en fait le problème vient du fait qu'on a pas commons-logging :(
Line 82: No source code is available for type org.apache.commons.logging.Log; did you forget to inherit a required module Même si tu arrive à le compiler, ca risque d'être lent, sur l'implémentation qu'il y a derrière (il faut que ca log coté serveur).
Sinon, il y a peut être moyen de bind l'api commons logging sur le log de gwt. A voir si slf4j ne propose pas d'alternative également. -- Éric <chatellier@codelutin.com> Tel: 02 40 50 29 28 http://www.codelutin.com
Le 08/11/2010 09:38, Eric Chatellier a écrit :
Le 06/11/2010 12:08, Jean Couteau a écrit :
Là en fait le problème vient du fait qu'on a pas commons-logging :(
Line 82: No source code is available for type org.apache.commons.logging.Log; did you forget to inherit a required module Même si tu arrive à le compiler, ca risque d'être lent, sur l'implémentation qu'il y a derrière (il faut que ca log coté serveur).
Sinon, il y a peut être moyen de bind l'api commons logging sur le log de gwt.
A voir si slf4j ne propose pas d'alternative également.
Je pense que c'est hors-sujet. Ne dois être transformé en GWT que les entités. Or une entité qui veut logger quelque chose, ca me choque ! Donc je pense qu'il va falloir plutôt envisager un bout de réorganisation... Mais j'avoue ne pas avoir mis le nez quand wikitty depuis un moment :( Arnaud.
Le 06/11/2010 11:20, Jean Couteau a écrit :
- WikittyUtil : * Line 77: The method toPattern() is undefined for the type SimpleDateFormat
Les implementations GWT de SimpleDateFormat que j'ai trouvé n'implémentent pas cette méthode.
* Line 82: No source code is available for type org.apache.commons.logging.Log; did you forget to inherit a required module?
Donc d'après toutes les informations que j'ai trouvé, pas de commons-logging côté client dans GWT, donc si on veut que Wikitty soit dispo dans gwt, il faut aucune trace de commons-logging dans les packages qui sont accessibles par gwt (entities et utilities).
* Line 85: No source code is available for type java.util.TimeZone; did you forget to inherit a required module? * Line 86: No source code is available for type java.util.Locale; did you forget to inherit a required module?
Résolu en utilisant : http://code.google.com/p/gwt-calendar-class/ Par contre c'est pas packagé maven et c'est en beta...
* Line 122: Pattern.DOTALL cannot be resolved
Pas encore implémenté dans gwtx : http://code.google.com/p/gwtx/issues/detail?id=23
* Line 149: The method matches() is undefined for the type Matcher (plein d'occurences)
En fait, gwtx implémente Matcher mais pas complètement : http://stackoverflow.com/questions/1162240/regular-expressions-and-gwt
* Line 639: The method forName(String) is undefined for the type Class * Line 644: The method isAssignableFrom(Class<capture#12-of ?>) is undefined for the type Class<BusinessEntityWikitty> * Line 650: The method newInstance() is undefined for the type Class<capture#13-of ?> * Line 699: No source code is available for type java.lang.reflect.Constructor<T>; did you forget to inherit a required module? * Line 700: The method getConstructor(Class<Wikitty>) is undefined for the type Class<capture#20-of ?>
Pour toutes les méthodes de réflexion sur les classes, il y a : http://gwtreflection.sourceforge.net/ mais ça m'a l'air un peu obscur.
* Line 673: No source code is available for type org.nuiton.wikitty.WikittyService; did you forget to inherit a required module?
Peut-être rajouter ça dans le package utilities ?
* Line 763: No source code is available for type org.nuiton.wikitty.services.WikittyServiceEnhanced; did you forget to inherit a required module?
Pas bon, voir si on peut s'en passer (ou on risque de se rajouter plein de problèmes je pense en le rajoutant dans le module gwt). Sinon je pense à un truc, mais je sais pas si ça solutionnera les problèmes (ni si ça marchera). L'idée serait de générer les interfaces des classes du modèle dans un package différent de celui des impls, comme ça on peut importer uniquement les interfaces et on devrait réduire les problèmes d'import (je pense que ça devrait pouvoir le faire mais pas dit que gwt réussise à s'en sortir). Jean
Le 06/11/2010 14:55, Jean Couteau a écrit :
Sinon je pense à un truc, mais je sais pas si ça solutionnera les problèmes (ni si ça marchera). L'idée serait de générer les interfaces des classes du modèle dans un package différent de celui des impls, comme ça on peut importer uniquement les interfaces et on devrait réduire les problèmes d'import (je pense que ça devrait pouvoir le faire mais pas dit que gwt réussise à s'en sortir).
J'ai fait un test, en copiant mes classes générées dans mon projet gwt. L'interface côté client et les implémentations (impl, abstract et helper) côté serveur. Ca passe presque, il me manque WikittyUser (que je dois étendre) et BusinessEntityWikitty. Du coup je pense que ça peut être une bonne approche. Si on suit le principe, WikittyUser est une interface et du coup se retrouvera côté client, il restera plus que BusinessEntityWikitty qui a un seul problème : Line 134: The method isAssignableFrom(Class<capture#1-of ? extends Object>) is undefined for the type Class<BusinessEntityWikitty>
On Sat, 06 Nov 2010 14:55:52 +0100 Jean Couteau <couteau@codelutin.com> wrote:
Sinon je pense à un truc, mais je sais pas si ça solutionnera les problèmes (ni si ça marchera). L'idée serait de générer les interfaces des classes du modèle dans un package différent de celui des impls, comme ça on peut importer uniquement les interfaces et on devrait réduire les problèmes d'import (je pense que ça devrait pouvoir le faire mais pas dit que gwt réussise à s'en sortir).
Non, non et non :) Je trouve cette approche de vouloir modifier les apis des couches de persistence pour rentrer dans un moule d'ui déroutante... Je sais bien que tu veux réussir à t'en sortir mais ça me parait tellement faire le truc à l'envers de modifier de l'api pour un besoin d'ui... La couche d'ui n'est pas orchestre de quoique se soit; si on se rends compte que GWT est trop tordu, il faudrait peut-être penser à en parler au client et trouver une solution de replis plutôt que déformer wikitty à tord. De plus la modification que tu soumets est lourde de conséquence : on déplace jamais des apis comme ça vite fait : elles doivent être dépréciées puis supprimer dans un temps second; enfin je dis ça sur un projet où y d'autres gens qui utilisent la librairie (ce qui est le cas ici si je ne m'abuse). -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
On Sun, 7 Nov 2010 09:15:27 +0100 chemit <chemit@codelutin.com> wrote:
On Sat, 06 Nov 2010 14:55:52 +0100 Jean Couteau <couteau@codelutin.com> wrote:
Sinon je pense à un truc, mais je sais pas si ça solutionnera les problèmes (ni si ça marchera). L'idée serait de générer les interfaces des classes du modèle dans un package différent de celui des impls, comme ça on peut importer uniquement les interfaces et on devrait réduire les problèmes d'import (je pense que ça devrait pouvoir le faire mais pas dit que gwt réussise à s'en sortir).
Si tu parlais du modèle client alors ce que j'ai écrit ne tient plus :) Si c'est pour le modèle de wikitty alors ça tient ;)
Non, non et non :)
Je trouve cette approche de vouloir modifier les apis des couches de persistence pour rentrer dans un moule d'ui déroutante...
Je sais bien que tu veux réussir à t'en sortir mais ça me parait tellement faire le truc à l'envers de modifier de l'api pour un besoin d'ui...
La couche d'ui n'est pas orchestre de quoique se soit; si on se rends compte que GWT est trop tordu, il faudrait peut-être penser à en parler au client et trouver une solution de replis plutôt que déformer wikitty à tord.
De plus la modification que tu soumets est lourde de conséquence : on déplace jamais des apis comme ça vite fait : elles doivent être dépréciées puis supprimer dans un temps second; enfin je dis ça sur un projet où y d'autres gens qui utilisent la librairie (ce qui est le cas ici si je ne m'abuse).
-- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
Le 07/11/2010 09:17, chemit a écrit :
On Sun, 7 Nov 2010 09:15:27 +0100 chemit <chemit@codelutin.com> wrote:
On Sat, 06 Nov 2010 14:55:52 +0100 Jean Couteau <couteau@codelutin.com> wrote:
Sinon je pense à un truc, mais je sais pas si ça solutionnera les problèmes (ni si ça marchera). L'idée serait de générer les interfaces des classes du modèle dans un package différent de celui des impls, comme ça on peut importer uniquement les interfaces et on devrait réduire les problèmes d'import (je pense que ça devrait pouvoir le faire mais pas dit que gwt réussise à s'en sortir).
Si tu parlais du modèle client alors ce que j'ai écrit ne tient plus :) Si c'est pour le modèle de wikitty alors ça tient ;)
Je parlais des deux ;) . Pour l'instant ce ne sont que des tests non commités, j'essaie de voir comment on peut faire fonctionner le bouzin, ensuite, une fois qu'on a trouvé la solution, on verra comment la mettre en pratique, et là c'est une autre question, il faut effectivement déprécier les anciennes classes,... mais comme je le dit, ce sont des tests pour l'instant, une tentative de bricolage, il est vrai, pour essayer de trouver la meilleure solution, et une fois qu'on a trouvé l'astuce 'bricolo' qui fonctionne, on essaye de la refaire mais de manière pro. Ca sert à rien de passer 3 heures de plus à faire les choses dans les règles de l'art si le test n'est pas concluant.
Le 07/11/2010 09:17, chemit a écrit :
On Sun, 7 Nov 2010 09:15:27 +0100 chemit <chemit@codelutin.com> wrote:
On Sat, 06 Nov 2010 14:55:52 +0100 Jean Couteau <couteau@codelutin.com> wrote:
Sinon je pense à un truc, mais je sais pas si ça solutionnera les problèmes (ni si ça marchera). L'idée serait de générer les interfaces des classes du modèle dans un package différent de celui des impls, comme ça on peut importer uniquement les interfaces et on devrait réduire les problèmes d'import (je pense que ça devrait pouvoir le faire mais pas dit que gwt réussise à s'en sortir).
Si tu parlais du modèle client alors ce que j'ai écrit ne tient plus :) Si c'est pour le modèle de wikitty alors ça tient ;)
Je parlais des deux ;) . Pour l'instant ce ne sont que des tests non commités, j'essaie de voir comment on peut faire fonctionner le bouzin, ensuite, une fois qu'on a trouvé la solution, on verra comment la mettre en pratique, et là c'est une autre question, il faut effectivement déprécier les anciennes classes,... mais comme je le dit, ce sont des tests pour l'instant, une tentative de bricolage, il est vrai, pour essayer de trouver la meilleure solution, et une fois qu'on a trouvé l'astuce 'bricolo' qui fonctionne, on essaye de la refaire mais de manière pro. Ca sert à rien de passer 3 heures de plus à faire les choses dans les règles de l'art si le test n'est pas concluant. Oui mais ca sert à rien aussi de vouloir faire n'importe quoi car tu
On Sun, 07 Nov 2010 10:10:55 +0100 Jean Couteau <couteau@codelutin.com> wrote: perds aussi 3 heures :) Donc je te parle pas de mise en forme mais de mélange de concept, genre et autre : tu dois pas faire plier les couches basses pour qu'elles rentrent dans l'ui mais l'inverse, je pensais avoir été clair :) Il ne s'agit pas aussi de savoir si c'est bien fait ou pas mais de pas le faire à l'envers. Après si benjamin t'a dit l'inverse de ça, une fois de plus on pense le contraire :) Tu veux que je te dise le fond de ma pensée : ce n'est pas toi qui devrait faire ça :) et prendre le problème par tatanoment expérimental me parait une hérésie :) On fait pas de la recherche en physique quantique juste de l'informatique... _______________________________________________
Wikitty-devel mailing list Wikitty-devel@list.nuiton.org http://list.nuiton.org/cgi-bin/mailman/listinfo/wikitty-devel
-- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
Le 07/11/2010 11:01, chemit a écrit :
On Sun, 07 Nov 2010 10:10:55 +0100 Jean Couteau <couteau@codelutin.com> wrote:
Oui mais ca sert à rien aussi de vouloir faire n'importe quoi car tu perds aussi 3 heures :) Donc je te parle pas de mise en forme mais de mélange de concept, genre et autre : tu dois pas faire plier les couches basses pour qu'elles rentrent dans l'ui mais l'inverse, je pensais avoir été clair :) Il ne s'agit pas aussi de savoir si c'est bien fait ou pas mais de pas le faire à l'envers.
Attends, je crois qu'il y a un malentendu, mon idée n'est pas de changer le modèle mais bien les packages de ce qui est généré à partir du modèle et d'avoir : org.nuiton.entities |--org.nuiton.entities.interfaces `--org.nuiton.entities.impl Le modèle lui ne changerai en aucun cas. Je ne vois rien de choquant là dedans, peut-être que je me trompe, mais dans ce cas, je veux bien une explication du pourquoi. Et dans tous les cas, l'idée n'est pas de pervertir Wikitty pour l'adapter à GWT mais faire en sorte qu'on puisse se servir de Wikitty dans le maximum de types d'applications différentes. Je pense que la solution que je propose n'est pas si déconnante que ça, mais comme dit plus haut, je peux me tromper.
Après si benjamin t'a dit l'inverse de ça, une fois de plus on pense le contraire :)
Il m'a rien dit, j'aime bien expérimenter, essayer, c'est comme ça que j'apprends.
Tu veux que je te dise le fond de ma pensée : ce n'est pas toi qui devrait faire ça :) et prendre le problème par tatanoment expérimental me parait une hérésie :)
Je fais ça seul, le week-end, parce que j'en ai envie et que j'aime bien essayer/tenter des trucs.
On fait pas de la recherche en physique quantique juste de l'informatique...
On est bien d'accord, c'est d'ailleurs pour ça qu'on peut expérimenter et tester beaucoup plus simplement.
Le 07/11/2010 11:01, chemit a écrit :
On Sun, 07 Nov 2010 10:10:55 +0100 Jean Couteau <couteau@codelutin.com> wrote:
Oui mais ca sert à rien aussi de vouloir faire n'importe quoi car tu perds aussi 3 heures :) Donc je te parle pas de mise en forme mais de mélange de concept, genre et autre : tu dois pas faire plier les couches basses pour qu'elles rentrent dans l'ui mais l'inverse, je pensais avoir été clair :) Il ne s'agit pas aussi de savoir si c'est bien fait ou pas mais de pas le faire à l'envers.
Attends, je crois qu'il y a un malentendu, mon idée n'est pas de changer le modèle mais bien les packages de ce qui est généré à partir du modèle et d'avoir :
org.nuiton.entities |--org.nuiton.entities.interfaces `--org.nuiton.entities.impl
Le modèle lui ne changerai en aucun cas. Je ne vois rien de choquant là dedans, peut-être que je me trompe, mais dans ce cas, je veux bien une explication du pourquoi.
On Sun, 07 Nov 2010 18:17:42 +0100 Jean Couteau <couteau@codelutin.com> wrote: parce que je vois pas l'utilité de deux packages et j'ai jamais un framework fonctionnant sur ce mode, c'est vraiment pas naturel. Pour moi par défaut les api et leur implantations sont à faire dans le même package. Il faudrait je sais pas par exemple voir si dans GWT on peut pas juste exclure certainnes classes d'un package ? Je dis ça sans aucune certitude car je connais pas GWT.
Et dans tous les cas, l'idée n'est pas de pervertir Wikitty pour l'adapter à GWT mais faire en sorte qu'on puisse se servir de Wikitty dans le maximum de types d'applications différentes. Je pense que la solution que je propose n'est pas si déconnante que ça, mais comme dit plus haut, je peux me tromper.
C'est pourtant bien que ce que tu essaye de faire : triturer dans tous les sens wikitty pour le faire rentrer dans GWT. Ce qui me paraitrait plus simple voyant que c'est pas évident d'utiliser tel quel wikitty dans GWt, c'est de dire la chose suivante : On attaquera pas directement depuis GWT les entités mais des beans d'ui qui seront compatibles. C'est une idée que je défends depuis toujours (et je suis pas le seul), Ben lui est catégoriquement contre (sans aucune explication justifié pour moi vu qu'on peut aussi les faire générer facilement). Pour moi c'est vraiment un anti-pattern de design d'utiliser dans une couche de présentation des objets persistants...
Après si benjamin t'a dit l'inverse de ça, une fois de plus on pense le contraire :)
Il m'a rien dit, j'aime bien expérimenter, essayer, c'est comme ça que j'apprends.
Bah faudrait plutôt qu'on en discute plutôt de faire des expériences de savants fous :)
Tu veux que je te dise le fond de ma pensée : ce n'est pas toi qui devrait faire ça :) et prendre le problème par tatanoment expérimental me parait une hérésie :)
Je fais ça seul, le week-end, parce que j'en ai envie et que j'aime bien essayer/tenter des trucs.
et perdre un peu de temps... car sans discussion avec des gens avec du recul sur ce genre de problématique, tu va perdre beaucoup de temps.
On fait pas de la recherche en physique quantique juste de l'informatique...
On est bien d'accord, c'est d'ailleurs pour ça qu'on peut expérimenter et tester beaucoup plus simplement.
Bah non c'est tout l'inverse, on bosse pas sur des théories non vérifiés et on fait du carré (euh de l'informatique) -> sans incertitude et avec le moyen de tatonnement possible ;)...
_______________________________________________ Wikitty-devel mailing list Wikitty-devel@list.nuiton.org http://list.nuiton.org/cgi-bin/mailman/listinfo/wikitty-devel
-- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
Le 07/11/2010 18:17, Jean Couteau a écrit :
Attends, je crois qu'il y a un malentendu, mon idée n'est pas de changer le modèle mais bien les packages de ce qui est généré à partir du modèle et d'avoir :
org.nuiton.entities |--org.nuiton.entities.interfaces `--org.nuiton.entities.impl
Le modèle lui ne changerai en aucun cas. Je ne vois rien de choquant là dedans, peut-être que je me trompe, mais dans ce cas, je veux bien une explication du pourquoi.
Et dans tous les cas, l'idée n'est pas de pervertir Wikitty pour l'adapter à GWT mais faire en sorte qu'on puisse se servir de Wikitty dans le maximum de types d'applications différentes. Je pense que la solution que je propose n'est pas si déconnante que ça, mais comme dit plus haut, je peux me tromper. Il me semble que coté client gwt, tu doit avoir à la fois les api, ET les l'impl, sinon, tu ne pourra même pas faire le moindre get/set sur tes objets.
-- Éric <chatellier@codelutin.com> Tel: 02 40 50 29 28 http://www.codelutin.com
* Line 673: No source code is available for type org.nuiton.wikitty.WikittyService; did you forget to inherit a required module? Peut-être rajouter ça dans le package utilities ? Non, les services wikitty ne devraient être appéle que
Le 06/11/2010 14:55, Jean Couteau a écrit : pas les services gwt, coté serveur, et donc non compilé en gwt. Apres, ca depend ou est utilisé cette classe dans l'api... -- Éric <chatellier@codelutin.com> Tel: 02 40 50 29 28 http://www.codelutin.com
participants (4)
-
Arnaud Thimel -
chemit -
Eric Chatellier -
Jean Couteau