[Allegro] Sprachcodes deutsch, offizielle ISO-Codeliste

[Thomas Berger]

Am 21.05.2015 um 08:58 schrieb Anando Eger:
> Hallo Herr Berger,
> 
>> Jedenfalls, unter
>> http://www.gymel.com/downloads/codes/
>> liegen nun zwei Dateien zum Experimentieren,
> 
> schöne Sache. Hab' wieder etwas über die Möglichkeiten des IE 
> dazugelernt.

XSLT koennen alle Browser. Und fuer die Verarbeitung im allegro-
Kontext nehme ich normalerweise eine von mir irgendwo gefundene
und etwas aufgemoebelte JavaScript-Emulation von xsltproc fuer
den WSH:
< http://svn.extra.gymel.com/viewvc/allegro/acxt/deploy/trunk/ >

Im Browser ist es einfach, wenn man die XML-Datei unter Kontrolle
hat und dann einfach eine xml-stylesheet Processing Instruction
ergaenzt, moeglichst auf ein extern gespeichertes Stylesheet.
Will man das Stylesheet einbetten, geht es auch noch, liegen die
Daten extern, wird es knifflig, der im gestrigen Beispiel genutzte
Zugriff auf die Originaldaten per document()-Funktion wird z.B.
von allen Browser aus CORS-Gruenden abgelehnt, da muesste die
LoC also schon mitspielen und die entsprechenden "Preflight-
Requests" positiv beantworten. "Normal" sind daher eher AJAX-
Requests etwa mit XHQ, aber auch hier sind in die Browser oft
staerkere Sicherheits-Schrauben einprogrammiert als fuer
vergleichbare JSON-Inhalte. Fuer irgendeine Anwendung, die
auf externe XML-Daten zugreifen sollte, musste ich sogar einen
Proxy aufsetzen lassen, damit XSLT und Daten dann scheinbar
von der gleichen Quelle kamen. Gluecklicherweise ist "Proxy
aufsetzen" eine Arbeit, die mit drei Zeilen in der Apache-
Konfiguration abgehandelt werden kann (und die Aktion war im
uebrigen mit der Originalquelle der Daten abgesprochen, /ich/
wuerde da erst einmal den Hahn abdrehen wenn ich bemerkte,
dass von einer mysterioesen Quelle plotzlich viele Anfragen
kommen...)



> Sie schrieben u.a. noch:
> 
>> ... leider gibt es m.W. aber absolut keine Moeglichkeit,
>> janas irgendwelche Parameter auf den Weg zu geben.
> 
> indirekt schon - ich nutze dafür das Template-Prinzip. Eine fertige 
> Funktion finden Sie hier:
> 
> http://www.aneg-dv.de/allegro/modpar/files/MP_JANAS.FLB

flex-crem, soso, jaja. Die naechste Version wird dann noch
die Sprungmarken und Variablennamen durch ausgewuerfelte Texte
ersetzen?


> Das sollte sich auch mit Ihrer Lösung "vertragen".

Es ist schon ein recht eingeschraenktes Setting, man koennte
vermutlich verantworten, eine Datei

<?xml version="1.0" encoding="cp850"?>
<?xml-stylesheet type="text/xsl" href="#"?>
<?app-param-fetchurl http://id.loc.gov/vocabulary/iso639-2.rdf ?>
<?app-param-callback mksprvw.flx ?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
 <xsl:import href="fetchmaschin.xml"/>
</xsl:stylesheet>

(die i.W. also nur die Parameter fuer den Aufruf enthaelt) per
write-Kommando im Flex zu generieren und janas darauf loszulassen.
Vermutlich gibt es dann aber zusaetzliche Komplikationen, ich
erinnere mich undeutlich dass ich fuer etwas aehnliches einmal
Dateien ins Arbeitsverzeichnis kopieren lassen musste, weil
sie sonst entweder nicht gefunden wurde oder irgendwelche Sicher-
heitsmechanismen zuschlugen.

Ich druecke mich allerdings auch vor der Frage, ob die
notwendigen Konfigurationsdaten, also eine zweispaltige
Tabelle
Name der Vw-Datei | URL der Originaldaten
plus die Moeglichkeiten zur Auswahl nun besser im Flex oder
in der Janas XML/XSL-Datei aufgehoben waeren... Jedenfalls
hat der Flex kein Gedaechtnis, er endet nach dem Launchen
von Janas und irgendwann wird er erneut aufgerufen und
kann ueberhaupt nur indirekt erkennen, dass es diesmal wohl
durch Janas war und nicht durch einen Benutzer oder Flip.
Dann muss er irgendwie ermitteln, welche Daten er da
praesentiert bekommt und wohin die wohl gehoeren. Alles
Sekundaerprobleme, aber fuer eine funktionierende Anwendung
ziemlich wichtig...



viele Gruesse
Thomas Berger