Dégradation harmonieuse d'interfaces utilisateur - UsiXML

Dans notre cas, nous n’aurons qu’une seule présentation à construire. Dans la fonction qui la
construit, chaque paire identificateur#valeur est liée à un widget spécifique. Ainsi, nous
avons (le code complet se trouve en annexes) :
fun {ViewPresentation Data}
H
fun {Loop X}
case X of D#V|Xs then
in
if (D==picture andthen {IsAtom V}) then
Widget1|{Loop Xs}
elseif (D==countriesdatas andthen {IsDictionary V}) then
% Accumulator Functions and Procedures
proc{AccumuleOneElem Handle1 Handle2 DrawAction}
…
end
proc{AccumuleAllElem Handle1 Handle2}
…
end
%Drawing/UnDrawing Procedure
proc {DrawSquares CanvasHandle Dict List DrawAction}
…
end
proc {ToolTipMaker CanvasHandle List}
…
end
…
Widget2 (-> accumulateur -> ensemble de widgets)|{Loop Xs}
end
else nil end
end
in
r(desc:{Record.adjoin {List.toTuple lr {Loop Data}}
lr(glue:nswe background:c(180 179 203) handle:H)}
handle :H)
end
Notre application : critique de l’approche suivie
Comme nous nous en doutions avant de réaliser notre application, le gros désavantage de cette
technique réside dans la pauvreté de la définition/spécification de l’interface. En ne disposant
uniquement d’un record avec les données, le type de widget choisi doit toujours être spécifié à
la main dans la fonction de construction (les encadrés rouges dans le code de cette dernière le
montre clairement).
Avec une définition d’interface comme celle-ci, le choix reste donc arbitraire de bout en bout.
Or, dans notre processus de dégradation d’interfaces, il ne nous sera pas donné la possibilité
de spécifier nos choix de widgets de cette manière pour toutes les présentations possibles.
Il va donc sans dire que notre définition devra être enrichie si nous voulons avoir des règles de
sélection plus fines, dont le fonctionnement dépend de plusieurs niveaux d’abstraction de
l’interface.
51