[Long] Retour de Test sur Windev Java Phase 2 suite et Fin

Le
Daniel
Suite de la phase 1.

Pour rappel développement d'une application Java avec Windev. Expérience
très positive avec une interrogation sur JDBC, et un gros regret du
manque de documentation.

J'ai enfin réussi à passer les options qu'on veut au connecteur JDBC.
(je pense au autoreconnect).

La phase 2, va consister à découvrir un peu plus les entrailles de la
bête, et de voir ce qu'on peut faire en terme de code.

Pour faciliter l'écriture d'une application en Java il est préférable de
le faire dès le début du projet.
Lorsqu'on développe en mode Java on écrit bien du Wlangage.
Ecriture de code Java directement. C'est possible en procédure globale
en cliquant sur le WL dans le code, ensuite on peut écrire en Java.
Attention Windev n'est pas un IDE Java, à moins de savoir ce qu'on fait
ou de copier du code, aucune aide à la saisie n'existe lorsqu'on écrit
du code Java.

C'est pratique. Toutefois il faut noter que le code de cette fonction
est complètement indépendant du code de l'application. Cette possibilité
est intéressante, mais le plus gros regret est qu'il n'est pas possible
de passer des arguments au code java. La solution pour passer des
arguments est JavaExecute et JavaExecuteFonction si on veut un retour.

Concernant le code Windev, de nombreuses fonctions ne sont pas
supportées, et comme par hasard c'est toujours celles qu'on utilise qui
manquent : thread, gestion des évènements, champclone etc

Les gros manques en terme de fonctionnalités ce sont les états (il y a
iimprime, mais à sa plus simple expression, pas de code barre, pas de
graphe), les graphes et les champs Web.

Pour les impressions, il ne faut pas hésiter à passer par iReport.

Pour les graphes, en l'état il serait nécessaire de faire un graphe avec
un outil externe (iReport le permet et il utilise JFreeChart) générer
une image qu'on intègre dans un supportant une image.
WD12 semble avoir les fonctions dDessin qui permettraient de faire les
graphes en codant tout, mais bon dans ce cas on va passer 100x plus de
temps pour créer des graphes. Et puis sous WD10 je n'ai pas dDessin.
J'ai donc opté pour une bibliothèques graphiques Java qui existe et qui
est bien fournie JFreeChart (il y a une démo sur leur site c'est
impressionnant), le manuel est payant quelques 10aine de dollars pour
une doc de 900 pages.

Pour les champs type Web Browser, en passant par swt ou d'autres API on
peut avoir un champs HTML.

Ces 3 manques (même dans WD12) ne sont pas anodins, car Java n'a pas
d'outil clé en main pour le faire.

