Re: GWT + règles N3 ?

[Jean-Marc Vanel]

Le 18 décembre 2011 23:49, luc peuvrier at home <lc....@orange.fr> a écrit :

Bonjour,

 

D'une façon générale le problème se pose pour de l'application web/html sachant que le moteur d'infèrence semble être le moteur de l'application (dites si je me trompe)

 

Le hasard faisant bien les choses j'ai fait quelques essais ajax/comet et j'envisage de développer une lbrairie où le serveur fait se qu'il veut dans la page html du navigateur, donc rendrait possible l'utilisation d'une application qui "monte dynamiquement" l'IHM.

Ca a l'air prometteur .

Quoi de neuf depuis le 18 décembre ?

 

Mais d'un autre coté je pense qu'il est possible de générer le code d'une IHM permetant d'éditer les individus/faits (ABox) à partir de l'ontologie/règles (TBox) régissant les individus/faits.

C'est exactement ce que fait  la base règles swing3 de Déductions, mais je répète que ça ne génère pas de code, ça instancie et configure des objets graphiques Java à l'intérieur d'une base de connaissances Drools. Ces objets pourraient être autre chose que Swing, Par exemple si on avait des objets qui créent dynamiquement du contenu côté web, ça marcherait.

On peut imaginer pour votre "application qui monte dynamiquement l'IHM" , une socket sur laquelle  le serveur envoie des messages, qui sont reçus et interprétés côté navigateur.

Par exemple ces messages peuvent être des fragments de JavaScript qui sont interprétés directement côté navigateur.

PS A côté de GWT, il y a d'autre framework comme Echo ( http://echo.nextapp.com/site/ ) . 

 

Cordialement

Luc

 

----- Original Message -----

From: Cyril Hansen

To: Jean-Marc Vanel

Cc: luc peuvrier at home

Sent: Sunday, December 18, 2011 10:29 PM

Subject: Re: GWT + règles N3 ?

Bonjour,

Je peux en effet ajouter ma propre remarque à vos échanges :

- GWT fonctionne différemment en mode développement (hosted mode) et production. 

En mode production, on a un vrai compilateur Java -> JS et plus aucune interprétation, ce qui correspond à ce que dit Luc.

En mode développement le code Java/GWT est interprété sous forme bytecode par la JVM, ce qui permet l'usage du débuggeur. L'IHM reste dans une fenetre de navigateur, ce qui nécessite des contorsions assez poussées, qui ne sont pas vraiment expliquées dans la documentation. 

