cerhu > microsoft.* > microsoft.dotnet.aspnet

Gloops (03/01/2009, 12h53)
Bonjour tout le monde,

Après avoir migré un site XHTML vers ASP à l'aide d'une moulinette
écrite pour, lors de l'écriture de nouvelles pages je me rends compte
que j'ai à augmenter cinq fois de suite la hauteur de chaque cellule
pour pouvoir lire ce qu'il y a dedans, dans l'éditeur de ressources
intégré à Visual Studio 2005.

D'où l'idée d'écrire un outil à cet effet. J'en suis à me demander
quelle serait l'interface utilisateur la plus pratique, si il s'agit
d'un fichier Word avec les noms des contrôles dans des commentaires par
exemple (il conviendrait alors de les saisir de façon semi-automatique
par une macro), ou si il vaut mieux une interface spécifique.

Je pense que le but est de pouvoir saisir du texte au kilomètre avec la
possibilité de le lire aisément pendant tout le processus, d'une part,
d'autre part aussi de pouvoir facilement sélectionner des styles dans
une feuille css, et aussi de pouvoir intervenir sur les noms des contrôles.

Quelqu'un serait-il susceptible d'utiliser un tel outil, et si oui avec
quels desiderata ?

Ou peut-être ce joujou existe-t-il déjà ?
Laurent Jordi (03/01/2009, 19h17)
Salut,

Un conseil... oublie cette idée... Apprends plutôt les CSS...

++

Laurent Jordi
[..]

"Gloops" <gloops> a écrit dans le message de
news:4072
Bonjour tout le monde,

Après avoir migré un site XHTML vers ASP à l'aide d'une moulinette
écrite pour, lors de l'écriture de nouvelles pages je me rends compte
que j'ai à augmenter cinq fois de suite la hauteur de chaque cellule
pour pouvoir lire ce qu'il y a dedans, dans l'éditeur de ressources
intégré à Visual Studio 2005.

D'où l'idée d'écrire un outil à cet effet. J'en suis à me demander
quelle serait l'interface utilisateur la plus pratique, si il s'agit
d'un fichier Word avec les noms des contrôles dans des commentaires par
exemple (il conviendrait alors de les saisir de façon semi-automatique
par une macro), ou si il vaut mieux une interface spécifique.

Je pense que le but est de pouvoir saisir du texte au kilomètre avec la
possibilité de le lire aisément pendant tout le processus, d'une part,
d'autre part aussi de pouvoir facilement sélectionner des styles dans
une feuille css, et aussi de pouvoir intervenir sur les noms des contrôles.

Quelqu'un serait-il susceptible d'utiliser un tel outil, et si oui avec
quels desiderata ?

Ou peut-être ce joujou existe-t-il déjà ?
Gloops (05/01/2009, 12h54)
Laurent Jordi a écrit, le 03/01/2009 18:17 :
> Salut,
> Un conseil... oublie cette idée... Apprends plutôt les CSS...


Bonjour,

Oui, j'applique les CSS, bien sûr (même si mes choix graphiques peuvent
parfois être discutables), sinon je ne parlerais pas d'inclure le choix
d'un style CSS dans l'interface. Est-ce que la maîtrise des CSS doit
permettre de saisir plus facilement les fichiers de ressources en
facilitant leur lecture pendant la saisie ?

Je veux bien qu'on m'explique ...
Patrice (05/01/2009, 15h20)
Je pense que c'est plus un problème de compréhension.

Tu parles en même temps de l'éditeur de ressources de VS et des styles et
des noms de contrôle. Je m'étais abstenu jusqu'à présent ne comprenant pas
trop cette discussion...

Si c'est bien l'éditeur de ressources, en 2008 (et sans doute en 2005) :
- double cliquer dans la marge sur le bas de la ligne affiche la cellule de
saisie aussi haute que nécessaire
- en faisant "view code" il est aussi possible de modifier directement les
ressources dans l'éditeur XML

Je ne vois pas ce que "augmenter cinq fois de suite la hauteur de chaque
cellule" (dans l'éditeur de ressources ?) veut dire. La hauteur des cellules
peut être bougée une fois pour toute à la souris donc peut-être une fois par
cellule (pourquoi 5 fois ?).

