Salut,
      Plutôt impressionnant le résultat obtenu avec une migration sous APPEON ( effectué sous EAS ).
      Les temps de réponses sont plutot impressionnant.

      Peu de fonctionnalité non supportés. ( Dans le cadre d'une utilisation normale de PB voir poussé ) :
       Les gros risque sont l'utilisation de fonctionnalités tels que FindclassDefinition , Findmatchingfunction etc.. qui  fonctionnent sur la librarylist. ( après le déploiement vers le web cette notion n'existe pas ). 
      Ce n'est pas le cas pour la fonction className() qui elle est supportée. Sinon sur les datawindows quasiment toutes les fonctions sont supportées. ( Sur une dizaine de migration vers appeon j'ai eu un seul problème avec la fonction reselectRow qui elle n'est pas supportée.)
par contre j'ai eu des petits soucis avec du code qui manipulait la clause where d'une datawindow pour la rendre dynamique ou là il faut être très rigoureux dans la syntaxe. Mais globalement peu de soucis.

       Le point négatif soulevés par les utilisateurs après le déploiement est qu'ils ne comprennent pas pourquoi on a un look windows de l'application alors que l'on se trouve sur internet explorer.


       Il n'y a pas de licence par utilisateurs.
             Tu as des licenses  développeurs ( vraiment pas cher) permettant de  déployer ( compiler  ....etc) et il est quasiment necessaire d'en avoir une par développeur. afin de produire et de tester son code de manière séparé sans ennuyer le collègue.
              Tu as des licenses de production qui elles ne comprenent pas la partie développeur ( comprend le serveur web EAS <si c'est le choix effectué par l'entreprise>  plus tout le framework appeon ainsi  l'activeX utilisé sur les postes clients. Mais pour les licenses tu peut te rapproché de la commerciale france qui s'en occupe : Son nom est je crois PASCALE ELKOUBI.

L'OLE WORD , EXCEL etc.. fonctionne  , La sortie PDF fonctionne etc....   

L'un des points que j'ai du revoir chez certains clients c'est la partie connection à la base de donnée. Si l'utilisateur se connecte à l'aide d'un LOGIN déclaré au niveau du SGBD il est nécessaire de revoir cette partie pour avoir une connection à l'aide d'un USER unique et de gérer la connection utilisateur au travers d'une table contenant les codes users et les mot de passe. La connexion étant gérer au travers d'un pool de connection. 

Si tu as besoin d'info sur des éléments en particulier ou sur lesquelles tu te pose des questions avant de faire le choix de APPEON n'hesite pas je te dirais si j'ai eu à traiter ce genre d'éléments et si j'ai eu des soucis ou non.




Mais je reste agréablement surpris du résultat obtenu avec APPEON.
.

Yanis

Hello,

Alors... Cela fait maintenant 1 an que j'ai repris des appli existantes sous Appeon... Cela fonctionne plutôt pas mal !
Via VPN, on a quelques ralentissements mais je pense que c'est lié aux images à afficher et aux quantités de données.

Sinon, niveau problème de déploiement, j'en ai rencontré 1 seul cf : http://pbadonf.fr/forum/viewtopic.php?id=3360

Les 2 seuls retours négatifs des applis APPEON :
- le look old school et non web
- le fait de devoir passer par IE ou IEtab (sous FF)

L'autre point négatif mais provenant de mon côté (ou alors c'est un mauvais paramétrage du serveur) :
- c'est l'impossibilité d'ouvrir plusieurs appli APPEON en même temps ! o_O

Enfin, niveau licence, rien à ajouter aux propos de Yanis.

Bonjour à tous,

A noter que l'on peut faire avec  PowerBuilder un look Web autrement dit une ergonomie WUI, Web Unit Interface et non GUI (Graphical Unit Interface), certes cela demande une adaptation notamment l'abandon du mode MDI mais à l'arrivée il n'y a plus aucune différence avec une application qui serait développée avec une technologie full Web comme PHP.
Actuellement je termine une application PowerBuilder qui fonctionnera sous APEON qui est rigoureusement en ergonomie WUI.

