[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:
(2791 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!
X

xmlItem "adressieren" !?

WernerPerplies
Beiträge gesamt: 2393

21. Mär 2012, 14:53
Beitrag # 2 von 7
Beitrag ID: #492177
Bewertung:
(2756 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:
(2720 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: 170

22. Mär 2012, 23:35
Beitrag # 4 von 7
Beitrag ID: #492286
Bewertung:
(2674 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: 2393

23. Mär 2012, 06:30
Beitrag # 5 von 7
Beitrag ID: #492288
Bewertung:
(2651 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: 170

23. Mär 2012, 08:25
Beitrag # 6 von 7
Beitrag ID: #492291
Bewertung:
(2620 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: 2393

23. Mär 2012, 08:39
Beitrag # 7 von 7
Beitrag ID: #492292
Bewertung:
(2617 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
Hier Klicken

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
18.11.2019

Düsseldorf
Montag, 18. Nov. 2019, 09.30 Uhr

Schulung, Seminar

Mit WordPress ist es möglich, ohne große Kosten und ohne Programmierkenntnisse eine ansprechende Webseite zu erstellen, die allen Anforderungen des modernen Webdesigns – besonders unter Beachtung der Suchmaschinenoptimierung (SEO) – gerecht wird. Unsere Schulung Webdesign mit WordPress zeigt Ihnen, wie Sie hochwertige Webseiten mit WordPress erstellen.

Ja

Organisator: Cleverprinting.de

https://www.cleverprinting.de/schulungen/schulung-webdesign-mit-wordpress/

Suchmaschinen-optimiertes Webdesign mit WordPress
Veranstaltungen
19.11.2019 - 20.11.2019

Düsseldorf
Dienstag, 19. Nov. 2019, 09.30 Uhr - Mittwoch, 20. Nov. 2019, 17.30 Uhr

Schulung, Seminar

Unsere Schulung „Zweitägige Weiterbildung zum Cleverprinting-Reinzeichner“ bietet allen Anwendern, die in Agenturen oder freiberuflich als Reinzeichner bzw. in der Reinzeichnung arbeiten, topaktuelles Grafik- und PrePress-Fachwissen rund um das Thema „Druckdatenerstellung mit InDesign, Photoshop, Acrobat“.

Ja

Organisator: Cleverprinting.de

https://www.cleverprinting.de/zweitaegige-weiterbildung-zum-cleverprinting-reinzeichner/

Zweitägige Weiterbildung zum Cleverprinting-Reinzeichner