Idées sur un éditeur ASP ?

Laurent Jordi

03/01/2009 à 18:17

Salut,

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

++

Laurent Jordi
http://www.ezlogic.mc

"Gloops" a écrit dans le message de
news:
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 à 11:54

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 peuve nt
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 à 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 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.

--
Patrice

"Gloops" a écrit dans le message de groupe de
discussion : #

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 ...

Gloops

05/01/2009 à 17:33

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 sty les et
des noms de contrôle. Je m'étais abstenu jusqu'à présent ne com prenant 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 cellu le 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 vi de
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 de la
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èr ement),
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 colo nne
de texte (en supposant que je ne dépasse pas la capacité), ça risqu e
d'être bien plus long. Quand je dis quarante lignes, c'est évalué e n
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éser ver
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 chaqu e
cellule" (dans l'éditeur de ressources ?) veut dire. La hauteur des c ellules
peut être bougée une fois pour toute à la souris donc peut-être une 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érote r 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 l a
lecture.

Par défaut on a le type de contrôle en tête (du nom de ressource) e t 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'affranchi r de
contraintes sur les nommages de ressources, en étant en mesure de garde r
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 ?

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 sty les et
des noms de contrôle. Je m'étais abstenu jusqu'à présent ne com prenant 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 cellu le 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 vi de
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 de la
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èr ement),
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 colo nne
de texte (en supposant que je ne dépasse pas la capacité), ça risqu e
d'être bien plus long. Quand je dis quarante lignes, c'est évalué e n
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éser ver
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 chaqu e
cellule" (dans l'éditeur de ressources ?) veut dire. La hauteur des c ellules
peut être bougée une fois pour toute à la souris donc peut-être une 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érote r 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 l a
lecture.

Par défaut on a le type de contrôle en tête (du nom de ressource) e t 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'affranchi r de
contraintes sur les nommages de ressources, en étant en mesure de garde r
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 ?

Vous avez filtré cet utilisateur ! Consultez son message

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 sty les et
des noms de contrôle. Je m'étais abstenu jusqu'à présent ne com prenant 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 cellu le 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 vi de
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 de la
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èr ement),
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 colo nne
de texte (en supposant que je ne dépasse pas la capacité), ça risqu e
d'être bien plus long. Quand je dis quarante lignes, c'est évalué e n
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éser ver
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 chaqu e
cellule" (dans l'éditeur de ressources ?) veut dire. La hauteur des c ellules
peut être bougée une fois pour toute à la souris donc peut-être une 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érote r 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 l a
lecture.

Par défaut on a le type de contrôle en tête (du nom de ressource) e t 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'affranchi r de
contraintes sur les nommages de ressources, en étant en mesure de garde r
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 à 18:08

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 sty les et
des noms de contrôle. Je m'étais abstenu jusqu'à présent ne com prenant pas
trop cette discussion...

En fait, je cherche à pouvoir faire de la "saisie au kilomètre", en m e
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 suivan t
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 ca s
dans la boîte à gants, dans un autre sous le siège, dans un autre c as
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 c ertes),
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 de s
lignes de l'éditeur, d'autre part la sélection des styles CSS, et j'a i
peut-être été un peu ... discret sur la question de l'ordre des lig nes.

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 de s
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 un e
dans la colonne des commentaires, où à l'occasion on peut avoir autre
chose à mettre.

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 sty les et
des noms de contrôle. Je m'étais abstenu jusqu'à présent ne com prenant pas
trop cette discussion...

En fait, je cherche à pouvoir faire de la "saisie au kilomètre", en m e
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 suivan t
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 ca s
dans la boîte à gants, dans un autre sous le siège, dans un autre c as
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 c ertes),
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 de s
lignes de l'éditeur, d'autre part la sélection des styles CSS, et j'a i
peut-être été un peu ... discret sur la question de l'ordre des lig nes.

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 de s
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 un e
dans la colonne des commentaires, où à l'occasion on peut avoir autre
chose à mettre.

Vous avez filtré cet utilisateur ! Consultez son message

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 sty les et
des noms de contrôle. Je m'étais abstenu jusqu'à présent ne com prenant pas
trop cette discussion...

En fait, je cherche à pouvoir faire de la "saisie au kilomètre", en m e
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 suivan t
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 ca s
dans la boîte à gants, dans un autre sous le siège, dans un autre c as
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 c ertes),
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 de s
lignes de l'éditeur, d'autre part la sélection des styles CSS, et j'a i
peut-être été un peu ... discret sur la question de l'ordre des lig nes.

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 de s
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 un e
dans la colonne des commentaires, où à l'occasion on peut avoir autre
chose à mettre.

Gloops

05/01/2009 à 18:41

Gloops a écrit, le 05/01/2009 18:08 :