(http://code.google.com/webtoolkit/doc/1.6/DevGuideCompilingAndDebugging.html) 

Je sais juste que cela utilise des interfaces assez poussées au niveau des navigateurs et l'accélération des release de firefox et de chrome a un peu perturbé l'équipe GWT.

Je pense que ce serait probablement bien pour vous que votre infrastructure fonctionne dans les deux modes, pour faciliter le développement. La compilation GWT->JS n'est pas du tout instantanée...

Le 17 décembre 2011 12:15, Jean-Marc Vanel <jeanmar...@gmail.com> a écrit :

Bonjour Cyril

Dommage que vous n'étiez pas là  ce matin sur IRC #eulergui.

Votre avis serait précieux sur plusieurs points .

<jmvanel> est ce qu'il y un compilo GWT qui génére du Swing ou ou AWT SWT ?

<lcpvrr> je ne pense pas

<jmvanel> actuellement dans le générateur de formulaires, c'est déjà assez portable ;

<jmvanel> la traduction générique vers Swing se fait ici : 

<jmvanel> https://deductions.svn.sourceforge.net/svnroot/deductions/n3_nojs/generic_to_java-rules.n3

<jmvanel> Il suffirait donc de remplacer :

<jmvanel> { ?W a gengui:Label.

<jmvanel> javapr:thisApplication app:platform app:Java . } => { ?W a java:javax-swing-JLabel } .

<jmvanel> par:

<jmvanel> { ?W a gengui:Label.

<jmvanel> javapr:thisApplication app:platform app:GWT . } => { ?W a java:???-?Label } .

<jmvanel> etc

<lcpvrr> yes, puis de générer les fichiers java pour GWT

<jmvanel> ?

<jmvanel> a priori non

<lcpvrr> oui oui, le compilo GWT a du java comme source !

<jmvanel> générer les fichiers JS + CSS vous vouliez dire ?

<lcpvrr> non non

<lcpvrr> je ne sais pas si ce code est simplement lu par le compilo GWT où s'il l'execute, mais ce n'est qu'une question d'implémentation du compilo

<lcpvrr> un source java c'est une forme comme une autre pour un  modèle ;-)

<jmvanel> c'est là que je crains un pb ; en Swing c'est très direct : si ; myPane.add( new JLabel() ) est dynamiquement exécuté, ça se verra tout de suite 

<lcpvrr> pas avec GWT

<jmvanel> sûr ?

<lcpvrr> oui

--
Jean-Marc Vanel
Déductions SARL - Consulting, services, training,
Rule-based programming, Semantic Web
http://jmvanel.free.fr/ - EulerGUI, a turntable GUI for Semantic Web + rules, XML, UML, eCore, Java bytecode
+33 (0)6 89 16 29 52
chat :  irc://irc.freenode.net#eulergui

--
Jean-Marc Vanel
Déductions SARL - Consulting, services, training,
Rule-based programming, Semantic Web
http://jmvanel.free.fr/ - EulerGUI, a turntable GUI for Semantic Web + rules, XML, UML, eCore, Java bytecode
+33 (0)6 89 16 29 52
chat :  irc://irc.freenode.net#eulergui

[Cyril Hansen]

Bonjour à tous,

GW

T imposant pour le client un compilateur Java-> Javascript, j'avoue que je ne vois pas comment on peut concilier cette techno en usage "normal" avec un système de génération dynamique d'IHM à base de règle.

D'une manière générale, le web impose des contraintes techniques fortes que les frameworks existants peinent encore à maîtriser. D'un coté HTTP est un protocole sans gestion de session native, ce qui force à conserver de force le contexte coté serveur, et de l'autre, les sites dynamiques doivent  limiter les ressources consommées par chaque client connecté pour avoir une bonne robustesse et montée en charge : La solution "naturelle" est de déporter une grosse partie de l'IHM coté client en javascript, et de ne conserver avec le serveur que des appels RPC élémentaires (type AJAX), idéalement cachables : C'est ce que fait GWT.

Sans forcément utiliser GWT, il me semble donc que l'architecture du web impose qu'une partie du code client soit préparée par anticipation et non généré à la volée : cela permet de la publier sous forme de documents statiques, qui est la clé de voute de la montée en charge de tout site.

Voilà pour mes 2 centimes,

Cyril

[luc peuvrier at home]

Bonjour,

 

Je ne connais pas suffisament les possibilités de GWT pour savoir s'il y a une posibilité de génération de page dynamiquement, peut être en embarquant le compilateur GWT et encore.

 

Cyril, si tu epluche la page délivrée par http://edoors.eu/homedt/pages en regardant ce qui est affiché dans ton navigateur tu verras qu'il est envisageable de modifier la page dynamiquement: manipulation du document html par le serveur. Ensuite pour le reste les technos classiques s'appliquent.

 

Cdt

[Jean-Marc Vanel]

Le 8 janvier 2012 21:26, Cyril Hansen <cyril....@gmail.com> a écrit :
....

> Sans forcément utiliser GWT, il me semble donc que l'architecture du web
> impose qu'une partie du code client soit préparée par anticipation et non
> généré à la volée : cela permet de la publier sous forme de documents
> statiques, qui est la clé de voute de la montée en charge de tout site.

Ce n'est pas ce que les gens de Echo disent :
http://echo.nextapp.com/site/node/102

Voir aussi une comparaison datant de 5 ans entre GWT et Echo 2 :
http://echo.nextapp.com/site/node/25

Il me semble que Echo 3 peut être utilisé pour envoyer des mises à
jour vers le navigateur. Cela semble répondre au besoin pour diriger
la construction dynamique
d'une IHM par règles .

Maintenant, il y a un autre cas d'utilisation.
C'est celui où on a *déjà* un HTML créé à la main.
On veut alors interagir avec cela .
Mais en gardant le bénéfice d'un traitement des évènement par règles.
L'idée que j'ai là, c'est : si on intercepte tous les évènements HTML
en JavaScript, on peut les renvoyer vers le serveur sur la socket,
sous forme d'une message N3 .

[Cyril Hansen]

En effet, mon opinion sur l'architecture web n'est pas partagé par tout le monde, loin s'en faut. Echo2 et 3 est un framework coté serveur, utilisant une approche de client "léger", mais on peut donner aussi Vaadin (basé sur GWT!) ou même JSF comme exemple.

Votre deuxième lien (http://echo.nextapp.com/site/node/25) contient une discussion assez honnête du sujet qui me préoccupe. L'avis de l'auteur c'est qu'au final c'est la bande passante réseau et la latence qui limite les performances avant la capacité serveur. Il me semble que cela dépend vraiment des applications et du nombre d'utilisateurs simultanés.

Je ne vois donc pas d'impossibilité à votre architecture de client léger utilisant un protocole basé sur des règles. La difficulté et le point qui attire ma curiosité porte plutôt il me semble sur le moteur de règle que vous utiliserez coté client.

Par contre, vous comprendrez que mes choix techniques en ce qui concerne mes devs soient différents. Je vois le web comme une plate forme cible plus qu'une architecture : Il ne faut pas oublier que maintenant il est possible d'embarquer de petites bases de données dans le navigateur (http://debray.jerome.free.fr/index.php?articles/L-api-websql-en-html5) et de faire tourner des applications entières depuis le cache même en l'absence de connection. En ciblant ce mode de fonctionnement, je m'oblige à un déploiement sous forme de client lourd. Evidemment si vous ciblez d'autres uages, les possibilités sont différentes.

Pour ce qui est de récupérer tous les évènements de la page web d'un coup, c'est possible et je peux vous indiquer le code de GWT qui fait cela à titre d'illustration :

Ceci se fait dans la méthode initEventSystem() de la classe DOMImplStandard :

http://code.google.com/codesearch#T04cSGC7sWI/trunk/user/src/com/google/gwt/user/client/impl/DOMImplStandard.java&q=previewEvent%20package:http://google-web-toolkit%5C.googlecode%5C.com

/*-{ et  }-*/ indiquent un corps de méthode en javascript "natif".

Cordialement,

Cyril HANSEN

[Paul HOSSENLOPP]

Bonjour, en lisant vos échanges (avec intérêt), je pense à Ulteo, dont la v3.0 vient de sortir. À toute fin utile : Ulteo (GPLv2) facilite le déploiement d'application La version 3.0 vient de sortir le 8 février 2012 : << version finale Ulteo OVD v3 : Ulteo, la startup commerciale Open Source est fière d'annoncer la sortie (18 mois d'effort de R&D) de sa solution de délivrance d'applications, OVD v3.0  >> Je cite encore : << Cela signifie par exemple la possibilité de publier des applications Linux et/ou Windows (avec RDS/TS), dans différents modes, dont Portail ou Bureau, mais aussi le mappage dynamique des disques locaux et des partages, l'impression, ou l'intégration à des sites web commerciaux ou portail. L'expérience utilisateur a également été étendue par la réalisation de clients OVD pour iPad et Android, d'un client natif pour Windows et Linux permettant une intégration des applications distantes dans le bureau local de l'utilisateur (mode seamless). Enfin, l'utilisation est possible aussi bien en LAN qu'en WAN avec le module OVD Gateway >> pour Ulteo v3, voilà l'annonce au complet Cordialement :) --- En date de : Lun 6.2.12, Cyril Hansen <cyril....@gmail.com> a écrit :

[Jean-Marc Vanel]

Merci Cyril pour les suggestions.

J'ai écrit un petit "comment faire" pour faire marcher Wicket avec EulerGUI :
Je préfère passer du temps à améliorer le générateur de formulaires existant .
Et j'espère donc que quelqu'un d'autre aura le temps et l'envie de le faire.

Le 6 février 2012 08:22, Cyril Hansen <cyril....@gmail.com> a écrit :
...

> La difficulté et le point qui
> attire ma curiosité porte plutôt il me semble sur le moteur de règle que
> vous utiliserez coté client.

Pas besoin avec Wicket .

Par ailleurs, je n'exclus pas à terme de faire tourner un agent
intelligent basé sur règles N3 dans le navigateur.
D'ailleurs Jos de Roo a écrit un moteur en JavaScript, mais je ne sais
pas le statut de ça .
Il ne fait que 108 lignes :
https://eulersharp.svn.sourceforge.net/svnroot/eulersharp/trunk/2006/02swap/euler.js

[Jean-Marc Vanel]

Le 11 février 2012 17:31, Jean-Marc Vanel <jeanmar...@gmail.com> a écrit :
> Merci Cyril pour les suggestions.
>
> J'ai écrit un petit "comment faire" pour faire marcher Wicket avec EulerGUI :

http://eulergui.svn.sourceforge.net/viewvc/eulergui/trunk/eulergui/html/webapp.html