Salut, je reste dubitatif sur l'intérêt d'utiliser JavaFX avec une webview. Tu vas devoir te limiter au niveau du CSS3 et de l'HTML5 et au final tu vas passer plus de temps à contourner les problèmes (le premier étant l'histoire du serveur local pour pouvoir afficher des images ...!) alors que tu utiliserait JAXX ce serait vraiment plus simple. Et si tu veux une interface web, de toute façon ce ne sera pas la même version que celle du client JavaFX. On pourra en rediscuter en réunion mais pour moi c'est se compliquer la vie pour rien. Kevin On 14/07/2013 23:12, Eric Chatellier wrote:

jTimer 2 architecture =====================

Je détail ici comment je vois l'architecture de jTimer 2.0 avec parfois des choses inconnues ou amusante à tester, voire des choses qui ne sont peut-être pas possibles.

La v2 serait un réécriture complète, rien n'à reprendre de la v1.

Livrable -------- Le but est d'avoir dans un premier temps un fonctionnement en local mais quand même sur une architecture client/serveur. Donc un jar exécutable démarrant un serveur http(?) et lançant un client (webview?, chrome app mode?, autre) sur ce serveur.

À plus long terme, l'application devrait être capable de fonctionner avec un micro-client local et un serveur distant.

Le tout attendu pour une application de timing sur les taches ne devrait pas dépasser 10Mo (de préférence).

Micro-client ------------ Le micro-client serait une WebView(?) JavaFX par défaut, impliquant un prérequis java 7 (voire java 8) car il devrait supporter les websockets. Une option de lancement ou config pourrait démarrer à la place chromium en "app-mode". Ce lancement (sans navigation, menu, etc) n'a pas l'air possible sur firefox.

Le micro-client est indispensable pour: - fournir un navigateur par défaut, connu de facon sur (WebView) - détecter l'inactivité système de l'utilisateur

L'inactivité (entre autre) sera communiqué par le serveur vers le client, donc c'est là que le websocket entre en jeu. Mais la WebView JavaFX 2 ne supporte pas ça, et ca n'a pas l'air prévu pour JavaFX 3 non plus (java 8). Même chose pour la synchronisation par exemple qui pousserait des choses au client.

Serveur ------- Le serveur doit avoir deux rôles: - fournir les ressources statiques (HTML/JS/CSS) - gérer les requêtes REST vers les services

Il n'est donc à priori pas nécessaires d'avoir une Stack JEE complète ici, un petit serveur HTTP en Java devrait très bien faire l'affaire (Mini conteneur de servlet pour l'instant : tjws).

Maven ----- J'hésite à tester l’écosystème javascript (Yeoman) et utiliser un plugin maven pour yeoman pour le packaging final (on se complique surement la vie à faire du frontend avec maven). Mais dans l’immédiat, plutôt du classique maven et nuiton-js.

Je vois pour l'instant 2 modules (pour utilisation locale) : - jtimer-services * stockage et services métier * mais de lancement de serveur http(?) * ressources statiques => à terme, le module devait produire un artifact déployable pour les services rest (war?) - jtimer-cli (dep sur jtimer-services) * main * lancement d'un serveur http(?) avec les services en local * lancement du client web (webview/autre) * code de détection d'inactivité

Technologies clientes --------------------- J'avais envie de tester des frameworks MVC, genre backbone + marionnette, emberjs ou autres, mais il n'y en a pas un qui m'attire particulièrement. Donc pour l'instant, ça serait du angular + javascript pur et du bootstrap pour ne pas développer de style dans un premier temps. Le tout optimisé par le plugin maven wro et cMinJawr et packerJs (ou autre).

Détection de l'inactivité toujours via bridj.

Technologies serveurs --------------------- En techno serveur on aurait: - un stockage jdbc sur h2 - un (ou plusieurs) service métier - une interface rest sur ces services (de préférence à ne pas développer) - peut être un proxy qui wrap toutes les requêtes service en: - transcodant les paramètres (params/body json) en object java - sérialisant les retours en json (via gson)