Je me demande si le terme "éditeur de ressources" est bien le même pour nous
deux.
Gloops (05/01/2009, 18h33)
Patrice a écrit, le 05/01/2009 14:20 :
> Je pense que c'est plus un problème de compréhension.
> Tu parles en même temps de l'éditeur de ressources de VS et des styles et
> des noms de contrôle. Je m'étais abstenu jusqu'à présent ne comprenant pas
> trop cette discussion...
> Si c'est bien l'éditeur de ressources, en 2008 (et sans doute en 2005) :
> - double cliquer dans la marge sur le bas de la ligne affiche la cellule de
> saisie aussi haute que nécessaire


En fait, c'est vrai, si le texte est déjà dans la cellule.
Si la cellule est vide et qu'on a quarante lignes à saisir dedans, pour
la première si il y a quarante cellules en-dessous on va faire un glissé
de souris jusqu'en bas, il n'y aura pas trop de souci, mais pour la
dernière, on va faire un glissé de souris jusqu'en bas de la ligne vide
en dessous, puis dérouler avec l'ascenseur pour faire réapparaître la
cellule vide, recommencer à faire un glissé de souris jusqu'en bas dela
ligne vide et cette fois on aura de la place pour deux lignes (en fait
un peu plus car par défaut la cellule fait apparaître deux lignes
d'écriture, donc on aura de la place pour quatre, évalué grossièrement),
et puis on continue. En fait, je disais cinq fois, mais dans l'exemple
où j'ai quarante lignes à taper dans la dernière cellule de la colonne
de texte (en supposant que je ne dépasse pas la capacité), ça risque
d'être bien plus long. Quand je dis quarante lignes, c'est évalué en
fonction de la largeur d'affichage de la colonne de texte, bien entendu.
Certes on peut l'élargir, ça ne fait que déplacer le problème ...

C'est vrai qu'une astuce pourrait être d'ajouter un certain nombre de
lignes à la fin qui n'aient pas de raison d'être autre que de réserver
de la place pour agrandir la dernière ligne utile.

> - en faisant "view code" il est aussi possible de modifier directement les
> ressources dans l'éditeur XML


Oui, mais je parlais de quelque chose de commode d'emploi et sans risque
de tout planter (peut-être proprement certes) en faisant des erreurs de
syntaxe (je pense par exemple aux fermetures de guillemets).

> Je ne vois pas ce que "augmenter cinq fois de suite la hauteur de chaque
> cellule" (dans l'éditeur de ressources ?) veut dire. La hauteur des cellules
> peut être bougée une fois pour toute à la souris donc peut-êtreune fois par
> cellule (pourquoi 5 fois ?).


En fait, j'ai répondu au-dessus ...

Un aspect à ne pas oublier : en l'état on doit veiller à numéroter les
cellules dans un ordre qui soit identique numériquement et
alphabétiquement, donc avec un nombre de chiffres fixe, sinon, les
lignes n'apparaissent pas dans l'éditeur de ressource dans l'ordre de la
lecture.

Par défaut on a le type de contrôle en tête (du nom de ressource) et un
numéro derrière, si on veut les lignes dans l'ordre de lecture il
faudrait faire l'inverse.

L'idée de gérer la saisie différemment était aussi de s'affranchir de
contraintes sur les nommages de ressources, en étant en mesure de garder
les ressources dans l'ordre de la création (peut-être à affiner ?).

> Je me demande si le terme "éditeur de ressources" est bien le même pour nous
> deux.


Je suppose, c'est peut-être l'usage fait qui n'est pas le même ?
J'ai tendance à faire une étiquette par paragraphe à faire apparaître,
peut-être est-ce un tort, je devrais en mettre plus ?
Gloops (05/01/2009, 19h08)
Patrice a écrit, le 05/01/2009 14:20 :
> Je pense que c'est plus un problème de compréhension.
> Tu parles en même temps de l'éditeur de ressources de VS et des styles et
> des noms de contrôle. Je m'étais abstenu jusqu'à présent ne comprenant pas
> trop cette discussion...


En fait, je cherche à pouvoir faire de la "saisie au kilomètre", en me
concentrant sur le sens du texte, sans avoir à me rappeler dans quel
contrôle je suis, où se trouve le texte du suivant, celui du précédent,
de quel type il est, quelles sont les contraintes si le contrôle suivant
est une image, si c'est une liste, ainsi de suite.

On n'envisagerait pas, au volant, d'introduire le volant dans un orifice
différent et en utilisant une clef différente (se trouvant dans un cas
dans la boîte à gants, dans un autre sous le siège, dans un autre cas
fixée au plafond) selon qu'on veut continuer tout droit, s'engager dans
une rue adjacente, dépasser, ou simplement attendre qu'un piéton
traverse. Le problème est un peu le même (aux conséquences près certes),
je trouve que devoir écrire le brouillon sur papier avant est une perte
de temps.

Je reviens donc à ma réponse, pour faire de la saisie au kilomètre,il
me semble qu'il importe d'une part de ne pas avoir à gérer la taille
d'affichage des cellules et en tout cas pas leur ordre, d'autre part que
les sélections de styles se fassent le plus rapidement et commodément
possible au cours de la saisie du texte sans quitter l'interface de
saisie. D'où, le fait d'aborder d'une part la question de la hauteur des
lignes de l'éditeur, d'autre part la sélection des styles CSS, et j'ai
peut-être été un peu ... discret sur la question de l'ordre des lignes.

En résumé, saisie au kilomètre de texte formaté avec accès aux noms des
paragraphes, cela appliqué aux ressources pour l'internationalisation.
L'éditeur de ressources permet d'introduire du texte, mais pas au
kilomètre, et pas en précisant rapidement la mise en forme sans se
déconcentrer du sens du texte.

Quand je dis accès aux noms des paragraphes, pour pouvoir introduire des
noms significatifs au même titre que les noms de variables peut-être,je
passe rapidement sur mon intention de présenter simultanément deux
langues pour chaque ressource (avec sélection de celle qui n'est pas la
culture par défaut, dite de "fall-back"), autrement qu'en en copiant une
dans la colonne des commentaires, où à l'occasion on peut avoir autre
chose à mettre.
Gloops (05/01/2009, 19h41)
Gloops a écrit, le 05/01/2009 18:08 :
> En résumé, saisie au kilomètre de texte formaté avec accès aux noms des
> paragraphes, cela appliqué aux ressources pour l'internationalisation.
> L'éditeur de ressources permet d'introduire du texte, mais pas au
> kilomètre, et pas en précisant rapidement la mise en forme sans se
> déconcentrer du sens du texte.


Et là, au passage, je prends conscience d'une difficulté : une mise en
forme de paragraphe ne s'applique pas à l'étiquette contenant son texte,
mais au paragraphe lui-même (j'ai déjà donné ;) ). Peut-être devrai-je
prévoir une notion de contenant.

A propos, pour gérer ça, jusque là, je passe en mode "source".
Savez-vous préciser une mise en forme de paragraphe en mode "design" ?
(et cette fois je ne parle pas de mon projet de nouvelle interface de
saisie, mais bien de l'interface Visual Studio 2005).

C'est vrai qu'une fois le paragraphe créé, on peut y accéder en mode
"design" par déplacements de curseur, en visualisant à droite des
onglets "design" et "source", le type de sélection. Toutefois il m'est
apparu nécessaire de créer le paragraphe en mode "source".
Patrice (05/01/2009, 20h34)
Désolé mais dans le contexte d'un éditeur de ressources je ne vois pas ce
qu'est un paragraphe. Pour moi, l'éditeur de ressources permet de définir
des chaines (String). Je ne comprends pas non plus cette histoire de mise en
forme dans ta ressource (tu mets les balises HTML directement dans tes
resssources ?)

Si tu as des chaines très longues comme ressources, je vois que tu peux
aussi les créer en tant que fichier texte ce qui te permet des les éditer
avec Notepad... Ou les éclatrer (titre, corps au lieu peut-être de mettre le
titre et le corps dans la même chaine).

Finalement ce n'est qu'une possibilité pas une obligation. Si par exemple
ton but est de donner accès aux traductions à un tiers tu peux gérer tes
ressources en base par exemple (et je crois que .NET permet même via un
"provider" de continuer à utiliser les mêmes mécanismes pour récupérer les
resssources).

En relisant le texte je crois que l'on ne parle pas effecivement de la même
chose. L'éditeur de ressources n'est pas pour moi le "concepteur de
formulaires".

Personnellement j'utilise le concepteur le moins possible. Je trouve plus
commode de travailler directement en balisage mais bon c'est peut-être une
habitude de "vieux" développeur...

Avant de te lancer dans un éventuel projet, vois aussi si le "concepteur" de
la version 2008 ne règle pas certains des problèmes que tu sembles avoir...

Bonne continuation.
Gloops (05/01/2009, 22h26)
Patrice a écrit, le 05/01/2009 19:34 :
> Désolé mais dans le contexte d'un éditeur de ressources je ne vois pas ce
> qu'est un paragraphe. Pour moi, l'éditeur de ressources permet de définir
> des chaines (String). Je ne comprends pas non plus cette histoire de mise en
> forme dans ta ressource (tu mets les balises HTML directement dans tes
> resssources ?)


Non, je ne crois vraiment pas qu'on puisse se limiter à un éditeur de
ressources. Il faut aller au-delà. Aussi bien puisque j'ai généréles
balises depuis le code XHTML tant pour les fichiers aspx que resx dans
la même opération, il ne me paraît pas absurde de le faire depuis une
saisie pour les nouvelles pages.

A priori, j'imagine un contrôle à répéter pour chaque ligne, qui
présente une zone de texte pour le nom de contrôle, une liste pour le
type de contrôle, une liste pour le format (renseignée d'après la
feuille CSS), deux zones de texte pour la culture par défaut (texte,
commentaire), et deux pour la culture étrangère (là aussi texte et
commentaire). Avant ça, en tête de l'interface de saisie, une zone
combinée pour sélectionner la culture étrangère, et une sélection,
probablement de fichier, pour la feuille CSS. Pendant qu'on y est il ne
paraît pas insurmontable que lorsqu'on modifie le contenu d'une zone de
texte de l'interface de saisie, cela ajuste sa taille automatiquement
(puisque pour bonne partie c'était le but).

Avec ça, on a ce qu'il faut pour générer les balises à mettre dans le
fichier aspx, et les deux fichiers de ressources, avec les
correspondances correctes entre les deux. Une fois que tout ça est fait,
il peut rester des retouches à faire sous Visual Studio, le but n'est
pas de tout refaire.

Bon, je venais voir si quelqu'un voyait des modifications à faire par
rapport à ces propositions, mais ... à condition que quelqu'un se sente
concerné :)

[..]
> En relisant le texte je crois que l'on ne parle pas effecivement de la même
> chose. L'éditeur de ressources n'est pas pour moi le "concepteur de
> formulaires".


Ben non. Justement, c'est bien ça le problème sous Visual Studio : ils
sont séparés. ça fait partie de ce qui me donne l'idée de mijoterun
éditeur qui fournit les trois fichiers (un aspx et deux resx, dans le
cas de deux langues) à Visual Studio pour qu'il poursuive le traitement.
Il y aura d'ailleurs un traitement un peu différent pour les langues
suivantes (à partir de la troisième si je compte bien), puisqu'alors
seul le fichier de ressources correspondant doit être généré.

> Personnellement j'utilise le concepteur le moins possible. Je trouve plus
> commode de travailler directement en balisage mais bon c'est peut-être une
> habitude de "vieux" développeur...


Bon, pour ajouter <p> devant l'étiquette et </p> après, c'est ce que
j'ai fait. Autrement, je dois dire qu'obtenir l'étiquette avec tous ses
paramètres avec juste un double-clic, je trouve ça pas mal, à ceci près
qu'avoir le texte dedans aiderait bien, quand même (d'où cette discussion).
Mais au fait, gérer le code HTML en balisage, en "vieux développeur",ça
suppose de balancer du eacute à la place d'un e accent aigu ? Il faut
être motivé :)
Il est vrai que j'ai bien l'impression que ça fait partie de ce que je
me propose de faire, mais par code cette fois.

> Avant de te lancer dans un éventuel projet, vois aussi si le "concepteur" de
> la version 2008 ne règle pas certains des problèmes que tu sembles avoir...


Moui, ça signifierait clairement m'offrir une nouvelle machine.
C'est prévu, mais il y a quelques étapes, avant, dont la première
bientôt, "signer en bas à droite" :)

