Discussion :

[Jeweller]

Bonjour,
J'aimerai mettre en place une fonctionnalité de "terminologie" sur une application xmlrad2005R2 (Delphi7).
Mon idée est d'intercepter (par un moyen ou un autre) l'insertion des Locales dans la grappe XML et de remplacer une certaine syntaxe (à définir, inspirée des templates {$....} ) dans les traductions avant (ou apres) que celles ci ne soient disponibles pour la parse XSL.
Cela m'évite de repasser dans tous mes écrans XSL pour modifier tous mes textes et pointer vers une autre grappe XML. L'ajout d'une nouvelle langue ne répond pas à mes besoins

Je n'aime (vraiment) pas modifier les sources du framework, mais quelle serait selon vous la meilleure solution ? Si je pouvais écrire un évènement qui s'executerait juste apres la génération des locales ce serait parfait. J'ai pensé rajouter donc qqch dans le xmlcollection et d'en faire l'appel au niveau du AddLocales (xmlservice)... mais ce n'est pas si simple au final... Peut etre qqn à déjà bossé sur ce thème ?

Michael

[Sylvain James]

Je ne comprends pas très bien ce que tu veux faire exactement avec ce système de "terminologie" et en quoi les locales multi langues ne conviennent pas ?
Tu pourrais peut-être implémenter les BeforeXSL des XMLServices concernés, le code remplaçant les locales dans l'output.
On ne peut pas prendre la main avant, à priori, lors du AddLocales.

[Jeweller]

L'idée c'est de donner la possibilité aux clients de paramétrer son logiciel de façon à ce que certains termes clés correspondent à ceux qu'ils emploient dans leurs différents process. Exemple le mot "equipement" ne veut pas forcément dire la même chose pour tout les clients, un dira plutot "machine" l'autre "appareil" et le troisieme "unité de production"... bref... Et cela pour chaque terme clé (il y a en une petite 20aines).
Dans mes locales j'aimerai mettre "Voulez vous supprimer cet {$EQUIP}" et remplacer le terme {$EQUIP} par le mot ou la phrase défini par le client (c'est stocké dans la BDD). Une langue supplémentaire obligerait l'intégrateur à modifier toutes les phrases et le gros problème ensuite, c'est comment gérer les mises à jours!!!
Ensuite j'ai plusieurs centaines de xmlservice, donc si je dois faire cela au niveau d'un évènement pour chacun c'est aussi du boulot.

En fait je peux peut etre créer un descendant du WebForm en surchargeant le beforeXSL... ca c'est pas bete par contre!

[Sylvain James]

