DojoToolKit et Rails

2006/11/16, philippe lachaise [email protected]:

vendor=“http://rubyforge.org/rite/”>

Tout à fait d’accord avec ta vision. Le prob c’est d’attendre 5 ans,
dans le
meilleur des cas … Rappelons que Microsoft va déployer sa propre
technologie comparable à XUL (XAML
Laurent Jouanneau),
ce qui, avec le troyen qu’est IE, devrait annihiler tes espoirs…

Ce que je veux dire c’est qu’au lieu de se torturer avec du JS dans tous
les
sens, (bonjour la torture à débuguer) pour essayer de mal copier les
applications natives, il existe des solutions plus crédible comme Java,
Ruby/Qt avec XML-RPC, ou XUL.
Les protocoles XML-RPC et SOAP permettent dès maintenant cette fusion du
desktop et du web, il faut juste arrêter de s’extasier sur AJAX et
l’utiliser à sa juste valeur.

Salut,

J’arrive un peu sur le tard dans la discusion mais je tenais à
conseiller moo.fx (3ko, nécessite prototype ou un morceau de
MooTools) et MooTools (max. 10ko, en compressé) ; légers, compatibles
prototype ; et agréables à utiliser :
moo.fx : http://moofx.mad4milk.net/
MooTools : http://mootools.net

à+np_______________________________________________
Railsfrance mailing list
[email protected]
http://lists.rubyonrails.fr/mailman/listinfo/railsfrance

pour essayer de mal copier les applications natives

bien vu. faut trouver une ergonomie adaptée au support. la tendance
actuelle à l’appli web “simple et qui marche” est là
pour conforter cette optique.

GMail n’a pas cherché à refaire un nième Outoolk !

Et sans meme aller chercher GMail, les webmails sont très utilisables
(Squirellmail par exemple), avec un niveau de HTML
qui doit etre proche du 1.0 !

gUI


Pour la santé de votre ordinateur, préférez les logiciels libres !

Guillaume B. : (05 61) 19 40 65 / bureau S723

XAML

L’intention de M$ de s’emparer du Web au travers de l’interface riche
rendue
possible par XAML m’a toujours été limpide.

Vu les forces mises en jeux le risque n’est pas nul de passer
directement au
Web 3.0 moyennant redevance.

(d’autant que .NET 3.0 ça commence aussi à être vachement agile !)

Va falloir se battre sur l’utilité de ce qu’on met en ligne et,
heureusement, le grand public n’a que faire du desktop qui est trop
compliqué par rapport à ses besoins.

Donc Ajax, avec sobriété oui, mais c’est pas la fin de l’histoire.

2006/11/16, philippe lachaise

Va falloir se battre sur l’utilité de ce qu’on met en ligne et,
heureusement, le grand public n’a que faire du desktop qui est trop
compliqué par rapport à ses besoins.