En passant par Eclispse (ou un autre IDE) , il est possible de générer
sans aucun problème l'intégration de tous ces éléments dans
l'application Java développée avec Windev. Afficher un graphe dans la
fenêtre générée avec Windev est possible, et rien ne permet de
distinguer que le graphe ne vient pas de Windev (sauf que Windev sous
Java ne le fait pas, et que certains graphes n'existent pas sous Windev.).

En terme de performance, l'application Java fonctionne correctement (je
n'ai pas testé sur un OS différent de Windows).
Sur certains points l'application est même plus rapide qu'une
application compilée en Windev, je pense à l'affichage de fenêtre un peu
chargée avec des plans et des cadres spécifiques où l'application Java
est bien plus rapide sur l'affichage. A croire que la JVM est plus
optimisée que le FrameWork natif de Windev.

Pour conclure. Windev permet de faire des applications fonctionnant en
Java, même si il manque certaines fonctionnalités. Dans le cadre d'un
projet important il est évident qu'on va gagner du temps si on dessine
nos interfaces avec Windev, mais en l'état, il est vraiment nécessaire
de connaître les limites du produit (Java Limitation) et je pense
personnellement qu'il est indispensable d'avoir des bases nécessaires en
Java et en POO.

En exportant l'archive générée par Windev, on peut faire ce qu'on veut
et ajouter tout le code nécessaire et bibliothèque nécessaire en Java (à
priori on doit pouvoir le faire avec JavaExecuteFonction mais bon il
faut bien écrire la classe à un moment ou à un autre).

@+



--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pascal F
Le #17411231
Daniel avait prétendu :
Suite de la phase 1.

Pour rappel développement d'une application Java avec Windev. Expérience très positive avec une interrogation sur JDBC, et un
gros regret du manque de documentation.

J'ai enfin réussi à passer les options qu'on veut au connecteur JDBC. (je pense au autoreconnect).

La phase 2, va consister à découvrir un peu plus les entrailles de la bête, et de voir ce qu'on peut faire en terme de code.

Pour faciliter l'écriture d'une application en Java il est préférable de le faire dès le début du projet.
Lorsqu'on développe en mode Java on écrit bien du Wlangage.
Ecriture de code Java directement. C'est possible en procédure globale en cliquant sur le WL dans le code, ensuite on peut
écrire en Java. Attention Windev n'est pas un IDE Java, à moins de savoir ce qu'on fait ou de copier du code, aucune aide à la
saisie n'existe lorsqu'on écrit du code Java.

C'est pratique. Toutefois il faut noter que le code de cette fonction est complètement indépendant du code de l'application.
Cette possibilité est intéressante, mais le plus gros regret est qu'il n'est pas possible de passer des arguments au code java.
La solution pour passer des arguments est JavaExecute et JavaExecuteFonction si on veut un retour.

Concernant le code Windev, de nombreuses fonctions ne sont pas supportées, et comme par hasard c'est toujours celles qu'on
utilise qui manquent : thread, gestion des évènements, champclone etc...

Les gros manques en terme de fonctionnalités ce sont les états (il y a iimprime, mais à sa plus simple expression, pas de code
barre, pas de graphe...), les graphes et les champs Web.

Pour les impressions, il ne faut pas hésiter à passer par iReport.

Pour les graphes, en l'état il serait nécessaire de faire un graphe avec un outil externe (iReport le permet et il utilise
JFreeChart) générer une image qu'on intègre dans un supportant une image.
WD12 semble avoir les fonctions dDessin qui permettraient de faire les graphes en codant tout, mais bon dans ce cas on va
passer 100x plus de temps pour créer des graphes. Et puis sous WD10 je n'ai pas dDessin.
J'ai donc opté pour une bibliothèques graphiques Java qui existe et qui est bien fournie JFreeChart (il y a une démo sur leur
site c'est impressionnant), le manuel est payant quelques 10aine de dollars pour une doc de 900 pages.

Pour les champs type Web Browser, en passant par swt ou d'autres API on peut avoir un champs HTML.

Ces 3 manques (même dans WD12) ne sont pas anodins, car Java n'a pas d'outil clé en main pour le faire.

En passant par Eclispse (ou un autre IDE) , il est possible de générer sans aucun problème l'intégration de tous ces éléments
dans l'application Java développée avec Windev. Afficher un graphe dans la fenêtre générée avec Windev est possible, et rien ne
permet de distinguer que le graphe ne vient pas de Windev (sauf que Windev sous Java ne le fait pas, et que certains graphes
n'existent pas sous Windev.).

En terme de performance, l'application Java fonctionne correctement (je n'ai pas testé sur un OS différent de Windows).
Sur certains points l'application est même plus rapide qu'une application compilée en Windev, je pense à l'affichage de fenêtre
un peu chargée avec des plans et des cadres spécifiques où l'application Java est bien plus rapide sur l'affichage. A croire
que la JVM est plus optimisée que le FrameWork natif de Windev.

Pour conclure. Windev permet de faire des applications fonctionnant en Java, même si il manque certaines fonctionnalités. Dans
le cadre d'un projet important il est évident qu'on va gagner du temps si on dessine nos interfaces avec Windev, mais en
l'état, il est vraiment nécessaire de connaître les limites du produit (Java Limitation) et je pense personnellement qu'il est
indispensable d'avoir des bases nécessaires en Java et en POO.

En exportant l'archive générée par Windev, on peut faire ce qu'on veut et ajouter tout le code nécessaire et bibliothèque
nécessaire en Java (à priori on doit pouvoir le faire avec JavaExecuteFonction mais bon il faut bien écrire la classe à un
moment ou à un autre).

@+



Merci de ce retour.

--
Pascal

Ne garder que le prénom pour me joindre
Moua
Le #17433521
Daniel avait soumis l'idée :
Suite de la phase 1.