Dernière modification par Dadone (29-06-2012 10:16:39)

Merci pour ce retour d'expérience détaillé, et pour cette énumération des divers pièges à con qui parsèment l'utilisation d'appeon

erasorz a écrit:

pour ces infos

En ce qui concerne :

Dadone a écrit:

--> Nous avons constaté des dysfonctionnement en utilisant la fonction setitem(), par exemple nous avons du remplacer le code suivant :
    idw_donneur.setItem(ll_rowInsert , "atd_grou" ,astr_duplication[ll_indice].groupeDonneur)
par le code
    idw_donneur .object.atd_grou[ll_rowInsert] = astr_duplication[ll_indice].groupeDonneur

pourtant techniquement strictement identique, pour la même problématique  toutes routines génériques qui fait des affectations en utilisant setItem risque de dysfonctionner sous APPEON

alors là c'est le GROS point noir
le nombre de fonctions que j'utilise avec des setitem sur un nom de colonne variable

Attention, ce n'est pas toujours le cas, nombre de fois le setItem fonctionne correctement mais de temps en temps il y a un problème...sans que l'on sache pourquoi...
Une fois que l'on est prévenu, on fait avec.
Plus gênant ce sont les règles de gestion codées dans les propriétés des objets datawindow, là on dégrade l'ergonomie si on s'en passe...

Dernière modification par Dadone (19-09-2012 12:29:56)

erasorz a écrit:

Comment tu fais pour contourner le problème de setitem quand il survient ?

J'ai utilisé la notation pointée où nous avons constaté les dysfonctionnements. Dysfonctionnements qui apparaissaient lors de la mise à jour car certains champs n'ayant pas été affectés, cela déclenchait une erreur DB.

Une fois cela à poser problème car j'ai écrit une routine qui simulait la fonction PowerBuilder rowscopy() mais en filtrant certain champs lors de la copie. Elle n'est pas passée sous APPEON, résultat au lieu d'une ligne d'appel, j'ai du procéder à des  dizaines d'affectations avec la notation pointée avec à chaque fois le risque de faire une faute d'orthographe...Je me suis transformé pour un temps en opératrice de saisie...

Dernière modification par Dadone (19-09-2012 12:48:24)

erasorz a écrit:

Dadone a écrit:

résultat au lieu d'une ligne d'appel, j'ai du procéder à des  dizaines d'affectations avec la notation pointée avec à chaque fois le risque de faire une faute d'orthographe...Je me suis transformé pour un temps en opératrice de saisie...

c'est bien ce que je redoutais
sans compter les traitements génériques où le nom de la colonne n'est pas connu d'avance

tu peux toujours faire une bricole de ce type :

long col_id
col_id = long( dw_1.describe(ls_col_name+".id") )
dw_1.object.data[ row, colid ] = val

mais çà rajoute de la lenteur au beans ( déjà que la notation avec object est plus lente )...

xlat a écrit:

tu peux toujours faire une bricole de ce type :

Code: pb

long col_id
col_id = long( dw_1.describe(ls_col_name+".id") )
dw_1.object.data[ row, colid ] = val

Je retiens l'astuce, je vais peut être essayé en modifiant ma routine perso rowscopy() pour voir si elle passe sous APPEON

Affaire à suivre..

Yanis a écrit:

Ce que moi j'ai pris pour habitude avec appeon, c'est de debugger systématiquement l'application pour voir si tout le code de ma fonction ou de mon événement s'effectue bien avec bien entendu tous les cas possible pour ma fonction ou evt .

Quand on voit à quel point le debugger PB est un menteur (= buggé) ça fait un peu peur de devoir passer par ça comme validation du code pour être sûr que ça ne plante pas silencieusement.

Je dis ça par exemple en pensant au nombre de fois où j'ai traçé une fonction qui retournait "true" et une fois revenu dans le code appelant, la valeur retournée était devenue "false" (et inversement). Ou alors aux plantages instantanés quand on a "classname()" dans un watch et qu'on se retrouve à l'intérieur d'une fonction globale... Boum !