> Bonne continuation.


Merci.
Patrice (06/01/2009, 11h54)
Ok désolé de mon peu d'enthousiasme ;-)

De mon côté il m'est arrivé de gérer des ressources dans une base mais je ne
vois pas ce que les styles viennent faire la dedans. Pour moi la mise en
forme n'est pas faitre ressources par ressources mais en fionction de son
usage (c'est un label de champ etc.. etc...)

Difficile parfois de communiquer quand on a n'a pas forcément les mêmes
besoins. Pour l'instant c'est un peu trop sophistiqué pour moi (faute sans
doute de connaître ton besoin, la mise en forme doit également pouvoir e^tre
modifiée par un les traducteurs ?)...

Sion pour le "provider" c'est de ce côté
[..]

Bonne continuation
Gloops (06/01/2009, 13h33)
Oui, la mise en forme est appliquée à un contrôle, et le contrôle
contient un texte. Ce qui fait que pour finir, lorsqu'on lit, on voit la
mise en forme appliquée au texte. Le contrôle, et la ressource qui va
avec, c'est juste une cuisine interne.

C'est surtout le rédacteur, qui a besoin d'avoir accès à la mise en
forme, bien entendu. Telle mise en garde doit apparaître en italique,
par exemple, donc concrètement avec le style des mises en garde. Je me
représente mal comment, pour l'utilisateur (en fait les utilisateurs :
rédacteur et lecteur, même si le premier est aussi développeur), ceci
doit dépendre d'un nom de ressource, ou d'un nom de contrôle. Il
m'apparaît que le rédacteur, lorsqu'il explique par exemple ses
aventures dans la forêt vierge, n'a rien à faire, lorsqu'il veut mettre
en italique des points de repère topographiques, que le paragraphe
correspondant s'appelle Label1225, mais que ce qu'il veut mettre en
italique, c'est bien tel poteau télégraphique en tant que point de
repère, et ce qu'il propose de découvrir à l'alentour.

