Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Tiens c'est délire ça !
Effectivement c'est une bonne idée pour empaqueter une appli Web. Ca fait quelques Mo de moins en mémoire à l'exécution. On peut aussi bloquer les touches de navigation pour éviter le F5 parfois fatal aux appli massivement AJAXisées.
Et un d'plus en moins !
et PUT et DELETE, c'est fait pour les mamies ?Envoyé par hackingcode
Perso je trouve que ce qu'il manque c'est une vraie solution d'impression ... c'est encore trop compliqué d'imprimer une bete feuille sans avoir tout un tas de complications ...
La meilleure solution que j'ai trouvé c'est utiliser xulrunner et un client léger en xul pour naviguer ... mais il bug avec les popup
Perso je trouve que ce qu'il manque c'est une vraie solution d'impression ... c'est encore trop compliqué d'imprimer une bete feuille sans avoir tout un tas de complications ...
La meilleure solution que j'ai trouvé c'est utiliser xulrunner et un client léger en xul pour naviguer ... mais il bug avec les popup
Et puis ca ne marche pas avec IE, non ? Pour faire une version d'impression, il faut avoir un template bien adapté et en faire un pour chaque situation me semble assez complexe - pas tant techniquement, mais c'est surtout au niveau interface où ceux qui ne connaissent niXUL et à peine PDF (ca fait du monde) vont être bien perdus !
Gmail fonctionne très bien avec les retours en arrière. Et pour F5, rappelons qu'à chaque fois que l'on fait une requete (ajax ou pas), il faut mettre des sécurités dès qu'il ne s'agit pas d'un GET tout bête.
On peut très bien clique deux ou trois fois sur un bouton SUBMIT sans ajax.
Ben, AIR, c'est ça en gros : un moyen de faire tourner du Flex sans navigateur. Et comme la partie html de notre application se limite en fait à inclure l'élément Flash développé avec Flex dans la page, ça a été assez simple à faire.
Un truc assez curieux dans les attentes des gens : quand un utilisateur appuie sur précédent alors qu'il est dans une application Flash, ça ne le choque pas que ça revienne à la page où il se trouvait avant de d'arriver sur cette appli, alors qu'avec Ajax, comme ça ressemble à un fonctionnement web traditionnel, ils s'attendent à pouvoir naviguer dans leur application. C'est une grosse différence dans les attentes des utilisateurs, je pense.
Salut,
Je m'excuse si je fais hors sujet je veux développer un client "lourd" j'ai fait des recherches et je tombe sur ce débat riche et j'en profite pour poser mon problème.
Je développe une application web et je voudrais intégrer les touches de fonction pour une meilleur intéractivité avec l'utilisateur par exemple faire de tel sorte que la touche F3 lance l'impression de la page courante ou que F1 ouvre l'aide de l'application; mais je ne sais pas comment le faire
Je suis à l'écoute.
synthèse client riche XML (lettre au père noël)
Bonjour à tous,
Je reprend ma précedente lettre au père noël pour la compléter et modifier certaines parties.
ce qu'il faudrait en fait c'est une technologie qui fonctionne sur tous les postes clients (mac, windows, linux).
Naturellement celle-ci doit permettre la réalisation d'applications RIA et RDA et mobile performantes avec un seul code (XML de présentation, style et code) pour tous les systèmes et dont le téléchargement serait pris en compte soit directement par le navigateur soit par un plug-in intégré au navigateur soit directement utilisable par un navigateur XML installé en local sur le poste de travail.
Naturellement, les applications interprétées seraient téléchargées dynamiquement à partir de serveurs web de tous types (IIS, J2EE,...) le tout via des requêtes HTTP standards post et/ou get ou autres.
En outre, les données pourraient être accédées via web services, rest, ou un autre flux (csv?) avec un simple process distant de type page asp, jsp, servlet, php,....
De plus, il y aurait un binding automatique des données en provenance du serveur web avec les objets graphiques de façon à ne pas coder les remplissage des champs de saisies ou des widgets situés dans les pages affichées.
Naturellement, il y aurait également la possibiliter de faire du binding inter objet dans une fenêtre ou inter objet entre plusieurs fenêtres.
On pourrait également donner un sens aux données du binding objet --> objets ou objet <--> objet ou objet <--- objet.
Il y aurait également la possibilité de gérer les données que l'on veut poster au serveur web via un simple paramétrage de la présentation et ce, avec les objets de plusieurs fenêtres.
êtes vous toujours d'accord avec ma synthèse ??
ais-je bien résumé les besoins ?
Ce sont des reflexes. C'est comme le simple clique sur internet et le double click dans windows. Le double click sur internet n'est pas utilisé et c'est pas logique pour l'utilisateur.
Tu as raison de soulever ce point. La seul solution c'est d'ouvrir l'application dans une popup à condition qu'ils n'utilisent pas la touche "back". Mais même cela c'est dérangeant de travailler sur une fenêtre ne ressemblant pas à une fenêtre web. De plus, certain seront déboussolé de ne plus voir leur onglet.
Mon avatar ? Ce n'est rien, c'est juste la tête que je fais lorsque je vois un code complètement frappa dingue !...
back et popup's
Lors du développement d'une application web d'entreprise (en intranet), il semble que les utilisateurs soient encore très habitués à leurs applications client serveur traditionnelles (vb , delphi ou autres) ce qui explique leur demande de richesse fonctionnelle en local et leur soif de fenêtrage multiple.
Il est tentant d'essayer de refaire la même chose avec les applications web mais elles sont naturellement limitées de par leur architecture de présentation et leur gestion de cinématique applicative (une seule fenêtre affichée à la fois pour du document centric) ce qui oblige à pratiquer certaines manoeuvres de gestion de contexte fonctionnel et de cinématique applicative (d'ou la multiplicité des framework que l'on a vu fleurir ces dernières années de struts à jsf et j'en passe).
Ajax est, d'une certaine manière, un pont entre les applications web standard et les application multi fenêtrage. Bien entendu, cela résoud certain problème puisque dans une même page on simule plusieurs (mini) pages (par réaffichage généralement) c'est ce qui existe aujourd'hui pour certain RIA ou donnés comme tels par le marketing des éditeurs. Mias cela pose d'autre soucis notamment en terme de maintenance.
Bien entendu et depuis des années, en entreprise les DSI essayent de promouvoir les applications web pour des raisons de TCO et d'homogéneisation du parc applicatif, des moyens de communication et de limitation des coûts de déploiement (entre autre chose).
Pendant longtemp, il n'y a pas eu de solution pratique pour limiter cette résistance au changement des utilisateurs tout en leur offrant des solutions "riches" en multifenêtrage avec l'utilisation des standards du web (ce qui devrait contenter tout le monde du DSi à l'utilisateur) .
Aujourd'hui le client riche évolue dans ce sens et propose des solutions qui semblent matures (le meilleur des deux monde en somme !) Mais la prise en compte du client riche passera obligatoirement par une évangélisation des utilisateurs que nous sommes et la mise en place d'outils d'une plus grande maturité et adaptés à un cycle de développement complet de ce type de solution.
Mes utilisateurs, ils sont très content de ne pas avoir de multi-fenetre, de menus et de sous-menus !
Et il ne veulent pas pleins de fonctionnalités et d'options, ils veulent que ce soient le programme qui fasse le boulot, en comprenant leurs besoins.
Mais les besoins exprimés par une maitrise d'ouvrage peuvent être simple ou compliqués et un programme qui fait "beaucoup de travail" comporte généralement plus de richesse fonctionnelle donc probablement plus de possibilité graphique. Néanmoins je connais également des utilisateurs telnet qui sont très content de leur interface ;-)
mais j'ai rien contre telnet ;-)))
Exact. D'ailleurs, ouvrir une pop-up, c'est ce qu'on a a fait avec Kizoa. Cela dit, on pourrait imaginer que les éditeurs de technos RIA intègrent la gestion de l'historique. Ca serait une fonctionnalité plutôt cool.
excusez car j'ai pas pu lire tout le débat donc je vais sûrement dire des trucs qui ont déjà été dits...
le rich client web et c'est pas de tout repos pour les sucs gastriques, parce qu'on est forcément dépendant d'une techno qui peut se casser la gueule n'importe quand, on perd un max de temps à anticiper des reconversions, à apprendre des trucs qui au final vous serviront à rien, on peut même se retrouver avec des mois de boulot bons pour la poubelle, des coups à couler sa boîte, on flippe à chaque fois qu'on a des rapports de bugs liés à la techno choisie, etc... tout ça accroît les risques d'ulcère
L'ajax c'est encore la valeur la plus sûre (à mon avis mais je peux me gourrer) car on peut toujours s'adapter aux évolutions des navigateurs web, mais ça coûte cher en temps de travail, à chaque update de navigateur on stresse, bref ça demande plus de boulot que du flash-sliverlight-etc pour un résultat moins bien.
Pour le moment je reste sur le standard flash aprce que c'est nettement plus productif mais vu comme adobe le transforme en usine à bugs (bosser sur la version cs4 devient bien relou) je croise les doigts et j'éspère que ça va pas se vautrer dans l'avenir (même si ça m'a l'air de tenir encore la route pour le moment)
j'ai pas beaucoup de conseils à donner pour faire avancer le shmilblick donc désolé si mon intervention est pas d'une utilité farouche mais ça fait du bien de vider son sac...
Hmmmf, en terme de productivité, je pense que les applets Java détronent tout. Mais c'est pas joli
ça dépend... l'applet java est plus productif que flash pour un développement sérieux car on peut récupérer plein de libs et on galère pas à trouver des tonnes d'optimisations pour script qui rame
par contre pour des contenus dans lequels on investit pas plus de 2 heures de travail et qu'on demande au graphiste d'apprendre l'actionscript parce qu'on veut pas payer un dev, flash l'emporte haut la main en matière de productivité vu que le graphiste peut faire un tchat en flash d'un coup de drag and drop (et la camelote pas cher ça se vend bien)
devant une concurrence aussi déloyale les applets java pourtant bien meilleurs se sont vautrés, maintenant ça s'intègre mal dans les pages web, ça marche pas sur opera, c'est mort, idem pour tous les super plugins 3d ils se sont pétés la tronche et pour la même raison, contenus trop cher à fabriquer pour ce que ça rapporte
plus c'est pourri et plus l'avenir de la techno est robuste, la seule qui a un avenir assûré c'est le javascript... le reste c'est entièrement dépendant des données économiques et des jeux de concurrence, même le flash il y'a des dev qui refusent d'en entendre parler, pas de techno propriétaire sur leurs sites
Super post, ca sent le vécu
Oui, les applets ca fait un peu old scool, surtout avec les technologies alternatives disponibles en java :
- GWT
- JavaFx.
Pas vraiment d'accord. GWT ne donne pas un rendu plus joli qu'une applet avec un L&F valable, et JavaFx est pour l'instant mal documenté et peu soutenu par les IDE, et surtout sera probablement mal acceptée par votre clientèle.
Ensuite Swing est bien plus facile à programmer que GWT et surtout s'il faut débugguer.
Pour moi c'est équivalent, aux animations près (en js les animations sont poussives).
Aujourd'hui oui. Mais ne pas négliger l'effet marketing. A voir dans le futur.
Tu m'en vois surpris, parce que Swing n'est pas un modèle de simplicité. En outre, tu peux très bien débugger sous GWT en hosted mode. Certes, il faut faire confiance au code généré (ou à la lib js sur laquelle on s'appuie), c'est là la limite.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager