[GastForen Programme Print/Bildbearbeitung Adobe InDesign Skriptwerkstatt xmlItem "adressieren" !?

  • Suche
  • Hilfe
  • Lesezeichen
  • Benutzerliste
Print/Bildbearbeitung - Photos, Layout, Design
Themen
Beiträge
Moderatoren
Letzter Beitrag

xmlItem "adressieren" !?

madoho
Beiträge gesamt: 132

21. Mär 2012, 14:30
Beitrag # 1 von 7
Bewertung:
(2783 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
hallo zusammen,
ich steh abermals glaub ein wenig auf dem schlauch. in meinem skript mache ich folgendes:

Code
var _Doc = app.activeDocument; 
var _Root = _Doc.xmlElements[0];

var _xpathElements = _Root.evaluateXPathExpression (".//image");

for ( var c = 0; c < _xpathElements.length; c++ ) {

}


In der for-Schleife werkel ich dann mit den Bilder o.Ä. dann rum. Machmal kommt dann auch ein Element, wo ein Fehler passiert.

Jetzt meine Frage: ich würde dann für jedes Element das ich gerade bearbeite dessen genaue "Adresse" haben um raus zu finden, wer da ein Problem hat. Als Ergebnis hätte ich gerne etwas in der Art:

root[0].range[4].article[2].image[5]

mit .markupTag.name und .index bekomme ich das noch für das aktuelle Element hin. Nur wie hangel ich dann hoch bis zum Root-Element?

Bin wie immer für alle sachdienlichen Hinweise dankbar!

Vielen Dank im Voraus!
Hier Klicken X

xmlItem "adressieren" !?

WernerPerplies
Beiträge gesamt: 2388

21. Mär 2012, 14:53
Beitrag # 2 von 7
Beitrag ID: #492177
Bewertung:
(2748 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo Manu,

Zitat Machmal kommt dann auch ein Element, wo ein Fehler passiert.


Für solche Fälle gibt es try - catch

Code
var _Doc = app.activeDocument;  
var _Root = _Doc.xmlElements[0];

var _xpathElements = _Root.evaluateXPathExpression (".//image");

for ( var c = 0; c < _xpathElements.length; c++ ) {
try
{


}
catch (error)
{
alert(error.message +"\n" + error.line.toString());
}
}

Wenn Du im ESTK auf das alert einen Unterbrecherpunkt setzt, kannst Du Objekte und Variablen in der Konsole auf Fehlerbedingungen hin untersuchen.

Einen schönen Tag wünscht

Werner Perplies
Auftragsprogrammierung und Skripte für Adobe InDesign
neu: WpsProjectHandler 15.06.2018, Version 1.75, neue Funktionen
Aktuelles
XING


als Antwort auf: [#492175]
(Dieser Beitrag wurde von WernerPerplies am 21. Mär 2012, 14:56 geändert)

xmlItem "adressieren" !?

madoho
Beiträge gesamt: 132

21. Mär 2012, 17:39
Beitrag # 3 von 7
Beitrag ID: #492197
Bewertung:
(2712 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Okay… danke!

Dann spiel ich damit mal ein bisschen rum… :)


als Antwort auf: [#492177]

xmlItem "adressieren" !?

Dirk Becker
Beiträge gesamt: 169

22. Mär 2012, 23:35
Beitrag # 4 von 7
Beitrag ID: #492286
Bewertung:
(2666 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
alert() ist zum Debuggen unpraktisch - man muss dann immer erst den Dialog wegklicken und wenn ESTK mal wieder den Brechpunkt vergisst wird man in einer ungünstigen Schleife mit richtig vielen Dialogen beglückt.

Um direkt im Debugger zu landen, reicht der Aufruf $.bp() - $ ist das vordefinierte Helper-Objekt und bp() steht für Breakpoint. Optional darf man sogar noch eine Bedingung mitgeben.

Danach ganz nett zum Debuggen: app.select(myXMLElement) zeigt das XE direkt in der Struktur an. app.select(myXMLElement.xmlAttributes.everyItem()) klappt sogar noch die Attribute auf.

Beliebige native Objekte (nicht nur XMLElement) lassen sich für später merken, mit der Funktion myObject.toSpecifier(). Das Ergebnis läßt sich mit resolve wieder zum ursprünglichen Objekt umwandeln, soweit dieses noch existiert.

Also: myObject = resolve(myObject.toSpecifier());

Dirk


als Antwort auf: [#492177]

xmlItem "adressieren" !?

WernerPerplies
Beiträge gesamt: 2388

23. Mär 2012, 06:30
Beitrag # 5 von 7
Beitrag ID: #492288
Bewertung:
(2643 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo Dirk,

nur zur Klarstellung:

Alert innerhalb des Programmablaufes ist natürlich nicht sinnvoll, ein Alert innerhalb des Catches halte ich für sinnvoll, denn es sorgt dafür, dass erkannte Fehler gemeldet werden, denn ein nicht bemerkter Fehler kann die Programmlogik beeinflussen, man sucht dann vielleicht lange an der falschen Stelle.

Dann kann man entscheiden, wie der Fehler zu behandeln ist:
Fehler ignorieren, weil er nicht kritisch ist,
Fehler protokollieren, und nach Programmablauf analysieren und ggf. die Fehlerbehandlung anpassen,
Kritischer Fehler, Abbruch oder neuen Fehler werfen, je nach Situation.

Einen schönen Tag wünscht

Werner Perplies
Auftragsprogrammierung und Skripte für Adobe InDesign
neu: WpsProjectHandler 15.06.2018, Version 1.75, neue Funktionen
Aktuelles
XING


als Antwort auf: [#492286]

xmlItem "adressieren" !?

Dirk Becker
Beiträge gesamt: 169

23. Mär 2012, 08:25
Beitrag # 6 von 7
Beitrag ID: #492291
Bewertung:
(2612 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Ich bin noch immer gegen Alerts mitten im Code. Mein Code wird aber auch massiv auf InDesign Servern eingesetzt, da verbietet sich das von selbst.

Bei der Entwicklung sollte man grundsätzlich die Option im ESTK ausschalten "Do not break on guarded Exceptions" - letzter Eintrag im Debug Menü. Damit findet man Programmfehler sofort - der Debugger steht dann auf der richtigen Stelle.

Ich verwende try-catch nie zur Behandlung von vorher erkennbaren Ausnahmezuständen. Gerade solche Fehler sollte man im Ablauf vorab berücksichtigen, also in unserem Fall etwa fehlende XML Elemente, diese lassen sich mit "isValid" überprüfen. Genauso die Probleme mit Übersatz "overset". Bisher habe ich fast immer einen passenden Test gefunden - Ausnahmen wären defekte Dateien beim Öffnen von Dokumenten bzw. XML Import. Du beschreibst das übliche Vorgehen ja auch mit den anstehenden Programmierer-Entscheidungen.

Das prophylaktische try-catch für unerwartete Ausnahmen in größeren Subsystemen kippt man in ein allgemeines Fehlerreporting - etwa eine Log-Ausgabe. Bei uns produzieren solche Fehler grundsätzlich ein email an die zuständigen Entwickler und einen Fehler-Status. Danach kann sich das Programm entweder (halbwegs) erholen und mit dem nächsten unabhängigen Arbeitsschritt sinnvoll weitermachen, oder es gibt auf mit einem weiteren throw.

Nur auf oberster Aufrufebene bei interaktiven Programmen - also zum Beispiel beim Menü-Invoke oder Button-Klick, würde ich ein try-catch mit Alert oder ähnlichem vorsehen. Beim Server würde entsprechend eine Nachbearbeitung angefordert - mit Fehlerstatus im Asset Management System oder ähnlichem.

Dirk


als Antwort auf: [#492288]

xmlItem "adressieren" !?

WernerPerplies
Beiträge gesamt: 2388

23. Mär 2012, 08:39
Beitrag # 7 von 7
Beitrag ID: #492292
Bewertung:
(2609 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hallo Dirk,

Zitat Ich bin noch immer gegen Alerts mitten im Code. Mein Code wird aber auch massiv auf InDesign Servern eingesetzt, da verbietet sich das von selbst.


Klar, im unbeaufsichtigen Ablauf ist das selbstverständlich.
Ausnahme vielleicht ein Fehler, der den weiteren Ablauf unmöglich macht. Auf dem Server sollte so etwas dann eine Meldung (email) an den Administrator auslösen.

Deshalb protokolliere ich im Regelfall Fehler.

Aber das erwähnst Du ja auch weiter unten.

Zitat Ich verwende try-catch nie zur Behandlung von vorher erkennbaren Ausnahmezuständen.


Auch da stimme ich Dir zu. Da man aber vielleicht nicht alle Ausnahmeursachen im Voraus weiß, try - catch mit Fehlerbehandlung.
Das hier (und auch in einigen Adobe-Unterlagen) auftauchende try{...}catch(e){};
ist m. E. eine unverzeihliche Unsitte.

Wenn ich das richtig sehe, sind wir über die richtige Vorgehensweise ja weitgehend einig.

Einen schönen Tag wünscht

Werner Perplies
Auftragsprogrammierung und Skripte für Adobe InDesign
neu: WpsProjectHandler 15.06.2018, Version 1.75, neue Funktionen
Aktuelles
XING


als Antwort auf: [#492291]
Hier Klicken X

Aktuell

InDesign / Illustrator
InDesign_Fazit

Veranstaltungskalender

Hier können Sie Ihre Anlässe eintragen, welche einen Zusammenhang mit den Angeboten von HilfDirSelbst.ch wie z.B. Adobe InDesign, Photoshop, Illustrator, PDF, Pitstop, Affinity, Marketing, SEO, Büro- und Rechtsthemen etc. haben. Die Einträge werden moderiert freigeschaltet. Dies wird werktags üblicherweise innert 24 Stunden erfolgen.

pdf-icon Hier eine kleine Anleitung hinsichtlich Bedeutung der auszufüllenden Formularfelder.

Veranstaltungen
21.10.2019 - 23.10.2019

Riga, die Hauptstadt Lettlands
Montag, 21. Okt. 2019, 09.32 Uhr - Mittwoch, 23. Okt. 2019, 09.33 Uhr

VIP-Event

Jedes Jahr haben Sie die Möglichkeit, beim VIP-Event mehr über die Produkte von axaio software, callas software und andere Lösungen zu erfahren, die Four Pees anbietet.

Diejenigen, die uns bereits kennen, wissen, dass wir gerne Business mit Genuss kombinieren. Wir sind schon sehr gespannt und wollen Ihnen deshalb gern einen Blick hinter die Kulissen gewähren ...

Die Stadt der gotischen Türme
Das diesjährige Ziel ist Riga, die Hauptstadt Lettlands. Die gotischen Türme, die das Stadtbild Rigas dominieren, haben den Anschein von Strenge, aber das trifft nicht zu. Diese pulsierende, kosmopolitische Stadt ist die größte der drei baltischen Hauptstädte und beherbergt einige Szenebars und experimentelle Restaurants. Das klingt doch nach einem perfekten Rahmen für unser nächstes VIP-Event, oder?

Nein

Organisator: callas

https://www.callassoftware.com/de/events/2019/10/vip-event-riga

Sind Sie für das nächste VIP-Event bereit?
Veranstaltungen
22.10.2019 - 23.10.2019

InDesign-Skripte: Königsklasse der Automatisierung

München
Dienstag, 22. Okt. 2019, 09.30 Uhr - Mittwoch, 23. Okt. 2019, 17.30 Uhr

Schulung, Seminar

Wer sich mit dem Skripting auskennt, der kann sich eigene Skripte erstellen und bestehende Skripte modifizieren. So lassen sich praktisch alle Arbeitsschritte in InDesign automatisieren. Hier versteckt sich ein enormes Einsparpotential. Arbeitschritte, die manuell viel Zeit und Nerven rauben, können mit Skripten in Sekunden erledigt werden.

Ja

Organisator: Cleverprinting.de

https://www.cleverprinting.de/schulung-skripting-mit-indesign/

Skripting in InDesign