La question de donner accès à la mise en forme au traducteur est
intéressante. C'est vrai que l'outil proposé par Visual Studio pour être
mis à disposition des traducteurs permet d'intervenir sur la mise en
forme, afin certainement de pouvoir ajuster la taille de la police si un
intitulé est beaucoup plus long dans une langue que dans une autre. Je
n'avais pas pensé à cet aspect, et c'est vrai que je n'avais proposé
qu'un style pour chaque contrôle. Je vais voir, peut-être que je me
dirai que cet aspect n'étant pas trop fréquent, on peut laisser
intervenir dessus directement depuis l'éditeur du formulaire.

Quand je parle de rédacteur et de traducteur, je n'évoque pas l'usagede
webparts, juste la rédaction du site avec Visual Studio, ou
éventuellement un outil plus commode.

______________________________________
Patrice a écrit, le 06/01/2009 10:54 :
[..]
Patrice (06/01/2009, 14h32)
Une dernière remarque... J'ai l'impression que cela va tout de même assez au
delà de la gestion usuelle de la simple traduction d'un site web. Je ne sais
pas quelle est la fonction principale de ce site web mais cela me fait
plutôt penser à un wiki... Surtout que si j'ai bien compris le site avant
était statique.

As tu envisagé la possibilité d'utiliser un site de gestion de contenu ou
plus précisemment un moteur de Wiki selon l'objectif de ce site ?
Gloops (06/01/2009, 16h26)
En fait, je prévois de me préparer un outil pour saisir des pages aspx
en général, pas juste pour un site web donné, ça serait dommage.