Pour rappel développement d'une application Java avec Windev. Expérience très
positive avec une interrogation sur JDBC, et un gros regret du manque de
documentation.

J'ai enfin réussi à passer les options qu'on veut au connecteur JDBC. (je
pense au autoreconnect).

La phase 2, va consister à découvrir un peu plus les entrailles de la bête,
et de voir ce qu'on peut faire en terme de code.

Pour faciliter l'écriture d'une application en Java il est préférable de le
faire dès le début du projet.
Lorsqu'on développe en mode Java on écrit bien du Wlangage.
Ecriture de code Java directement. C'est possible en procédure globale en
cliquant sur le WL dans le code, ensuite on peut écrire en Java. Attention
Windev n'est pas un IDE Java, à moins de savoir ce qu'on fait ou de copier du
code, aucune aide à la saisie n'existe lorsqu'on écrit du code Java.

C'est pratique. Toutefois il faut noter que le code de cette fonction est
complètement indépendant du code de l'application. Cette possibilité est
intéressante, mais le plus gros regret est qu'il n'est pas possible de passer
des arguments au code java. La solution pour passer des arguments est
JavaExecute et JavaExecuteFonction si on veut un retour.

Concernant le code Windev, de nombreuses fonctions ne sont pas supportées, et
comme par hasard c'est toujours celles qu'on utilise qui manquent : thread,
gestion des évènements, champclone etc...

Les gros manques en terme de fonctionnalités ce sont les états (il y a
iimprime, mais à sa plus simple expression, pas de code barre, pas de
graphe...), les graphes et les champs Web.

Pour les impressions, il ne faut pas hésiter à passer par iReport.

Pour les graphes, en l'état il serait nécessaire de faire un graphe avec un
outil externe (iReport le permet et il utilise JFreeChart) générer une image
qu'on intègre dans un supportant une image.
WD12 semble avoir les fonctions dDessin qui permettraient de faire les
graphes en codant tout, mais bon dans ce cas on va passer 100x plus de temps
pour créer des graphes. Et puis sous WD10 je n'ai pas dDessin.
J'ai donc opté pour une bibliothèques graphiques Java qui existe et qui est
bien fournie JFreeChart (il y a une démo sur leur site c'est impressionnant),
le manuel est payant quelques 10aine de dollars pour une doc de 900 pages.

Pour les champs type Web Browser, en passant par swt ou d'autres API on peut
avoir un champs HTML.

Ces 3 manques (même dans WD12) ne sont pas anodins, car Java n'a pas d'outil
clé en main pour le faire.

En passant par Eclispse (ou un autre IDE) , il est possible de générer sans
aucun problème l'intégration de tous ces éléments dans l'application Java
développée avec Windev. Afficher un graphe dans la fenêtre générée avec
Windev est possible, et rien ne permet de distinguer que le graphe ne vient
pas de Windev (sauf que Windev sous Java ne le fait pas, et que certains
graphes n'existent pas sous Windev.).

En terme de performance, l'application Java fonctionne correctement (je n'ai
pas testé sur un OS différent de Windows).
Sur certains points l'application est même plus rapide qu'une application
compilée en Windev, je pense à l'affichage de fenêtre un peu chargée avec des
plans et des cadres spécifiques où l'application Java est bien plus rapide
sur l'affichage. A croire que la JVM est plus optimisée que le FrameWork
natif de Windev.

Pour conclure. Windev permet de faire des applications fonctionnant en Java,
même si il manque certaines fonctionnalités. Dans le cadre d'un projet
important il est évident qu'on va gagner du temps si on dessine nos
interfaces avec Windev, mais en l'état, il est vraiment nécessaire de
connaître les limites du produit (Java Limitation) et je pense
personnellement qu'il est indispensable d'avoir des bases nécessaires en Java
et en POO.

En exportant l'archive générée par Windev, on peut faire ce qu'on veut et
ajouter tout le code nécessaire et bibliothèque nécessaire en Java (à priori
on doit pouvoir le faire avec JavaExecuteFonction mais bon il faut bien
écrire la classe à un moment ou à un autre).

@+



Bonjour Daniel,

Merci pour cette expérience.
Publicité
Poster une réponse
Anonyme