En résumé, saisie au kilomètre de texte formaté avec accès au x 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 e n
forme de paragraphe ne s'applique pas à l'étiquette contenant son tex te,
mais au paragraphe lui-même (j'ai déjà donné ;) ). Peut-être de vrai-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 mod e
"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 à 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 ?)

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.

--
Patrice

"Gloops" a écrit dans le message de groupe de
discussion : u2$

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".

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.

--
Patrice

"Gloops" <gloops@invalid.zailes.org> a écrit dans le message de groupe de
discussion : u2$4Xz1bJHA.556@TK2MSFTNGP06.phx.gbl...

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".

Vous avez filtré cet utilisateur ! Consultez son message

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.

--
Patrice

"Gloops" a écrit dans le message de groupe de
discussion : u2$

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".

Gloops

05/01/2009 à 21:26

Patrice a écrit, le 05/01/2009 19:34 :

Désolé mais dans le contexte d'un éditeur de ressources je ne voi s 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 mi se 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 u ne
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électi on,
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 dan s 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 sen te
concerné :)

Si tu as des chaines très longues comme ressources, je vois que tu pe ux
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 exe mple
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".

Ben non. Justement, c'est bien ça le problème sous Visual Studio : il s
sont séparés. ça fait partie de ce qui me donne l'idée de mijoter un
é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 pl us
commode de travailler directement en balisage mais bon c'est peut-êtr e une
habitude de "vieux" développeur...

Bon, pour ajouter devant l'étiquette et 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 discus sion).
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 "concept eur" 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 a écrit, le 05/01/2009 19:34 :

Désolé mais dans le contexte d'un éditeur de ressources je ne voi s 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 mi se 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 u ne
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électi on,
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 dan s 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 sen te
concerné :)

Si tu as des chaines très longues comme ressources, je vois que tu pe ux
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 exe mple
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".

Ben non. Justement, c'est bien ça le problème sous Visual Studio : il s
sont séparés. ça fait partie de ce qui me donne l'idée de mijoter un
é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 pl us
commode de travailler directement en balisage mais bon c'est peut-êtr e une
habitude de "vieux" développeur...

Bon, pour ajouter devant l'étiquette et 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 discus sion).
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 "concept eur" 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.

Vous avez filtré cet utilisateur ! Consultez son message

Patrice a écrit, le 05/01/2009 19:34 :

Désolé mais dans le contexte d'un éditeur de ressources je ne voi s 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 mi se 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 u ne
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électi on,
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 dan s 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 sen te
concerné :)

Si tu as des chaines très longues comme ressources, je vois que tu pe ux
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 exe mple
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".

Ben non. Justement, c'est bien ça le problème sous Visual Studio : il s
sont séparés. ça fait partie de ce qui me donne l'idée de mijoter un
é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 pl us
commode de travailler directement en balisage mais bon c'est peut-êtr e une
habitude de "vieux" développeur...

Bon, pour ajouter devant l'étiquette et 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 discus sion).
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 "concept eur" 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 à 10:54

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é
http://msdn.microsoft.com/en-us/library/aa905797.aspx

Bonne continuation

--
Patrice

Gloops

06/01/2009 à 12:33

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), ce ci
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 mett re
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'usage de
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 :

Ok désolé de mon peu d'enthousiasme ;-)

De mon côté il m'est arrivé de gérer des ressources dans une ba se mais je ne
vois pas ce que les styles viennent faire la dedans. Pour moi la mise e n
forme n'est pas faitre ressources par ressources mais en fionction de s on
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 pouv oir e^tre
modifiée par un les traducteurs ?)...

Sion pour le "provider" c'est de ce côté
http://msdn.microsoft.com/en-us/library/aa905797.aspx

Bonne continuation

--
Patrice

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), ce ci
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 mett re
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'usage de
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 :

Ok désolé de mon peu d'enthousiasme ;-)

De mon côté il m'est arrivé de gérer des ressources dans une ba se mais je ne
vois pas ce que les styles viennent faire la dedans. Pour moi la mise e n
forme n'est pas faitre ressources par ressources mais en fionction de s on
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 pouv oir e^tre
modifiée par un les traducteurs ?)...

Sion pour le "provider" c'est de ce côté
http://msdn.microsoft.com/en-us/library/aa905797.aspx

Bonne continuation

--
Patrice

Vous avez filtré cet utilisateur ! Consultez son message

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), ce ci
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 mett re
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'usage de
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 :

Ok désolé de mon peu d'enthousiasme ;-)

De mon côté il m'est arrivé de gérer des ressources dans une ba se mais je ne
vois pas ce que les styles viennent faire la dedans. Pour moi la mise e n
forme n'est pas faitre ressources par ressources mais en fionction de s on
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 pouv oir e^tre
modifiée par un les traducteurs ?)...

Sion pour le "provider" c'est de ce côté
http://msdn.microsoft.com/en-us/library/aa905797.aspx

Bonne continuation

--
Patrice

Idées sur un éditeur ASP ?

10 réponses

Veuillez sélectionner un problème