La gymnastique de taper le texte dans un éditeur de texte et de le
copier vers le contrôle ensuite, puis faire la même chose pour la
traduction, cette fois vers l'éditeur de ressources, après avoir
localisé la ressource que je suis en train de traiter, je finis par
trouver ça assez lourd à la longue.

Ensuite, une fois que c'est saisi, a priori je m'en remets aux outils
usuels de Visual Studio, quand il y a juste des petites retouches ça
reste gérable il me semble.

Pour le moment, je n'exploite de .Net que l'internationalisation
(implicite et explicite), ce qui certes est dommage, mais il fallait
bien commencer par quelque chose. Le dernier sujet mis en ligne
justifierait bien un échange interactif avec les utilisateurs, mais ça,
ça sort du sujet de l'éditeur asp.

Bon, j'ai l'impression que ça va être juste pour moi ...

Bon ben tant pis. Merci pour le temps passé, et pour les idées, pour des
gens pas intéressés (si j'ai bien compris) c'était quand même très
constructif, je me suis rendu compte que j'avais oublié des trucs.

______________________________________
Patrice a écrit, le 06/01/2009 13:32 :
[..]
Discussions similaires
50 cm3 ... des idées...???

Editeur Wysiwyg, éditeur page web

Après le menun déroulant, l'éditeur html. quel est votre éditeur html préféré?

Des idées, toujours des idées, rien que des idées !!!!


Fuseau horaire GMT +2. Il est actuellement 16h17. | Privacy Policy