J’ai un Grooooos doute là dessus … avant qu’une suite bureautique en
web
remplace une suite bureautique native c’est pas pour tout de suite, Ã
part
dans les fantasmes de certains :slight_smile: De plus avec l’explosion des ordi
portable
je doute que le grand public apprécie de ne plus pouvoir utiliser ses
applications sans le net …
Le wifi ouvert partout ? fantasme numéro2.
On en reparle dans 10 ans, en attendant le desktop natif a de beaux
jours
devant lui mais avec des services web (exemple Flickr avec
http://juploadr.sourceforge.net/).

GMail n’a pas cherché à refaire un nième Outoolk !

Ce qu’on tenté Yahoo et Zimbra, pour aboutir à des trucs bien trop
lourds.

le grand public n’a que faire du desktop

J’ai un Grooooos doute là dessus … avant qu’une suite bureautique en
web remplace une suite bureautique native c’est pas pour tout de suite

Le grand public, pas celui qui peuple les bureaux. Les gens qui vont
peut-être se servir du Web si jamais ça leur permet de se simplifier la
vie.

Ceux pour qui Word et Windows sont une seule et même chôse et qui
dorment
bien quand même :wink:

avant qu’une suite bureautique en web remplace une suite bureautique native
c’est pas pour tout de suite

non c’est pas pour tout de suite.

mais je pense qu’il ne faut pas se méprendre sur le moment ou ca arrivera.
ca n’arrivera pas le jour où l’on pourra
faire autant de truc sur une appli web que sur une appli native, ca
arrivera le jour ou les gens se rendront compte
qu’ils n’ont pas besoin d’une suite bureautique.

je vois au boulot 99% des utilisations de Excel sont complètement à côté de la
plaque :

  • soit parce que ca permet de faire des présentation dans des boi-boites
    (exactement ce que je fais à l’heure ou j’écris
    : procédures de validation système, décrites dans un fichier excel)
  • soit parce que c’est plus facile qu’une base de données (ce qui est faux
    evidemment : si on a besoin d’une BdD, on
    utilise une BdD, c’est tout).
  • soit parce qu’on peut faire des macros (là ou un script shell ferait
    exactement le meme boulot).

je ne parle donc meme pas de Word pour faire une simple lettre…

gUI


Pour la santé de votre ordinateur, préférez les logiciels libres !

Guillaume B. : (05 61) 19 40 65 / bureau S723

Je ne peux qu’être d’accord avec Frédéric.

Certes, concevoir des applications Web me paraît plus simple qu’une
application “desktop” (ne serait-ce parce qu’actuellement je fais du
Ruby on Rails et plus de Delphi), mais au niveau richesse et
utilisabilité, cette dernière s’en sortira toujours mieux.

Alors oui, aujourd’hui, on vit une étape de transition, avec un regain
d’intérêt pour les applications Web grâce à AJAX, à Ruby on Rails, au
buzz Web 2.0, XUL qui commence à intéresser du monde.
Mais ça ne peut être une finalité en soi.
Déjà parce que les différences entre les navigateurs obligent à écrire
plus de hacks CSS que de code réellement pertinent, que la gestion du
position en fonction de la taille de l’écran est problématique, et que
l’utilisation de polices fait se poser la question du système
d’exploitation (au secours, dans quel ordre je mets mes noms de
police, pour avoir un rendu à peu près identique sur tous les OS ?).

Ce qui me tarde le plus de voir apparaître, ce sont d’autres langages
pour venir épauler Javascript (oups, pardon, ECMAScript) dans les
navigateurs… mais leur diffusion sera encore plus lente que celle
des standards :-\

De l’autre côté, l’application desktop pourra toujours être
“facilement” plus riche et attractive (par exemple, le menu carroussel
de Windows Vista, disponible d’un clic dans WinDEV 11). Elle sera
également plus rapide, “survivra” à une coupure de l’accès à Internet,
ne sera pas impactée par telle ou telle mise à jour de Flash ou autre
plugin sur la machine, bref, elle sera cohérente et (si j’ose dire)
WYSIWYG, dans le sens où l’application développée par le programmeur
est celle qui est utilisée.

A mon avis, les applications Web trouvent leur intérêt dans les cas
suivants (liste non exhaustive bien entendu) :

-> démonstration technologique (“hey, that’s kinda cool…”)
-> plateforme finale maîtrisée (ce qui est paradoxal pour du Web,
convenons-en), avec l’utilisation de XUL par exemple
-> diffusion très large nécessitant une mise à jour rapide (tests et
ajout de fonctionnalités, retour à la version précédente)
-> alternative aux clients légers : des postes démarrent et
n’exécutent qu’un navigateur en plein écran, affichant la page du
serveur d’applications, sur le réseau local ou distant, peu importe
-> l’envie d’essayer ?

Mais bon, inutile d’ergoter sur le sujet, chacun a ses positions. Vous
connaissez la mienne maintenant :slight_smile:
(hum, je crois que je me suis écarté du sujet de base, à savoir
l’intégration de DojoToolKit dans Rails)

hum, je crois que je me suis écarté du sujet de base, à savoir
l’intégration de DojoToolKit dans Rails

Comme nous tous dans cette discussion d’ailleurs :wink:

Ca laisse présager des discussions intéressantes demain, après Paris
on Rails, pour ceux qui resteront sur place pour un after :wink:

Le Jeu 16 novembre 2006 15:06, philippe lachaise a écrit :

Va falloir se battre sur l’utilité de ce qu’on met en ligne et,
heureusement, le grand public n’a que faire du desktop qui est trop
compliqué par rapport à ses besoins.

Moi j’aurai dit exactement le contraire.
Passé la bulle, il va falloir demander à quoi sert de tout faire passer
par le Web. Faut pas oublier que le but de l’informatique c’est de
servir
d’outil.

De quoi a t’on besoin ?

  • d’un stockage, qui soit distant pour partager les données et les gérer
    par profil itinérant, mais qui puisse aussi être local pour un mode
    déconnecté ou les données privées
  • de services, qui doivent pouvoir être locaux quand il y a beaucoup de
    données à traiter ou beaucoup de calcul, et qui doivent pouvoir être
    distant quand il s’agit de manipuler des données partagées ou d’accéder à
    des abonnements de services
  • d’une interface, qui doit pouvoir être réactive et utilisable même
    déconnecté.

Désolé mais les applications distantes en ajax (ou équivalent) ne
répondent pas du tout aux besoins. Elles imposent une connexion toujours
active, un serveur de calcul énorme, une réactivité pourrie et un stockage
distant.

Vous croyez vraiment que j’ai besoin de me connecter au Web pour
utiliser
un traitement de texte ? que c’est une connexion à Miami qui m’assurera le
meilleur confort d’utilisation pour taper la lettre à mon agence de
location ? Qu’est ce que ça m’apporte ?
A la limite je peux vouloir stocker ça sur un dépot itinérant (webdav) ou
utiliser des services distants pour rappatrier des modèles de lettre
depuis le net (services web, quelle que soit la techno derrière). Par
contre l’appli elle même elle n’a que des désavantages à être distante.

Tout au plus, outre le stockage distant et les services annexes par WS,
on
peut imaginer de télécharger une appli locale régulièrement pour avoir des
mises à jour où pouvoir y accéder depuis un nouveau poste.
Mais bon, dans ces cas là, un FTP mixé avec une mise à jour auto de type
firefox ça correspond tout à fait. A la limite on peut partir sur un
système proche de java webstart.
Par contre l’appli elle, elle reste locale.

Et vous voulez savoir quoi ? bon gré mal gré, pour des contraintes de
réactivité et de charge serveur et de performances, on se dirige vers
cette solution de l’appli locale téléchargée à la demande. Le seul truc
c’est que l’appli locale en question pour l’instant c’est du mégaoctet de
javascript associé à un toolkit HTML.
Est-ce que réellement on n’a pas mieux que du javascript et du HTML pour
développer de l’applicatif ? vous ne me ferez pas dire que “oui” est la
réponse.
Est-ce que vraiment il faut que notre appli fasse un appel serveur pour
tout et n’importe quoi et du coup impose la connexion à tout instant pour
les actions simples ? là aussi je doute que la réponse soit “oui”.

Les applis Web c’est une bonne idée. Vouloir tout passer par le Web c’est
contre-productif et c’est une jolie mode qui va vite retomber avec les
premier retours d’expérience.

Tiens, quand j’y pense, la dernière fois qu’on parlait de tout faire
passer par le Web, avec des net computer qui n’ont qu’un navigateur …
c’était lors de la dernière bulle Internet, dans les années 2000. Chacun
en tirera les conclusions qu’il veut.
Quand je pense que, encore quelques années de plus en arrière, on était
content de mettre fin au tout centralisé et aux terminaux X en amenant le
PC (personnal computer) … je sais que l’informatique fonctionne par
cycles, mais là on tourne en rond.


Eric D.

que c’est une connexion à Miami qui m’assurera le
meilleur confort d’utilisation pour taper la lettre à mon agence de
location ?

ca c’est la version actuelle. par exemple, on peut imaginer qu’un jour
ton abonnement Internet comprendra la petite
suite bureautique qui va bien.

l’interet pour l’utilisateur final ? gratuit, simple, utilisé par tout le
monde… bref aucun argument technique.

gUI


Pour la santé de votre ordinateur, préférez les logiciels libres !

Guillaume B. : (05 61) 19 40 65 / bureau S723

Le Jeu 16 novembre 2006 15:32, Guillaume B. a écrit :

mais je pense qu’il ne faut pas se méprendre sur le moment ou ca
arrivera. ca n’arrivera pas le jour où l’on pourra
faire autant de truc sur une appli web que sur une appli native, ca
arrivera le jour ou les gens se rendront compte qu’ils n’ont pas besoin
d’une suite bureautique.

Si je peux me permettre : quel rapport ?

Si ton problème est “mes logiciels sont trop gros et font le café au lieu
de faire des trucs simples”, en quoi est ce que tout faire passer par le
Web est une solution ?

Tu peux très bien faire des petites applis simples en local hein, pas
besoin de passer par le Web pour ça. De la même manière, on voit des trucs
horribles par le Web.

Tu as peut être un vrai problème, mais tu y appliques une solution qui non
seulement ne résoud pas le problème de départ, mais en plus y ajoutera ses
propres défauts.


Eric D.

2006/11/16, philippe lachaise [email protected]:

Perso j’utilise pas le mail pour classer mes documents :slight_smile: Mais j’ai
compris
l’exemple. Cependant rien ne vaut une application desktop pour accéder Ã
ses
documents distant. A tiens c’est exactement ce que propose Neuf (
http://www.neufgiga.com) et l’interface c’est du Java, tiens donc :slight_smile:

l’interet pour l’utilisateur final ? gratuit, simple, utilisé par tout le
monde… bref aucun argument technique.

Et surtout fini les “B… de M… où est ce que j’ai encore mis ce
document
!?”

J’ai remarqué, par exemple, que mon système de classement le plus
efficace
c’est gmail : je retouve toujours mes vieux mails avec un ou deux mots
clés, et de n’importe où.

Puisque le débat dérive complètement, je dirais que, comme bien souvent,
il
y a du bon dans les appli web et dans les locales, il y a du bon dans
les
terminaux et dans les pc. Le tout est de ce servir du bon outil pour
répondre au besoin bien exprimé :slight_smile:

De mon point de vu c’est tout l’intérêt de l’informatique aujourd’hui:
Trouvé la bonne réponse à un problème (comment ça c’tait déjà le cas y’a
10
ans ? :smiley: )

Le 16/11/06, Guillaume B.
[email protected]
a écrit :

Si ton problème est “mes logiciels sont trop gros et font le café au lieu
de faire des trucs simples”, en quoi est ce que tout faire passer par le
Web est une solution ?

ce n’est en rien une solution. mais une appli web a certains avantages
par rapport à la version desktop (la mobilité, la
mise à jour etc…). les inconvénients (principalement toutes les
limitations dûes au medium) s’estompent avec la
simplicité de l’application. BaseCamp (c’ets son bien nom???) fait cent
fois moins de chose que Microsoft Project. Mais
les gens qui prennent conscience que finalement il y a dans BaseCamp le
1% qu’ils utilisent de Microsoft Project
trouvent leur bonheur dans BaseCamp (et du coup peuvent profiter d’une
appli distribuée).

donc ce que je voulais dire, c’est qu’en cherchant la simplicité (et pas
les fonctionnalités dont finalement on ne se
sert jamais) on tendra a avoir des besoins compatibles avec les applis
web.

si à cela on ajoute les performances grandissantes des connexions (et il
faut le reconnaitre, des standards permettants
qques fantaisies), ca convergera peut-etre, en effet, vers des applis
web plus nombreuses qu’actuellement.

mais à mon sens, la diminution des besoins fait avancer les choses bien
plus vite que l’augmentation des débits (-:

gUI


Pour la santé de votre ordinateur, préférez les logiciels libres !

Guillaume B. : (05 61) 19 40 65 / bureau S723

Le 17/11/06, Guillaume B.
[email protected]
a écrit :

simplicité de l’application. BaseCamp (c’ets son bien nom???) fait cent
fois moins de chose que Microsoft Project. Mais
les gens qui prennent conscience que finalement il y a dans BaseCamp le 1%
qu’ils utilisent de Microsoft Project
trouvent leur bonheur dans BaseCamp (et du coup peuvent profiter d’une
appli distribuée).

Pour ma part je n’ai jamais dis qu’une appli web n’avait pas d’intérêt
bien
au contraire. Je dis qu’il n’y a pas d’intérêt à ce qu’une appli web
essaye
de mimer une appli desktop, ce qui n’est pas du tout le cas avec
Basecamp
par exemple.
Pour essayer de revenir au sujet du fil, Dojo est bien un toolkit JS qui
essaye de mimer une appli desktop … avec les problèmes que l’on a
cité.
J’estime que lorsque l’on a des besoins avancés en matière d’interface
graphique il faut oublier le web et revenir aux applications desktop.
Pour
me répéter,

  1. en utilisant XML-RPC par exemple, l’application desktop peut être une
    coquille vide et les traitements sont coté serveur via des webservices.
  2. On met plus souvent à jour le code de traitement que l’interface
    graphique donc le “problème” de la mise à jour est limité.
  3. En développant intelligemment son application desktop il est tout Ã
    fait
    possible que celle-ci se mette à jour automatiquement. C’est le cas des
    extensions Firefox, et l’arrivée prochaine de xul-runner va accentuer ce
    type d’application.
  4. Et en développant encore un peu plus intelligemment son application
    desktop, celle-ci peut tout à fait être utilisée en local, il suffit de
    stocker les données dans une base de donnée fichier de type sqlite, pour
    ensuite les synchroniser dès que l’utilisateur retrouve une connexion
    Internet → avantages du desktop ET du web.
  5. Des bibliothèque graphiques desktop comme Qt ou GTK+ sont évidement
    étudiées pour le desktop. HTML / CSS / JS non. Faites une IHM un peu
    complexe en Ruby/GTK+ / Glade et la même en AJAX et on en reparle.
  6. Après AJAX peut être que l’on redécouvrira que l’on peut faire des
    IHM
    évoluées via des applets JAVA. Le plugin JAVA est aussi simple Ã
    installer
    que le plugin Flash. Sachant que JAVA va passer en licence GPL …

A mon avis le web ne peut être qu’un complément au desktop, en aucun cas
un
remplacent. En tout cas amusez-vous bien avec Dojo :slight_smile:

“Mais le plus intéressant, à mon sens, c’est l’arrivée d’une base de données
dans Firefox , qui permet à des extensions voire à des applications Web de
continuer à fonctionner même quand on est déconnecté du réseau”

Intéressant sur le papier, les dérives possibles font un peu peur
quand même. (sécurité des données notamment)