Web Source Framework

Hallo, es gibt so ein paar Sachen, die vermiss ich beim Schreiben und Experimentieren von Web Sources Skripten immer wieder:

1. Dekodieren von verschiedenen Encodings
Es gibt ja für das einbinden der Suchbegriffe in die IndexURL & AlbumURL bereits die Zeile:
[Encoding]=
Das müßte es umgekehrt für das Output auch geben:
[Decoding]=
Oder alternativ auch als Befehl, den man immer wieder im Script anwenden muss:
decode "utf-8" "unicode"
oder so ähnlich.

Ich habs hier schon mal angesprochen: /t/11477/1
Bei meinem jetztigen Discogs Skript ersetzt ich UTF-8 (hex.) Codierungen mit den Unicode Zeichen. Oder eine Variante von UTF-8 (hex.), so genau kenn ich mich da nicht aus, bei Discogs stehen da immer Pozentzeichen (%) mit drin. Also z.B. für å steht %C3%A5 anstatt 0xC3 0xA5 oder c3a5 wie ich das in anderen Tabellen finde.
Bei meinem Discogs Skript sind das jetzt über 900 replace Kommando, die das Skript spürbar langsamer machen. Ausserdem trotzdem nur einen Teil der Zeichen abdecken. (Die ersten beiden Zeichensätze von hier: http://www.utf8-zeichentabelle.de/unicode-utf8-table.pl ). Wer chinesische oder russische Musik taggen will, dürfte Probleme bekommen.

Jetzt bin ich beim ersten Versuch ein Web Script für die in JSON gefasste API Version von Discogs zu schreiben über ein ähnliches Problem gestolpert. Dort sind Sonderzeichen scheinbar in C/C++/Java source code kodiert. Oder eine Variante davon, für å steht \u00e5 anstatt "\u00e5 " wie ich das hier: http://www.fileformat.info/info/unicode/char/e5/index.htm finde.

Wie gesagt, ich kenn mich da nicht so aus. Weiß nicht wie umständlich das ist zum einbauen. Aber da es das [Encoding]= schon gibt, müßte es doch rückwärts auch möglich sein.

2. bestehendes Output nochmal in den Text einfügen
Oft hab ich mir schon gedacht das wäre praktisch. Meisten konnte ich das Problem dann auch irgendwie anders lösen. Aber nur so mal vorgeschlagen:
Ein Befehl PasteOutput ähnlich wie SayOutput. Nur das der bereits bestehende Text nochmal in den Text der online Quelle eingefügt wird, und zwar an die Stelle, an der sich der Parser gerade befindet. Damit könnte man den Text in kombinatione mit anderen Werten weiter mit RegexpReplace oder anderem bearbeiten. Wär ganz praktische, weil es oft ein Hindernis ist, das solche Probleme nur für die momentane Zeile zählen.

3. [ParserScriptIndex] wiederholen
Für komplexere Suchen wäre es praktisch, wenn man den [ParserScriptIndex] Part auch zweimal oder öfter durchführen könnte. Etwa bei Discogs erst allgemein Suchen, und dann auf einer Master Release Page (wo verschiedene Versionen eines Albums aufgelistet sind) die Suche nochmal verfeinern.
Am besten wärs, wenn man das optional machen könnte, etwa

if "Master Page"

[ParserScriptIndex] 

endif

4. mehr als ein Coverbild speichern
Es gibt ja genügend Seiten, die mehr als nur das Frontcover bieten. Da wäre es natürlich praktisch die auch mit speichern zu können. Etwa:
outputto "coverurl_1"
outputto "coverurl_2"
outputto "coverurl_3"
outputto "coverurl_4"
Und dann in den Optionen jeden Nutzer festlegen lassen, welch Dateinamen man dafür geben will und als welcher Covertyp das in der Datei gespeichert werden soll.

oder:
outputto "coverurl_front"
outputto "coverurl_back"
outputto "coverurl_disc"
outputto "coverurl_other"
Und damit gleich den Typ und Dateinamen vorgeben. Wenn man dann in den Optionen weiterhing den Namen für das Hauptcover (also coveurl_front) frei vergeben kann, wär das nicht schlecht.

Bereits schon mal woanders erwähnt:
Im Fenster "anpassen der ermittelten Informationen", den horizontalen Scrollbalken immer in beiden Fenstern (die Tracks aus der Web Source und die zu beschreibenden Dateien) anzeigen, damit man parallel Scrollen kann ohne dass sich die Track verschieben. Am besten gleich einen vertikalen Scrollbalken für beide Fenster, man will ja eigentlich immer die Track sehen wie sie dann zugeordnet werden.

Im selben Fenster die bei Utils versteckten Optionen zum Cover schreiben, an den freien Platz am rechten Rand under der Cover Vorschau schieben. Ab und zu möchte ich das nämlich bei eingen Alben anders haben als meine Standard Einstellung, und meistens vergess ich das dann zurück zu stellen, weil es eben nicht direkt angzeigt wird.

Es wäre einfacher, wenn Multivalue Tags direkt mit Web Sources geschrieben werden könnten, ohne dass man danach die Tag-Felder am \\ trennen muss.

Lieber pone, und auch Florian und Dano und andere, bitte das Folgende nicht falsch verstehen, denn ich bewundere die Leistung wirklich sehr, die pone und andere mit dem 'krüppeligen' WebSource Werkzeug zustande bringen können. Dafür muss man schon ziemlich verquer denken könnnen, und wie MacGyver in der Lage sein, eine Vielzahl unorthodoxer Lösungen zu finden für teilweise einfachste Programmier-Problemchen. Wenn ich in die neuesten WebSource Skripte hineinschaue, da habe ich das Gefühl, es paart sich RegEx mit Lochkarte.

pone, was du nun an Verbesserungsvorschlägen vorbringst, ist meines Erachtens nur ein 'Herumdoktern' an Designproblemen der WebSource Programmiersprache und Schnittstelle.

Ich bin davon überzeugt, wenn die Schnittstelle zwischen Mp3tag und dem Ding was sich WebSource Skript nennt, ordentlich dokumentiert und offen zugänglich wäre, dass sofort einige gute Programmierer auf den Plan treten würden und eine moderne Art und Weise der Datengewinnung für Mp3tag etablieren könnten, wesentlich einfacher im gesamten Handling, Nutzung des Object Document Modells der Webseiten, Standard Programmiersprachen usw. usw.
Der AlbumArtDownloader macht es doch schon seit vielen Jahren vor, wie das funktionieren kann.

Das aktuelle Mp3tag Websource Framework ist leider nur ein Rahmenwerk mit zu vielen Lücken und ganz komischen Eigenartigkeiten. Ich gehe an dieses Ding so wie es ist nicht mehr dran, weil es mich einfach viel zu viel Zeit kosten würde. Es gibt andere Werkzeuge, die, nicht unbedingt im Handumdrehen, aber mit wesentlich weniger Aufwand und ausgestattet mit besseren Funktionen, schneller Ergebnisse liefern.

DD.20120211.2000.CET