Discussion :

[Baptiste Wicht]

Bonjour,

Je viens d'écrire un nouvel article : http://baptiste-wicht.developpez.com...tting-started/

Il explique comment développer une application modulaire de base avec JTheque Core.

Qu'en dites-vous ?

[dingoth]

Bonjour,

Je trouve l'article pas mal écrit et présentant bien l'ensemble des système impliqués et la manière dont ils le sont.

Cependant, je me permets de remettre en question deux petits choix, mais c'est plus lié à l'application JThèque qu'à l'article.

• L'utilisation d'un fichier application.xml contenant toutes les langues alors que les java.util.ResourceBundle sont facilement extensibles et supportent différentes langues très facilement. Par exemple, un fichier principal application.properties contient toutes les informations communes, deux sous-fichiers application_fr.properties contient la partie localisée en français et application_en.properties la partie localisée en anglais. Le ResourceBundle avec la langue française chargera systématiquement application_fr.properties ET application.properties, et prendra en priorité ce qui se trouve dans application_fr.
• Les annotations @Module et @PrimaryModule qui, à mon sens, contiennent des informations qui devraient davantage se trouver dans des fichier de configuration (.properties, voire Manifest) ; sans compter le fait que primaryModule pourrait alors être juste un booléen inclus dans Module.

Si ces remarques feraient mieux de se trouver dans un autre forum, désolé d'avance.

[Baptiste Wicht]

L'utilisation d'un fichier application.xml contenant toutes les langues alors que les java.util.ResourceBundle sont facilement extensibles et supportent différentes langues très facilement. Par exemple, un fichier principal application.properties contient toutes les informations communes, deux sous-fichiers application_fr.properties contient la partie localisée en français et application_en.properties la partie localisée en anglais. Le ResourceBundle avec la langue française chargera systématiquement application_fr.properties ET application.properties, et prendra en priorité ce qui se trouve dans application_fr.

J'ai justement voulu supprimer la partie RessourceBundle de l'application. Vu le peu de propriétés, j'ai préféré limiter au plus le nombre de fichier nécessaire pour l'application. Mais peut-être n'est ce pas encore la bonne façon de faire.

Les annotations @Module et @PrimaryModule qui, à mon sens, contiennent des informations qui devraient davantage se trouver dans des fichier de configuration (.properties, voire Manifest) ; sans compter le fait que primaryModule pourrait alors être juste un booléen inclus dans Module.

C'est effectivement prévu d'améliorer cette partie. Notamment d'internationaliser et d'externaliser une partie des propriétés.

Je suis tout à fait d'accord pour ce qui est de la redondance et ce devrait être corrigé.

A tout le monde : n'hésitez pas à vous exprimer également sur le projet JTheque, tous les commentaires sont bons à prendre pour moi

[Baptiste Wicht]

Bonjour,

Je viens de mettre à jour l'article pour la version 2.0.2 de JTheque Core.

Il n'y a plus de distinction entre un module primaire et secondaire et l'api a subit pas mal de changements.

N'hésitez pas à me remonter tout commentaire que vous pourriez avoir.

Merci

[Baptiste Wicht]

Bonjour,

Je viens de mettre à jour l'article pour la version 2.0.3 de JTheque Core.

J'ai essayé de simplifier au mieux le développement de modules avec JTheque Core.

N'hésitez pas à me remonter tout commentaire que vous pourriez avoir.

L'utilisation d'un fichier application.xml contenant toutes les langues alors que les java.util.ResourceBundle sont facilement extensibles et supportent différentes langues très facilement. Par exemple, un fichier principal application.properties contient toutes les informations communes, deux sous-fichiers application_fr.properties contient la partie localisée en français et application_en.properties la partie localisée en anglais. Le ResourceBundle avec la langue française chargera systématiquement application_fr.properties ET application.properties, et prendra en priorité ce qui se trouve dans application_fr.

C'est maintenant chose fait avec la version 2.0.3

En plus de cela, on n'a plus besoin de déclarer à la main au début le smodules dans le fichier de config, il suffit d'ajouter une option <discovery />.

[Deaf]

Bonjour,

je suis actuellement sur un projet similaire. Mon but est de découvrir les problématiques liées aux modules.

Après avoir regarder ton Tuto, une question m'est venue:
L'interface graphique est-elle un module? est-elle obligatoire?

[Baptiste Wicht]

Bonjour,

je suis actuellement sur un projet similaire. Mon but est de découvrir les problématiques liées aux modules.

Après avoir regarder ton Tuto, une question m'est venue:
L'interface graphique est-elle un module? est-elle obligatoire?

Non, pour moi, l'interface graphique n'est pas un module. Pour moi c'est un service rendu par le core. Ensuite les modules utilisent ce service pour ajouter des éléments à la vue.

Par contre, s'il n'y a aucun module, dans mon cas, la vue est vide, mais une application modulaire sans module n'a pas vraiment de sens.