Pasturel Jean-Louis wrote:Pierre Morel a écrit:
=================== >
Si une modification est requise dans le UI, n'importe qui peut la faire
sans l'intervention du programmeur, car la présentation est séparer de
la logique.
Ui original:
<jframe
<jmenu
<jtoolbar
<jpanel
<jlabel
<jtextfield
</jpanel>
<jframe>
UI modifié:
<jframe
<jmenu
<jpanel
<jlabel
<jtextfield
</jpanel>
<jtoolbar
<jframe>
Le toolbar est maintenant changer d'endroit, à la guise, de
l'utilisateur. Il n'a qu'à sauvegarder son fichier.
Exécuter à nouveau, et les changements sont immédiats.
Aucune compilation. Aucun packaging.
Les classes et/ou scripts continue à être aussi efficace qu'auparavant.
Avec ce modèle, tu n'as pas besoin de tout prévoir au moment de la
conception.
Si tu n'as pas mis de fonctionnalité pour le changement de Look&Feel
dans ton application, et bien l'utilisateur ajoute seulement un tag, et
voilà. Son programme est maintenant à ce look&feel
Ui original:
<jframe id="main-frame"
<jpanel
<jlabel
...
Ui modifié:
<jframe id="main-frame"
<plaf.manager plaf="SkinLF" theme="Whistler"
ref-component="main-frame"/>
<jpanel
<jlabel
...
Aucune compilation. Tu ne sait même pas qu'un de tes clients roule ton
application dans un look&feel de son choix.
================================ >
Je n'ai pas regardé la doc autour de ce produit, mais il appelle
quelques remarques.
Quelles sont les libertées laissées à l'utilisateur pour modifier son
interface par rapport au besoin applicatif ? => ne risque-t-il pas de
supprimer un objet de l'UI obligatoire du point de vue applicatif ? (
Champ saisie obligatoire par exemple)
Dans le cas d'un déploiement massif de ces UI, j'ai peur que le
soutien utilisateur à distance soit difficile ? ("oui tu vois le
widget en haut à droite" .. "Ah j'ai rien en haut à droite mais par
contre au centre "....)
D'accord, je me suis un peu emballé et projeté dans le futur. J'aurais
du dire "super user" au lieu d'utilisateur. Disons que c'est celui qui
s'occupe de l'informatique dans la compagnie qui fait ces modifs. Il
connait l'application et fait des modifications en conséquence.
Mais je persiste à dire qu'il doit bien y avoir un moyen de donner plus
de pouvoir à l'utilisateur. Comme l'industrie de l'automobile l'a fait.
Quand j'achète une automobile, du moment que j'en prends possession,
elle est à moi, je peux me planter dans le mur si je le désire. Je peux
aussi y apporter ou y faire apporter des modifications à ma guise. Je
peux changer de carburateur, mettre des pneus plus large, y ajouter un
toit ouvrant. Elle est à moi. Je peux ouvrir le capot aussi et
déconnecter des fils, enlever des morceaux importants, et mon auto ne
fonctionnera plus. Mais ils me font confiance et pense que je ne suis
pas idiot. Et ceci me donne la liberté de faire ce que je veux. Des
milliers de personne n'ouvre pas le capot, moi le premier, mais pour
ceux qui le veulent, c'est possible.
Nous en informatique, on a batit une industrie ou les utilisateurs sont
considérés comme des idiots, alors on mets des barrières partout pour
qu'ils n'aient pas la liberté de faire quoi que se soit. Et ainsi on
garde bien clos notre territoire et nos jobs.
Mais à chaque fois qu'il y a eu plus grande liberté pour les
utilisateurs, il y a eu explosion de créativité. Si le HTML aurait été
en binaire et que seulement les programmeurs auraient pu faire des pages
web, il n'y aurait pas le web qu'on connait aujourd'hui.
De même pour les langages script. PHP et les autres. Plein de gens qui
ne sont pas des informaticiens font des choses vraiment bien avec cela.
Pour en revenir à la question, oui il faut appréhender des problèmes
pour un support technique de la sorte, mais c'est à nous à mettre
l'infrastructure qu'il faut.
Pourquoi il n'y aurait pas un tag support dans l'application et que ce
tag permette de t'envoyer le fichier que ton client utilisateur a devant
lui. Et voilà, tu regarde la même chose que lui et tu peux l'aider dans
ce qu'il fait.
Nous avons une petite demo expérimental qui prends une application à
notre site et la charge sur l'ordinateur de l'utilisateur.
demo-remote.bat
=================== > call r-run.bat -File
http://www.ultrid.com/xpml/com-ultrid-remote/Temperature.xpml %*
==================== >
alors l'inverse pourrait être vrai. Le fichier xpml voyage de
l'utilisateur à toi.
merci pour ta question, cela provoque ma réflexion. Je n'ai pas toutes
les réponses, loin de là.
Pierre Morel
www.ultrid.com
Une utilisation possible de votre outil serait de faire des filtres par
Pasturel Jean-Louis wrote:
Pierre Morel a écrit:
=================== >
Si une modification est requise dans le UI, n'importe qui peut la faire
sans l'intervention du programmeur, car la présentation est séparer de
la logique.
Ui original:
<jframe
<jmenu
<jtoolbar
<jpanel
<jlabel
<jtextfield
</jpanel>
<jframe>
UI modifié:
<jframe
<jmenu
<jpanel
<jlabel
<jtextfield
</jpanel>
<jtoolbar
<jframe>
Le toolbar est maintenant changer d'endroit, à la guise, de
l'utilisateur. Il n'a qu'à sauvegarder son fichier.
Exécuter à nouveau, et les changements sont immédiats.
Aucune compilation. Aucun packaging.
Les classes et/ou scripts continue à être aussi efficace qu'auparavant.
Avec ce modèle, tu n'as pas besoin de tout prévoir au moment de la
conception.
Si tu n'as pas mis de fonctionnalité pour le changement de Look&Feel
dans ton application, et bien l'utilisateur ajoute seulement un tag, et
voilà. Son programme est maintenant à ce look&feel
Ui original:
<jframe id="main-frame"
<jpanel
<jlabel
...
Ui modifié:
<jframe id="main-frame"
<plaf.manager plaf="SkinLF" theme="Whistler"
ref-component="main-frame"/>
<jpanel
<jlabel
...
Aucune compilation. Tu ne sait même pas qu'un de tes clients roule ton
application dans un look&feel de son choix.
================================ >
Je n'ai pas regardé la doc autour de ce produit, mais il appelle
quelques remarques.
Quelles sont les libertées laissées à l'utilisateur pour modifier son
interface par rapport au besoin applicatif ? => ne risque-t-il pas de
supprimer un objet de l'UI obligatoire du point de vue applicatif ? (
Champ saisie obligatoire par exemple)
Dans le cas d'un déploiement massif de ces UI, j'ai peur que le
soutien utilisateur à distance soit difficile ? ("oui tu vois le
widget en haut à droite" .. "Ah j'ai rien en haut à droite mais par
contre au centre "....)
D'accord, je me suis un peu emballé et projeté dans le futur. J'aurais
du dire "super user" au lieu d'utilisateur. Disons que c'est celui qui
s'occupe de l'informatique dans la compagnie qui fait ces modifs. Il
connait l'application et fait des modifications en conséquence.
Mais je persiste à dire qu'il doit bien y avoir un moyen de donner plus
de pouvoir à l'utilisateur. Comme l'industrie de l'automobile l'a fait.
Quand j'achète une automobile, du moment que j'en prends possession,
elle est à moi, je peux me planter dans le mur si je le désire. Je peux
aussi y apporter ou y faire apporter des modifications à ma guise. Je
peux changer de carburateur, mettre des pneus plus large, y ajouter un
toit ouvrant. Elle est à moi. Je peux ouvrir le capot aussi et
déconnecter des fils, enlever des morceaux importants, et mon auto ne
fonctionnera plus. Mais ils me font confiance et pense que je ne suis
pas idiot. Et ceci me donne la liberté de faire ce que je veux. Des
milliers de personne n'ouvre pas le capot, moi le premier, mais pour
ceux qui le veulent, c'est possible.
Nous en informatique, on a batit une industrie ou les utilisateurs sont
considérés comme des idiots, alors on mets des barrières partout pour
qu'ils n'aient pas la liberté de faire quoi que se soit. Et ainsi on
garde bien clos notre territoire et nos jobs.
Mais à chaque fois qu'il y a eu plus grande liberté pour les
utilisateurs, il y a eu explosion de créativité. Si le HTML aurait été
en binaire et que seulement les programmeurs auraient pu faire des pages
web, il n'y aurait pas le web qu'on connait aujourd'hui.
De même pour les langages script. PHP et les autres. Plein de gens qui
ne sont pas des informaticiens font des choses vraiment bien avec cela.
Pour en revenir à la question, oui il faut appréhender des problèmes
pour un support technique de la sorte, mais c'est à nous à mettre
l'infrastructure qu'il faut.
Pourquoi il n'y aurait pas un tag support dans l'application et que ce
tag permette de t'envoyer le fichier que ton client utilisateur a devant
lui. Et voilà, tu regarde la même chose que lui et tu peux l'aider dans
ce qu'il fait.
Nous avons une petite demo expérimental qui prends une application à
notre site et la charge sur l'ordinateur de l'utilisateur.
demo-remote.bat
=================== > call r-run.bat -File
http://www.ultrid.com/xpml/com-ultrid-remote/Temperature.xpml %*
==================== >
alors l'inverse pourrait être vrai. Le fichier xpml voyage de
l'utilisateur à toi.
merci pour ta question, cela provoque ma réflexion. Je n'ai pas toutes
les réponses, loin de là.
Pierre Morel
www.ultrid.com
Une utilisation possible de votre outil serait de faire des filtres par
Pasturel Jean-Louis wrote:Pierre Morel a écrit:
=================== >
Si une modification est requise dans le UI, n'importe qui peut la faire
sans l'intervention du programmeur, car la présentation est séparer de
la logique.
Ui original:
<jframe
<jmenu
<jtoolbar
<jpanel
<jlabel
<jtextfield
</jpanel>
<jframe>
UI modifié:
<jframe
<jmenu
<jpanel
<jlabel
<jtextfield
</jpanel>
<jtoolbar
<jframe>
Le toolbar est maintenant changer d'endroit, à la guise, de
l'utilisateur. Il n'a qu'à sauvegarder son fichier.
Exécuter à nouveau, et les changements sont immédiats.
Aucune compilation. Aucun packaging.
Les classes et/ou scripts continue à être aussi efficace qu'auparavant.
Avec ce modèle, tu n'as pas besoin de tout prévoir au moment de la
conception.
Si tu n'as pas mis de fonctionnalité pour le changement de Look&Feel
dans ton application, et bien l'utilisateur ajoute seulement un tag, et
voilà. Son programme est maintenant à ce look&feel
Ui original:
<jframe id="main-frame"
<jpanel
<jlabel
...
Ui modifié:
<jframe id="main-frame"
<plaf.manager plaf="SkinLF" theme="Whistler"
ref-component="main-frame"/>
<jpanel
<jlabel
...
Aucune compilation. Tu ne sait même pas qu'un de tes clients roule ton
application dans un look&feel de son choix.
================================ >
Je n'ai pas regardé la doc autour de ce produit, mais il appelle
quelques remarques.
Quelles sont les libertées laissées à l'utilisateur pour modifier son
interface par rapport au besoin applicatif ? => ne risque-t-il pas de
supprimer un objet de l'UI obligatoire du point de vue applicatif ? (
Champ saisie obligatoire par exemple)
Dans le cas d'un déploiement massif de ces UI, j'ai peur que le
soutien utilisateur à distance soit difficile ? ("oui tu vois le
widget en haut à droite" .. "Ah j'ai rien en haut à droite mais par
contre au centre "....)
D'accord, je me suis un peu emballé et projeté dans le futur. J'aurais
du dire "super user" au lieu d'utilisateur. Disons que c'est celui qui
s'occupe de l'informatique dans la compagnie qui fait ces modifs. Il
connait l'application et fait des modifications en conséquence.
Mais je persiste à dire qu'il doit bien y avoir un moyen de donner plus
de pouvoir à l'utilisateur. Comme l'industrie de l'automobile l'a fait.
Quand j'achète une automobile, du moment que j'en prends possession,
elle est à moi, je peux me planter dans le mur si je le désire. Je peux
aussi y apporter ou y faire apporter des modifications à ma guise. Je
peux changer de carburateur, mettre des pneus plus large, y ajouter un
toit ouvrant. Elle est à moi. Je peux ouvrir le capot aussi et
déconnecter des fils, enlever des morceaux importants, et mon auto ne
fonctionnera plus. Mais ils me font confiance et pense que je ne suis
pas idiot. Et ceci me donne la liberté de faire ce que je veux. Des
milliers de personne n'ouvre pas le capot, moi le premier, mais pour
ceux qui le veulent, c'est possible.
Nous en informatique, on a batit une industrie ou les utilisateurs sont
considérés comme des idiots, alors on mets des barrières partout pour
qu'ils n'aient pas la liberté de faire quoi que se soit. Et ainsi on
garde bien clos notre territoire et nos jobs.
Mais à chaque fois qu'il y a eu plus grande liberté pour les
utilisateurs, il y a eu explosion de créativité. Si le HTML aurait été
en binaire et que seulement les programmeurs auraient pu faire des pages
web, il n'y aurait pas le web qu'on connait aujourd'hui.
De même pour les langages script. PHP et les autres. Plein de gens qui
ne sont pas des informaticiens font des choses vraiment bien avec cela.
Pour en revenir à la question, oui il faut appréhender des problèmes
pour un support technique de la sorte, mais c'est à nous à mettre
l'infrastructure qu'il faut.
Pourquoi il n'y aurait pas un tag support dans l'application et que ce
tag permette de t'envoyer le fichier que ton client utilisateur a devant
lui. Et voilà, tu regarde la même chose que lui et tu peux l'aider dans
ce qu'il fait.
Nous avons une petite demo expérimental qui prends une application à
notre site et la charge sur l'ordinateur de l'utilisateur.
demo-remote.bat
=================== > call r-run.bat -File
http://www.ultrid.com/xpml/com-ultrid-remote/Temperature.xpml %*
==================== >
alors l'inverse pourrait être vrai. Le fichier xpml voyage de
l'utilisateur à toi.
merci pour ta question, cela provoque ma réflexion. Je n'ai pas toutes
les réponses, loin de là.
Pierre Morel
www.ultrid.com
Une utilisation possible de votre outil serait de faire des filtres par
Une utilisation possible de votre outil serait de faire des filtres par
type d'utilisateur afin de cibler l'UI en fonction d'un profil. on cache
les écrans ( et donc les fonctionalités associées) en fonction des
profils de l'utilisateur. On pourrait ainsi disposer d'un source UI
unique customisable par votre produit.
A creuser de ce coté là.
Mais je persiste à dire qu'en terme d'application industrielle, on ne
doit laisser que très peu de liberté à l'utilisateur final ( On peut
laisser le choix de la couleur éventuellement). Pour la bureautique, il
fait ce qu'il veut, il ne met en péril que son poste.
Une utilisation possible de votre outil serait de faire des filtres par
type d'utilisateur afin de cibler l'UI en fonction d'un profil. on cache
les écrans ( et donc les fonctionalités associées) en fonction des
profils de l'utilisateur. On pourrait ainsi disposer d'un source UI
unique customisable par votre produit.
A creuser de ce coté là.
Mais je persiste à dire qu'en terme d'application industrielle, on ne
doit laisser que très peu de liberté à l'utilisateur final ( On peut
laisser le choix de la couleur éventuellement). Pour la bureautique, il
fait ce qu'il veut, il ne met en péril que son poste.
Une utilisation possible de votre outil serait de faire des filtres par
type d'utilisateur afin de cibler l'UI en fonction d'un profil. on cache
les écrans ( et donc les fonctionalités associées) en fonction des
profils de l'utilisateur. On pourrait ainsi disposer d'un source UI
unique customisable par votre produit.
A creuser de ce coté là.
Mais je persiste à dire qu'en terme d'application industrielle, on ne
doit laisser que très peu de liberté à l'utilisateur final ( On peut
laisser le choix de la couleur éventuellement). Pour la bureautique, il
fait ce qu'il veut, il ne met en péril que son poste.
J'ai posté un Réponse dans notre forum.
http://www.ultrid.com/index.php?name=PNphpBB2&file=viewtopic&p=8#8
J'ai posté un Réponse dans notre forum.
http://www.ultrid.com/index.php?name=PNphpBB2&file=viewtopic&p=8#8
J'ai posté un Réponse dans notre forum.
http://www.ultrid.com/index.php?name=PNphpBB2&file=viewtopic&p=8#8
Si quelqu'un est capable de faire rouler notre software en Mac et/ou
Linux, svp, faites nous parvenir ces scripts. Nous les metterons dans le
download et il sera beacoup plus facile aux prochains utilisateurs
d'essayer les programmes.
Je n'ai pas de Mac ni Linux (Shame on me).
Si quelqu'un est capable de faire rouler notre software en Mac et/ou
Linux, svp, faites nous parvenir ces scripts. Nous les metterons dans le
download et il sera beacoup plus facile aux prochains utilisateurs
d'essayer les programmes.
Je n'ai pas de Mac ni Linux (Shame on me).
Si quelqu'un est capable de faire rouler notre software en Mac et/ou
Linux, svp, faites nous parvenir ces scripts. Nous les metterons dans le
download et il sera beacoup plus facile aux prochains utilisateurs
d'essayer les programmes.
Je n'ai pas de Mac ni Linux (Shame on me).
un p'tit sript ruby (run.rb) pour lancer (depuis ultrid/) un fichier
*.xpml :
--------------------------------------------------------------------
#!/usr/bin/ruby
ultridDir = Dir.pwd
libDir = ultridDir + "/lib"
ultridClasses = "."
jarFiles = Dir[libDir + "/*.jar"]
jarFiles.each { |jarFile| ultridClasses += ":" + jarFile}
zipFiles = Dir[libDir + "/*.zip"]
zipFiles.each { |zipFile| ultridClasses += ":" + zipFile}
print "n"
print "Enter file's name to launch (without .xpml ext.) : "
file = gets.chomp() + ".xpml"
system("java -classpath " + ultridClasses + " -Xmx200m
com.ultrid.se.Runner " + file)
--------------------------------------------------------------------
Pour ne pas à avoir à éditer les fichiers xpml,
ultridDir = Dir.pwd
libDir = ultridDir + "/lib"
ultridClasses = "."
mettre:
print "n"
print "Select one of the demo : "
file = (ici le code en ruby qui me donne un des elements de la liste)
un p'tit sript ruby (run.rb) pour lancer (depuis ultrid/) un fichier
*.xpml :
--------------------------------------------------------------------
#!/usr/bin/ruby
ultridDir = Dir.pwd
libDir = ultridDir + "/lib"
ultridClasses = "."
jarFiles = Dir[libDir + "/*.jar"]
jarFiles.each { |jarFile| ultridClasses += ":" + jarFile}
zipFiles = Dir[libDir + "/*.zip"]
zipFiles.each { |zipFile| ultridClasses += ":" + zipFile}
print "n"
print "Enter file's name to launch (without .xpml ext.) : "
file = gets.chomp() + ".xpml"
system("java -classpath " + ultridClasses + " -Xmx200m
com.ultrid.se.Runner " + file)
--------------------------------------------------------------------
Pour ne pas à avoir à éditer les fichiers xpml,
ultridDir = Dir.pwd
libDir = ultridDir + "/lib"
ultridClasses = "."
mettre:
print "n"
print "Select one of the demo : "
file = (ici le code en ruby qui me donne un des elements de la liste)
un p'tit sript ruby (run.rb) pour lancer (depuis ultrid/) un fichier
*.xpml :
--------------------------------------------------------------------
#!/usr/bin/ruby
ultridDir = Dir.pwd
libDir = ultridDir + "/lib"
ultridClasses = "."
jarFiles = Dir[libDir + "/*.jar"]
jarFiles.each { |jarFile| ultridClasses += ":" + jarFile}
zipFiles = Dir[libDir + "/*.zip"]
zipFiles.each { |zipFile| ultridClasses += ":" + zipFile}
print "n"
print "Enter file's name to launch (without .xpml ext.) : "
file = gets.chomp() + ".xpml"
system("java -classpath " + ultridClasses + " -Xmx200m
com.ultrid.se.Runner " + file)
--------------------------------------------------------------------
Pour ne pas à avoir à éditer les fichiers xpml,
ultridDir = Dir.pwd
libDir = ultridDir + "/lib"
ultridClasses = "."
mettre:
print "n"
print "Select one of the demo : "
file = (ici le code en ruby qui me donne un des elements de la liste)
Pour ne pas à avoir à éditer les fichiers xpml,
Juste à la suite de:ultridDir = Dir.pwd
libDir = ultridDir + "/lib"
ultridClasses = "."
mettre:
modulesDir = ultridDir + "/module"
ultridClasses += ":" + modulesDir
Pour rouler le petit exemple de 'Zero Deployment' qui prends une
application directement d'un domaine et l'execute localement, tu as
besoin d'avoir le directory '/cache' qui soit devant modulesDir
Ce directory n'existe pas à l'installation, c'est seulement lorsque la
demo remote est roulé qu'il est alors créé.
Donc si un seul fichier utiliser pour runner les demos,
mettre:
cacheDir = ultridDir + "/cache"
ultridClasses += ":" + cacheDir
modulesDir = ultridDir + "/module"
ultridClasses += ":" + modulesDir
l'utilisateur. Si oui, on pourrait avoir un fichier 'demos.rb' qui a les
même classpath settings que 'run.rb', et une liste de choix pour
faciliter l'expérimentation des demos.print "n"
print "Select one of the demo : "
file = (ici le code en ruby qui me donne un des elements de la liste)
Test --> test.xpml
Temperature Converter --> /com-ultrid-demos/Temperature/Temperature.xpml
Calculator --> /com-ultrid-demos/Calculator/Calculator.xpml
Text Editor --> /com-ultrid-demos/Editor/Editor.xpml
Dictionary Editor --> /com-ultrid-addons/DictionaryEditor/Dictionary.xpml
Language Editor --> /com-ultrid-addons/LanguageEditor/Language.xpml
Remote (Zero Deployment) -->
http://www.ultrid.com/xpml/com-ultrid-remote/Temperature.xpml
SwingSet2 --> /com-ultrid-demos/SwingSet2/SwingSet2.xpml
Il ne restera alors qu'à trouver une facon de faire fonctionner le
SwingSet2 Demo qui est un clone du SwingSet2 de Sun, mais écrit en
langage Ultrid.
En Windows, j'ai
set CLASSPATH=%JAVA_HOME%demojfcSwingSet2SwingSet2.jar
Ce jar doit être dans le classpath pour que la SwingSet2 demo roule.
On se retrouverait avec seulement 2 fichiers, soit
run.rb pour les applications que tu développe
demos.rb pour avoir une apercu de ce qui peut être fait en Ultrid.
Pour ne pas à avoir à éditer les fichiers xpml,
Juste à la suite de:
ultridDir = Dir.pwd
libDir = ultridDir + "/lib"
ultridClasses = "."
mettre:
modulesDir = ultridDir + "/module"
ultridClasses += ":" + modulesDir
Pour rouler le petit exemple de 'Zero Deployment' qui prends une
application directement d'un domaine et l'execute localement, tu as
besoin d'avoir le directory '/cache' qui soit devant modulesDir
Ce directory n'existe pas à l'installation, c'est seulement lorsque la
demo remote est roulé qu'il est alors créé.
Donc si un seul fichier utiliser pour runner les demos,
mettre:
cacheDir = ultridDir + "/cache"
ultridClasses += ":" + cacheDir
modulesDir = ultridDir + "/module"
ultridClasses += ":" + modulesDir
l'utilisateur. Si oui, on pourrait avoir un fichier 'demos.rb' qui a les
même classpath settings que 'run.rb', et une liste de choix pour
faciliter l'expérimentation des demos.
print "n"
print "Select one of the demo : "
file = (ici le code en ruby qui me donne un des elements de la liste)
Test --> test.xpml
Temperature Converter --> /com-ultrid-demos/Temperature/Temperature.xpml
Calculator --> /com-ultrid-demos/Calculator/Calculator.xpml
Text Editor --> /com-ultrid-demos/Editor/Editor.xpml
Dictionary Editor --> /com-ultrid-addons/DictionaryEditor/Dictionary.xpml
Language Editor --> /com-ultrid-addons/LanguageEditor/Language.xpml
Remote (Zero Deployment) -->
http://www.ultrid.com/xpml/com-ultrid-remote/Temperature.xpml
SwingSet2 --> /com-ultrid-demos/SwingSet2/SwingSet2.xpml
Il ne restera alors qu'à trouver une facon de faire fonctionner le
SwingSet2 Demo qui est un clone du SwingSet2 de Sun, mais écrit en
langage Ultrid.
En Windows, j'ai
set CLASSPATH=%JAVA_HOME%demojfcSwingSet2SwingSet2.jar
Ce jar doit être dans le classpath pour que la SwingSet2 demo roule.
On se retrouverait avec seulement 2 fichiers, soit
run.rb pour les applications que tu développe
demos.rb pour avoir une apercu de ce qui peut être fait en Ultrid.
Pour ne pas à avoir à éditer les fichiers xpml,
Juste à la suite de:ultridDir = Dir.pwd
libDir = ultridDir + "/lib"
ultridClasses = "."
mettre:
modulesDir = ultridDir + "/module"
ultridClasses += ":" + modulesDir
Pour rouler le petit exemple de 'Zero Deployment' qui prends une
application directement d'un domaine et l'execute localement, tu as
besoin d'avoir le directory '/cache' qui soit devant modulesDir
Ce directory n'existe pas à l'installation, c'est seulement lorsque la
demo remote est roulé qu'il est alors créé.
Donc si un seul fichier utiliser pour runner les demos,
mettre:
cacheDir = ultridDir + "/cache"
ultridClasses += ":" + cacheDir
modulesDir = ultridDir + "/module"
ultridClasses += ":" + modulesDir
l'utilisateur. Si oui, on pourrait avoir un fichier 'demos.rb' qui a les
même classpath settings que 'run.rb', et une liste de choix pour
faciliter l'expérimentation des demos.print "n"
print "Select one of the demo : "
file = (ici le code en ruby qui me donne un des elements de la liste)
Test --> test.xpml
Temperature Converter --> /com-ultrid-demos/Temperature/Temperature.xpml
Calculator --> /com-ultrid-demos/Calculator/Calculator.xpml
Text Editor --> /com-ultrid-demos/Editor/Editor.xpml
Dictionary Editor --> /com-ultrid-addons/DictionaryEditor/Dictionary.xpml
Language Editor --> /com-ultrid-addons/LanguageEditor/Language.xpml
Remote (Zero Deployment) -->
http://www.ultrid.com/xpml/com-ultrid-remote/Temperature.xpml
SwingSet2 --> /com-ultrid-demos/SwingSet2/SwingSet2.xpml
Il ne restera alors qu'à trouver une facon de faire fonctionner le
SwingSet2 Demo qui est un clone du SwingSet2 de Sun, mais écrit en
langage Ultrid.
En Windows, j'ai
set CLASSPATH=%JAVA_HOME%demojfcSwingSet2SwingSet2.jar
Ce jar doit être dans le classpath pour que la SwingSet2 demo roule.
On se retrouverait avec seulement 2 fichiers, soit
run.rb pour les applications que tu développe
demos.rb pour avoir une apercu de ce qui peut être fait en Ultrid.
Marc Collin wrote:Pierre Morel wrote:Quel solution libre te permet de créer une application en définissant
ton interface utilisateur aussi facilement...
Pierre Morel
le plus connu étant eclipse avec le plugin adéquat
Je crois bien qu'on ne parle pas de la même chose.
Le plugin eclipse va t'aider à produire ton interface et générer le code
Java pour toi. C'est super et je ne nie pas cette fonctionnalité quand
on se met dans la perspective du programmeur seulement.
Mais quand tes classes seront compiler et que tes jars seront fait,
l'utilisateur lui ne pourra rien y changer.
Ce que je te parle, c'est de séparer l'interface utilisateur du code,
c'est à dire de la vrai logique de l'application.
Avec une description de l'interface en XML,
1) Ca ne requiert pas que ce soit un programmeur qui fasse cette partie,
2) Le programmeur fait la logique requise pour que l'application
fonctionne.
Quand tu livres ton produit, tu as:
1) Une description du UI en XML
2) Tes classes ou fichier scripts.
Si une modification est requise dans le UI, n'importe qui peut la faire
sans l'intervention du programmeur, car la présentation est séparer de
la logique.
Ui original:
<jframe
<jmenu
<jtoolbar
<jpanel
<jlabel
<jtextfield
</jpanel>
<jframe>
UI modifié:
<jframe
<jmenu
<jpanel
<jlabel
<jtextfield
</jpanel>
<jtoolbar
<jframe>
Le toolbar est maintenant changer d'endroit, à la guise, de
l'utilisateur. Il n'a qu'à sauvegarder son fichier.
Exécuter à nouveau, et les changements sont immédiats.
Aucune compilation. Aucun packaging.
Les classes et/ou scripts continue à être aussi efficace qu'auparavant.
Avec ce modèle, tu n'as pas besoin de tout prévoir au moment de la
conception.
Si tu n'as pas mis de fonctionnalité pour le changement de Look&Feel
dans ton application, et bien l'utilisateur ajoute seulement un tag, et
voilà. Son programme est maintenant à ce look&feel
Ui original:
<jframe id="main-frame"
<jpanel
<jlabel
...
Ui modifié:
<jframe id="main-frame"
<plaf.manager plaf="SkinLF" theme="Whistler" ref-component="main-frame"/>
<jpanel
<jlabel
...
Aucune compilation. Tu ne sait même pas qu'un de tes clients roule ton
application dans un look&feel de son choix.
Le Get Started - Premier Pas au site montre très bien ce que je décris ici.
Certaines parties du site sont en francais, donc choissisez le drapeau
francais pour la visualiser. Nous espérons terminer le reste de notre
traduction en français très bientôt.
http://www.ultrid.com/index.php?module=Static_Docs&type=user&func=view&f=steps/index.html&meida
De nouveaux mots peuvent être ajoutés au langage à ceux que nous avons
déjà.
http://www.ultrid.com/modules/Static_Docs/data/fra/udoc/com-ultrid-se/index.html
L'architecture du moteur d'affichage ne requiert pas que ce soit nous
qui fassions ces mots. Il peuvent être développer par tous et chacun. Et
donc plus il y aura de service qui seront abstrait en tag, plus il y
aura de facilité et rapidité à produire des applications.
http://www.ultrid.com/index.php?module=Static_Docs&type=user&func=view&f=technology/index.html&meidF
merci
Pierre Morel
www.ultrid.com
Marc Collin wrote:
Pierre Morel wrote:
Quel solution libre te permet de créer une application en définissant
ton interface utilisateur aussi facilement...
Pierre Morel
le plus connu étant eclipse avec le plugin adéquat
Je crois bien qu'on ne parle pas de la même chose.
Le plugin eclipse va t'aider à produire ton interface et générer le code
Java pour toi. C'est super et je ne nie pas cette fonctionnalité quand
on se met dans la perspective du programmeur seulement.
Mais quand tes classes seront compiler et que tes jars seront fait,
l'utilisateur lui ne pourra rien y changer.
Ce que je te parle, c'est de séparer l'interface utilisateur du code,
c'est à dire de la vrai logique de l'application.
Avec une description de l'interface en XML,
1) Ca ne requiert pas que ce soit un programmeur qui fasse cette partie,
2) Le programmeur fait la logique requise pour que l'application
fonctionne.
Quand tu livres ton produit, tu as:
1) Une description du UI en XML
2) Tes classes ou fichier scripts.
Si une modification est requise dans le UI, n'importe qui peut la faire
sans l'intervention du programmeur, car la présentation est séparer de
la logique.
Ui original:
<jframe
<jmenu
<jtoolbar
<jpanel
<jlabel
<jtextfield
</jpanel>
<jframe>
UI modifié:
<jframe
<jmenu
<jpanel
<jlabel
<jtextfield
</jpanel>
<jtoolbar
<jframe>
Le toolbar est maintenant changer d'endroit, à la guise, de
l'utilisateur. Il n'a qu'à sauvegarder son fichier.
Exécuter à nouveau, et les changements sont immédiats.
Aucune compilation. Aucun packaging.
Les classes et/ou scripts continue à être aussi efficace qu'auparavant.
Avec ce modèle, tu n'as pas besoin de tout prévoir au moment de la
conception.
Si tu n'as pas mis de fonctionnalité pour le changement de Look&Feel
dans ton application, et bien l'utilisateur ajoute seulement un tag, et
voilà. Son programme est maintenant à ce look&feel
Ui original:
<jframe id="main-frame"
<jpanel
<jlabel
...
Ui modifié:
<jframe id="main-frame"
<plaf.manager plaf="SkinLF" theme="Whistler" ref-component="main-frame"/>
<jpanel
<jlabel
...
Aucune compilation. Tu ne sait même pas qu'un de tes clients roule ton
application dans un look&feel de son choix.
Le Get Started - Premier Pas au site montre très bien ce que je décris ici.
Certaines parties du site sont en francais, donc choissisez le drapeau
francais pour la visualiser. Nous espérons terminer le reste de notre
traduction en français très bientôt.
http://www.ultrid.com/index.php?module=Static_Docs&type=user&func=view&f=steps/index.html&meida
De nouveaux mots peuvent être ajoutés au langage à ceux que nous avons
déjà.
http://www.ultrid.com/modules/Static_Docs/data/fra/udoc/com-ultrid-se/index.html
L'architecture du moteur d'affichage ne requiert pas que ce soit nous
qui fassions ces mots. Il peuvent être développer par tous et chacun. Et
donc plus il y aura de service qui seront abstrait en tag, plus il y
aura de facilité et rapidité à produire des applications.
http://www.ultrid.com/index.php?module=Static_Docs&type=user&func=view&f=technology/index.html&meidF
merci
Pierre Morel
www.ultrid.com
Marc Collin wrote:Pierre Morel wrote:Quel solution libre te permet de créer une application en définissant
ton interface utilisateur aussi facilement...
Pierre Morel
le plus connu étant eclipse avec le plugin adéquat
Je crois bien qu'on ne parle pas de la même chose.
Le plugin eclipse va t'aider à produire ton interface et générer le code
Java pour toi. C'est super et je ne nie pas cette fonctionnalité quand
on se met dans la perspective du programmeur seulement.
Mais quand tes classes seront compiler et que tes jars seront fait,
l'utilisateur lui ne pourra rien y changer.
Ce que je te parle, c'est de séparer l'interface utilisateur du code,
c'est à dire de la vrai logique de l'application.
Avec une description de l'interface en XML,
1) Ca ne requiert pas que ce soit un programmeur qui fasse cette partie,
2) Le programmeur fait la logique requise pour que l'application
fonctionne.
Quand tu livres ton produit, tu as:
1) Une description du UI en XML
2) Tes classes ou fichier scripts.
Si une modification est requise dans le UI, n'importe qui peut la faire
sans l'intervention du programmeur, car la présentation est séparer de
la logique.
Ui original:
<jframe
<jmenu
<jtoolbar
<jpanel
<jlabel
<jtextfield
</jpanel>
<jframe>
UI modifié:
<jframe
<jmenu
<jpanel
<jlabel
<jtextfield
</jpanel>
<jtoolbar
<jframe>
Le toolbar est maintenant changer d'endroit, à la guise, de
l'utilisateur. Il n'a qu'à sauvegarder son fichier.
Exécuter à nouveau, et les changements sont immédiats.
Aucune compilation. Aucun packaging.
Les classes et/ou scripts continue à être aussi efficace qu'auparavant.
Avec ce modèle, tu n'as pas besoin de tout prévoir au moment de la
conception.
Si tu n'as pas mis de fonctionnalité pour le changement de Look&Feel
dans ton application, et bien l'utilisateur ajoute seulement un tag, et
voilà. Son programme est maintenant à ce look&feel
Ui original:
<jframe id="main-frame"
<jpanel
<jlabel
...
Ui modifié:
<jframe id="main-frame"
<plaf.manager plaf="SkinLF" theme="Whistler" ref-component="main-frame"/>
<jpanel
<jlabel
...
Aucune compilation. Tu ne sait même pas qu'un de tes clients roule ton
application dans un look&feel de son choix.
Le Get Started - Premier Pas au site montre très bien ce que je décris ici.
Certaines parties du site sont en francais, donc choissisez le drapeau
francais pour la visualiser. Nous espérons terminer le reste de notre
traduction en français très bientôt.
http://www.ultrid.com/index.php?module=Static_Docs&type=user&func=view&f=steps/index.html&meida
De nouveaux mots peuvent être ajoutés au langage à ceux que nous avons
déjà.
http://www.ultrid.com/modules/Static_Docs/data/fra/udoc/com-ultrid-se/index.html
L'architecture du moteur d'affichage ne requiert pas que ce soit nous
qui fassions ces mots. Il peuvent être développer par tous et chacun. Et
donc plus il y aura de service qui seront abstrait en tag, plus il y
aura de facilité et rapidité à produire des applications.
http://www.ultrid.com/index.php?module=Static_Docs&type=user&func=view&f=technology/index.html&meidF
merci
Pierre Morel
www.ultrid.com
demos.rb pour avoir une apercu de ce qui peut être fait en Ultrid.
demos.rb pour avoir une apercu de ce qui peut être fait en Ultrid.
demos.rb pour avoir une apercu de ce qui peut être fait en Ultrid.
Bonjour,
Nous sommes fier d'annoncer notre outil de création d'interface
utilisateur Java à partir d'un meta-langage en XML.
Voyez comment vous pouvez créer des applications 'rich-client' en
utilisant le XML et des langages scripts (10 langages supportés).
Facilement créer des applications localisés.
Ajouter un système d'aide sans effort.
Ajouter un element à votre fichier XML pour changer le Look & Feel.
Créer l'interface en XML dans la langue maternelle (le français).
Plusieurs démos sont disponible au site.
Un Tutoriel montre comment batir un Éditeur de texte avec XML et du
Javascript seulement.
Une réponse à Microsoft XAML pour la communauté Java ?
Bonjour,
Nous sommes fier d'annoncer notre outil de création d'interface
utilisateur Java à partir d'un meta-langage en XML.
Voyez comment vous pouvez créer des applications 'rich-client' en
utilisant le XML et des langages scripts (10 langages supportés).
Facilement créer des applications localisés.
Ajouter un système d'aide sans effort.
Ajouter un element à votre fichier XML pour changer le Look & Feel.
Créer l'interface en XML dans la langue maternelle (le français).
Plusieurs démos sont disponible au site.
Un Tutoriel montre comment batir un Éditeur de texte avec XML et du
Javascript seulement.
Une réponse à Microsoft XAML pour la communauté Java ?
Bonjour,
Nous sommes fier d'annoncer notre outil de création d'interface
utilisateur Java à partir d'un meta-langage en XML.
Voyez comment vous pouvez créer des applications 'rich-client' en
utilisant le XML et des langages scripts (10 langages supportés).
Facilement créer des applications localisés.
Ajouter un système d'aide sans effort.
Ajouter un element à votre fichier XML pour changer le Look & Feel.
Créer l'interface en XML dans la langue maternelle (le français).
Plusieurs démos sont disponible au site.
Un Tutoriel montre comment batir un Éditeur de texte avec XML et du
Javascript seulement.
Une réponse à Microsoft XAML pour la communauté Java ?