D'accord :-)
Si tu crées un descendant de webform, ça va se compliquer pour les migrations vers les versions plus récentes du framework.
D'autre part, je ne pense pas que tu puisses centraliser BeforeXSL pour tous les XMLServices de l'appli (au niveau de XMLCollection).
Il faudrait créer un hook sur tous les XMLServices concernés... (oui y'en a quand même beaucoup !)
Ou bien tant pis, modifier le framework...

[RDM]

c'est pas simple ton histoire...
par contre il est clair que de créer un descendant de WebForm n'est pas pas la bonne solution a long terme (XMLComponent va dégager dans la 2008)
En fait je pense qu'il te faut un événement equivletn a OnExecuteXMLService mais après l'execution = modif du framework.
Sinon AfterXMLService ou BeforeXSL sur tous tes XMLServices

[Jeweller]

Oui, c'est pas simple! Voici la solution pour la quelle je suis en train d'obter... je n'ai pas termine mais ca se passe bien pour le moment:

Je suis par contre obligé de modifier les sources du framework:
XMLService.pas, 780, dans Addlocales, juste avant l'ajout des locales au document racine, j'invoque un évènement que j'ai rajouté sur le TXmlcollection (ca m'évite me modifier aussi l'interface!):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
if Assigned(TXMLCollection(XMLCollection).OnParseLocales) 
then TXMLCollection(XMLCollection).OnParseLocales(XMLCollection,Context,LanguageLocales);

J'affecte dynamiquement mon évènement à la collection dans le onInitialize.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

xmlsession.TXMLCollection(XMLCollection).OnParseLocales := XMLCollectionParseLocales;

Ensuite lors de l'invocation, j'execute un xmlservice qui extrait les données de ma base (avec une instruction cache biensur) et je m'en sert pour traiter et remplacer les locales...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
procedure TMOS_Security.XMLCollectionParseLocales(XMLCollection: IXMLCollection; Context:IXMLContext; Locales: IXMLCursor);
var 
    CurLoc, CurVar,Input, OutPut:IXMLCursor; 
begin
   if Locales = nil then exit;
   try
     CurVar := XMLCollection.Execute2('GetVar',Input,OutPut);
     CurLoc := Locales.select('/Locales/*');
     while not CurLoc.EOF do
     begin
         //traitement des locales
         CurLoc.Next;
     end;
   except
     //comment avertir de l'erreur sans bloquer?
   end;
end;

Peut etre que je suis à coté de la plaque, mais je ne vais pas tarder à le savoir! J'espere juste ne pas créer de choses bizzard qui ne fonctionneront que pour un pool et pas un autre, etc...
Michael

[RDM]

euh tu me fais peur là: XMLCollection est bien de type IXMLCollection2 ?
c'est ca que tu transtypes en TXMLCollection ????
parce que là je peux t'assurer que cela ne va jamais marcher !

Les interfaces ont dégagés en 2007, mais pour 2006 il vaudrait mieux que tu déclares cela dans IXMLCollection2.

[Jeweller]

Je comprends ton "ca me fait peur"
Surtout qu'en plus ca fonctionne "apparement" tres bien! Si je modifie XMLCollection2 je vais devoir générer un nouveau stdxml.tlb, non ? On a tout ce qu'il faut pour faire ca ? Et puis comme tu dis, les mises à jours suivantes risquent de me poser bcp plus de probleme...
Comment vous feriez, vous ?

Michael

[RDM]

les interface en version 2 sont dans stdXMLC et n'ont pas besoin de TLB.
heureusement que tout cela saute en 2007, c'est vachement plus simple.

Tu ne peux pas récupérer la variable de classe à partir d'une variable d'interface. Si ca marche c'est coup de bol !
pour te convaincre que c'est pas correct :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
type
  IMyInterface = interface
  ['{5AA9D6CB-3148-4352-9F0F-840BEE6FEE33}']
    procedure MyMethod;
  end;
  TMyClass = class(TInterfacedObject, IMyInterface)
  private
    FInt: Integer;
  protected
    procedure MyMethod;
  public
    constructor Create;
    procedure MyMethod2;
  end;
 
constructor TMyClass.Create;
begin
  inherited;
  FInt := 42;
end;
 
procedure TMyClass.MyMethod;
begin
  ShowMessage('TMyClass.MyMethod');
end;
 
procedure TMyClass.MyMethod2;
begin
  ShowMessage('TMyClass.MyMethod2 '+IntToStr(FInt));
end;
 
procedure TfrmMain.Button2Click(Sender: TObject);
var
  MyObj: TMyClass;
  MyInterface: IMyInterface;
begin
  MyObj := TMyClass.Create;
  MyObj.MyMethod2;
  MyInterface := MyObj;
  MyInterface.MyMethod;
  TMyClass(MyInterface).MyMethod2;
end;

Explication:
MyObj et MyInterface ne pointe pas sur la même zone mémoire.
donc si tu appelles la method MyMethod2 avec MyInterface, quand tu as vas accéder aux données membres dans MyMethod2, ca va planter... ou pas (= pire ca écrit ou lit n'importe ou en mémoire...)

[Jeweller]

Mmm, ok chef!

Bon du coup le seul cast qui reste c'est dans le TXMLCollectionEvents.OnInitialize:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 IXMLCollection2(XMLCollection).OnParseLocales := XMLCollectionParseLocales;

Car XMLCollection est de type IXMLCollection.
Cela fonctionne bien autrement

Merci
Michael