Technologies diverses --------------------- En technologie diverses à utiliser (ou à tester) : * Communication serveur>client via websocket(? pas sûr des possibilités navigateur) * TestNG, fest assert pour les tests unitaires des services * Karma pour les tests unitaires javascript(?) * Selenium avec 'page factory pattern' ou FluentLenium pour les tests d'intégration: - par défaut sur phantomjs en headless - possibilité de lancer les tests sur firefox et chromium

Le 14/07/2013 23:12, Eric Chatellier a écrit :

jTimer 2 architecture =====================

Je détail ici comment je vois l'architecture de jTimer 2.0 avec parfois des choses inconnues ou amusante à tester, voire des choses qui ne sont peut-être pas possibles.

La v2 serait un réécriture complète, rien n'à reprendre de la v1.

Livrable -------- Le but est d'avoir dans un premier temps un fonctionnement en local mais quand même sur une architecture client/serveur. Donc un jar exécutable démarrant un serveur http(?) et lançant un client (webview?, chrome app mode?, autre) sur ce serveur.

À plus long terme, l'application devrait être capable de fonctionner avec un micro-client local et un serveur distant.

Le tout attendu pour une application de timing sur les taches ne devrait pas dépasser 10Mo (de préférence).

Micro-client ------------ Le micro-client serait une WebView(?) JavaFX par défaut, impliquant un prérequis java 7 (voire java 8) car il devrait supporter les websockets. Une option de lancement ou config pourrait démarrer à la place chromium en "app-mode". Ce lancement (sans navigation, menu, etc) n'a pas l'air possible sur firefox.

Le micro-client est indispensable pour: - fournir un navigateur par défaut, connu de facon sur (WebView) - détecter l'inactivité système de l'utilisateur

L'inactivité (entre autre) sera communiqué par le serveur vers le client, donc c'est là que le websocket entre en jeu. Mais la WebView JavaFX 2 ne supporte pas ça, et ca n'a pas l'air prévu pour JavaFX 3 non plus (java 8). Même chose pour la synchronisation par exemple qui pousserait des choses au client.

Serveur ------- Le serveur doit avoir deux rôles: - fournir les ressources statiques (HTML/JS/CSS) - gérer les requêtes REST vers les services

Il n'est donc à priori pas nécessaires d'avoir une Stack JEE complète ici, un petit serveur HTTP en Java devrait très bien faire l'affaire (Mini conteneur de servlet pour l'instant : tjws).

Maven ----- J'hésite à tester l’écosystème javascript (Yeoman) et utiliser un plugin maven pour yeoman pour le packaging final (on se complique surement la vie à faire du frontend avec maven). Mais dans l’immédiat, plutôt du classique maven et nuiton-js.

Je vois pour l'instant 2 modules (pour utilisation locale) : - jtimer-services * stockage et services métier * mais de lancement de serveur http(?) * ressources statiques => à terme, le module devait produire un artifact déployable pour les services rest (war?) - jtimer-cli (dep sur jtimer-services) * main * lancement d'un serveur http(?) avec les services en local * lancement du client web (webview/autre) * code de détection d'inactivité

Technologies clientes --------------------- J'avais envie de tester des frameworks MVC, genre backbone + marionnette, emberjs ou autres, mais il n'y en a pas un qui m'attire particulièrement. Donc pour l'instant, ça serait du angular + javascript pur et du bootstrap pour ne pas développer de style dans un premier temps. Le tout optimisé par le plugin maven wro et cMinJawr et packerJs (ou autre).

Détection de l'inactivité toujours via bridj.

Technologies serveurs --------------------- En techno serveur on aurait: - un stockage jdbc sur h2 - un (ou plusieurs) service métier - une interface rest sur ces services (de préférence à ne pas développer) - peut être un proxy qui wrap toutes les requêtes service en: - transcodant les paramètres (params/body json) en object java - sérialisant les retours en json (via gson)

Technologies diverses --------------------- En technologie diverses à utiliser (ou à tester) : * Communication serveur>client via websocket(? pas sûr des possibilités navigateur) * TestNG, fest assert pour les tests unitaires des services * Karma pour les tests unitaires javascript(?) * Selenium avec 'page factory pattern' ou FluentLenium pour les tests d'intégration: - par défaut sur phantomjs en headless - possibilité de lancer les tests sur firefox et chromium

-- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com