Solution RIA simple et puissante
Gilgamesh
Membre
Bonsoir,
Je sollicite a nouveau vos avis d'expert en matière de programmation en vous posant une question plutôt complexe et requérant une certaine dose d'objectivité.
Je suis a la recherche d'une solution de mise en place d'une RIA simple dans sa programmation mais puissante dans son traitement de bases de données et riche au niveau de son IHM. J'ai pu voir Cappuccino, Google app toolkit, Open Lazslo et bien sur Flex.
j'ai déjà renoncer a Flex et Open Lazslo car ils se basent tout les deux sur du Flash que je veut éviter absolument.
Je me suis renseigné sur Cappuccino en ObjectiveJ, mais peut être compliquer a mettre en oe“uvre.
JavaFX me semble tres lourd, leur site est long a charger en 1M sans autres navigations ou IM a coté.
Donc voilà je me trompe surement sur mes points de vue sur ces technologies, j'en ai surement raté d'autres.
Quel est votre avis, vos expériences, vos commentaires.
Merci de vos réponses.
Je précise que j'aimerais une solution libre d'accès et d'utilisation/commercialisation, donc sans licences.
Je sollicite a nouveau vos avis d'expert en matière de programmation en vous posant une question plutôt complexe et requérant une certaine dose d'objectivité.
Je suis a la recherche d'une solution de mise en place d'une RIA simple dans sa programmation mais puissante dans son traitement de bases de données et riche au niveau de son IHM. J'ai pu voir Cappuccino, Google app toolkit, Open Lazslo et bien sur Flex.
j'ai déjà renoncer a Flex et Open Lazslo car ils se basent tout les deux sur du Flash que je veut éviter absolument.
Je me suis renseigné sur Cappuccino en ObjectiveJ, mais peut être compliquer a mettre en oe“uvre.
JavaFX me semble tres lourd, leur site est long a charger en 1M sans autres navigations ou IM a coté.
Donc voilà je me trompe surement sur mes points de vue sur ces technologies, j'en ai surement raté d'autres.
Quel est votre avis, vos expériences, vos commentaires.
Merci de vos réponses.
Je précise que j'aimerais une solution libre d'accès et d'utilisation/commercialisation, donc sans licences.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Pour ce qui est de cappuccino, le principal avantage, c'est que si tu sais développer en cocoa, tu sais quasiment développer en Cappuccino, y'a que très peu de temps d'adaption pour passer de l'un a l'autre. On y retrouve la même syntaxe, les mêmes pattern, et tout et tout.
En plus avec leur IDE Atlas qui est en beta en ce moment, tu pourras même retrouver un IB like avec le systeme d'action, d'outlets, de connexion et tout et tout.
Sinon tu peux nous dire en quoi Cappuccino avait l'air compliqué à mettre en place ?
je viens de me renseigner, Atlas est en beta payante et limitée dans le temps.
Second problème, Cappuccino ne peut être dev que sur mac
C'est juste l'IDE qui est compatible uniquement Mac, pour le moment ! Il me semble qu'à terme ils souhaitent le rendre multiplateforme.
En fait c'est juste des outils comme NibToCib que tu peux pas utiliser, vu que ça convertit les nib (enfin, xib) de interface builder en cib, utilisés par Cappuccino.
Sinon muqaddar, pour commencer, vu que Objective-J et un superset de JavaScript, et que les objets JSON sont des objets JavaScript (en gros), alors l'objJ gère nativement le JSON.
Pour le XML il me semble aussi qu'il y a ce qu'il faut, à vérifier.
Merci.
C'est vrai que je vais m'y intéresser sous peu... il faudra que je vois comment coupler ça à Rails et Ruby pour les entrées/sorties de données.
J'adore ce lien ! Merci.
Si tu te lance Muquddar tu pourrais me faire part de tes impressions ?
très complet pas simple à mettre en oeuvre
beaucoup plus léger
ExtJS app en javascript IHM tres complete simple à mettre en oeuvre
repose sur la techno de son choix côté server.
Je l'utilise avec Zend FrameWork
il existe un version GWT
bref Google Web Toolkit avec les classes de ExtJS pour obtenir une HIM très pro
tu peux aussi voir du coté de JAXER http://www.jaxer.org/
voir aptana.com http://www.aptana.org/
A+JYT
Oui, mais pas avant 3 ou 4 mois...
Sinon, on en a déjà parlé là :
http://www.pommedev.com/forum/index.php?topic=5121
Passé en version 1.0 ce week-end. Mais je n'ai pas d'expérience dans sa mise en oeuvre.
Pour ma part j'ai jamais réussi à faire ce que je souhaitais avec sproutcore. Deplus la partie serveur que j'utilise est souvent en PHP.
Et ça se marie mal avec PHP ?
Disons juste que ça se marie mieux avec RoR. Mais comme je suis pas un fan de RoR (je ne m'y suis pas pencher dessus). Les appels ajax sont tous sous forme d'url : /module/var1/var2/ d'après mes souvenirs (ça fait un bon moment que j'ai pas tester sproutcore).
Je suis également à la recherche de quelque chose me simplifiant la vie pour le dev des RIA. pour le moment j'utilise mes propre biblio avec prototypejs. Mais capuchino m'interesse de plus en plus même si j'en connais pas même un 1%. Le simple fait que cela est basé sur le Mac et Obj-C me plait ! Vive le Mac ! Vive Obj-C ! :P
Perso j'utilise depuis 2 ans Flex et pour le développement d'application dans le cadre d'un entreprise c'est vraiment un bonne solution.
Attention, on parle bien d'applications d'entreprise, pas de faire un site web, un blog ou une galerie photo, mais bien un outil utilisé par des personnels d'une entreprise.
Les avantages qui j'y vois :
- langage objet puissant (actionscript)
- bibliothèque riche et adaptée au développement dans le cadre pro (framework Flex)
- gestion aisée du layout (position des éléments à l'écran)
- intégration d'animation simple
Ce qu'il faut savoir c'est que Flex n'est qu'un framework, tu peux tout coder uniquement en actionscript et c'est d'ailleurs ce que je fais le plus souvent, je construit mes composants en actionscript et Flex ne me sert qu'à gérer le layout
J'ai découvert il y a peu cappuccino et ce produit semble vraiment intéressant et la communauté active.
Pensant avoir découvert un bug sous Chrome (l'application "hello world" ne fonctionne pas), j'ai ouvert un ticket et le lendemain j'avais un message m'indiquant que c'est un bug de Chrome qui ne peut faire de requête ajax en local (url : file://)
Le projet est donc vraiment actif, y'a qu'à suivre ce dernier sous Google Code pour s'en persuader
Comme j'ai la chance de développer sous mac, le fait que les outils soient sur cette plateforme ne me dérange pas (au contraire)
Reste que si le projet pouvait être soutenu par Apple, ça lui donnerait encore plus de poids
Pour finir, je pense qu'il ne faut pas chercher la solution magique, si tu maà®trises bien les concepts de programmation (OOP, patterns ...) tu pourras t'adapter facilement.
Je me souviens de le phrase d'un formateur Flex en introduction : "si demain tout le monde veut du Silverlight, je ferais du Silverlight"
Si tu veux en faire ton métier, il faut avant tout être compétent dans les domaines qui sont recherchés, ou alors tu peux être idéaliste et ne chercher qu'à faire ce que tu aimes ....
Bon dev et bonne recherche
SproutCore me semble plus brouillon, Cappuccino a l'air bien géré... je parle d'après ce que j'en ai vu car je n'ai pas encore développé avec. En tout cas, pour des RIA, ça semble être une solution élégante.
Et surtout parce que c'est un framework JS basé sur Cocoa (au niveau de la structure)... de quoi avantager bien des devs Cocoa !
je dois dire que je trouve moi aussi cette approche sympathique.
mais il y a quelques petites choses qui me gênent
cib : cib c'est le format NIB pour Coppucino. en fait NIB d'apple c'est en gros (à la louche un dictionnaire) l'équipe de Cappuccino a mise au point son équivalent mais cette fois les clef valeurs sont véhiculées dans du JSON pour quoi pas. mais cela à un inconvénient il faut soit utiliser un produit dédié (il en vendent un) soit convertir le IB en CIB
alors que InterfaceBuilder produit XIB nativement XIB c'est NIB en XML
pour lire un CIB cappuccino utiliser XMLHttpRequest mais laisse tomber le fonction native de l'objet pour ne gérer que HttpRequest
alors que s'il utilisait XML XIB donc XMLHttpRequest parserait pour eux le fichier en question.
CIB est plus léger mais moins facile à mettre en oe“uvre et nécessite d'embarquer un interprète en JS pour le lire. c'est très marginal mais je trouve ça dommage.
deuxième petite chose gênante mais là beaucoup plus c'est impossibilité de changer le thèmes de l'interface;
Ce n'est pas tant que la changement de thème soit une fonctionnalité primordiale. Mais que lorsqu'on développe pour une entreprise on ne puisse pas fournir une application respectant les règles de l'IHM de la maison.
pour finir objective-J
là je dis chouette génial etc. un vrai langage de programmation structuré sur le navigateur. Mais revers de la médaille
le debug c'est la croix. pas de point d'arrêt pas de pas à pas c'est une boite noire et on ne sais pas ce qu'il se passe.
c'est un bricolage pas possible que je chasser le bug la dedans.
solution développement itératif on fait un tout petit bout on le teste re teste et re re teste puis on commence à assembler deux petit bout qu'on va tester et re tester puis trois etc. si on s'aventura à assembler d'un coup beaucoup trop de chose et qu'un bug apparait il est très difficile de le trouver.
bref quelques petits défauts
un très gros manque de maturité
beaucoup de potentiel
et un point rédhibitoire en entreprise l'impossibilité d'adopter le thème de l'entreprise.
A+JYT
Donc le format JSON, c'est natif en JS (par définition, puisque JSON c'est du Javascript, JSON voulant dire "JavaScript Object Notation"). Donc pour interpréter le JSON d'un CIB... bah c'est directement intégré et natif au langage javascript, y'a pas besoin d'avoir de parseur ou quoi. Un simple "eval" sur la chaà®ne et le tour est joué.
Donc au contraire c'est plus simple à gérer qu'un XML, en tout cas en JS !
je me demandais également comment personnaliser le thème par défaut, j'ai ma réponse
je reste de toute façon branché dessus, Apple va bien finir par les racheter ^^
pas vraiment effectivement tu va pouvoir utiliser eval bien que ce soit ce qu'il est surtout recommandé de ne pas faire.
mais tu vas donc passer par l'interprète javascript pour obtenir un objet Javascript et non un dictionnaire objective-J
avec XML tu n'as rien a faire XMLHttpRequest Get monurl.ver.une.resource.xml
response.getXML() te donne non pas le source XML mais un DOM complet déjà instancier de ton XML.
pour cela XMLHttp.request utilise le parser XML natif de la plateforme (webkit)
c'est rapide et peu gourmand
pour JSON il est très forement recommendé d'utiliser un parser.
il y a somme tout des différence entre jsonparser et eval
http://json.parser.online.fr/ pour comparer
pour les navigateur n'embarquant pas nativement jsonParse http://www.json.org/json2.js
A+JYT
Mais je voulais surtout montrer que JSON était un type natif (par définition) de JavaScript.
Après je savais pas qu'il existait des "dictionnaires Objective-J" : je pensais que c'était un Object (la classe "Object" de Javascript, quoi) dont Cappuccino avait modifié le prototype (genre qu'ils avaient fait [tt]Object.prototype.dictionaryWithObjectsAndKeys = function() { ... }[/tt] pour rajouter la fonction dictionaryWithObjectsAndKeys à la classe Object tout comme ils auraient pu faire [tt]Array.prototype.arrayWithObjects = function() { ... }[/tt] pour rajouter arrayWithObjects à la classe javascript "Array" déjà existante)
Du coup un eval (ou plutôt un parsing avec un parseur JSON qui assure la sécurité et évite le risque d'exécution de code malicieux) classique (que tu pourrais faire même dans un contexte autre qu'Objective-C) te retournerait un "Object", comme habituellement en javascript quoi... sauf que cet Object, de par les ajouts de Cappuccino, pourrait être vu comme un NSDictionary...
Mais bon je dis ça plein de suppositions, je n'ai jamais mainpulé Cappuccino, alors bon...
mais le tout m'a laissé l'impression d'un désir de fermer le tout
des format propriétaire et vente d'outil pour aller avec alors que IB + XMLHttpRequest sont dispos et gartuit
un débug hermétique + vente de formation
etc...
je me trompe peut-être mais c'est le sentiment que j'ai eu
j'ai porté un bout du code de renaissance qui est un projet GnuStep ou gmaker (le NIB de gnustep est remplacé par du xml donc un truc proche de XIB. plus ancien que XIB ) juste pour voir
coté perf nikel et pas de difficulté majeure. (sauf le débug de la chose)
mais j'ai juste testé la faisabilité.
bref j'aurais bien vu un support d'objective-j et du framework intégré à Xcode plutôt qu'un dev proprio
pour moi le frein c'est impossible en l'état de m'adapter à l'entreprise et le debug
pour ce qui est du thème il faut retoucher au coeur de cappuccino les images et autre css étant embarqué dans le code du framework
A+JYT