Strukturierung von Definitionen

[Ralf]

Hallo,

ich muss für eine Javascript-Anwendung Daten in HTML sinnvoll strukturieren. Es handelt sich dabei um Daten für einen Reportgenerator.

Bisher habe ich folgende Definition benutzt, um ein Ausgabeformat für eine Tabelle zu definieren:

  
<REPORT  
  id="packliste"  
  typ="TABELLE"  
  from="ARTIKEL"  
  ></REPORT>  
<TABELLE  
  report="packliste"  
  header="Packliste"  
  table="border=2 cellspacing=0 cellpadding=5"  
  format="font:10pt verdana;background-color:ThreeDLightShadow;"  
  ></TABELLE>  
<SPALTE  
  report="packliste"  
  header="Menge"  
  data="[[[Menge]]]"  
  sum="0"  
  format="text-align:right;"  
  ></SPALTE>  
<SPALTE  
  report="packliste"  
  header="Bezeichnung"  
  data="[[[Artikelbeschreibung]]]"  
  sort="A"  
  ></SPALTE>  
<DETAIL  
  report="packliste"  
  suppress="y"  
  format="background:#eeffee;"  
  alt="background:#ccffcc;"  
  ></DETAIL>  
<SUMME  
  report="packliste"  
  format="background:white;"  
  alt="background:InfoBackground;"  
  suppress=""  
  ></SUMME>  
<GESAMT  
  report="packliste"  
  format=""  
  suppress="Y"  
  ></GESAMT>  

Diese Struktur lässt sich sowohl im IE als auch Firefox per DOM-Zugriff verarbeiten, befriedigt aber nicht meine Ansprüche an eine sauber (=valide) definierte Struktur.
Es gibt in dieser Definition eine gewisse Hierarchie, welche durch Verwendung des report-Attributes hergestellt wird.
Definiert wird im Beispiel ein REPORT vom Typ TABELLE mit bestimmten Eigenschaften (SPALTE(n), DETAIL, SUMME GESAMT).

Für eine "saubere" Struktur muss natürlich ebenfalls der DOM-Zugriff einfach möglich sein. Ich bin zwar bereit, den Javascript-Code anzupassen, möchte aber dort auch keine unnötigen Klimmzüge machen.

Auf die Frage bin ich gekommen, weil mir bei anderer Gelegenheit Definitionen mit DL/DT/DD aufegfallen sind und vielleicht kann ich das auch sinnvoll verwenden? Wenn ja - wie sollte ich die Definition gem. obigem Beispiel strukturieren? Wenn nein - gibt es Alternativen?

Um Fragen vorzubeugen: Es kommt ausschließlich HTML für die Definition in Frage und es handelt sich um ein Definition innerhalb einer generierten Seite, auf die ich außerhalb der Definition keinen Einfluss nehmen kann.

Ralf

[Cheatah]

Hi,

Für eine "saubere" Struktur muss natürlich ebenfalls der DOM-Zugriff einfach möglich sein.

es ist möglich, einen String so zu verwenden, dass dessen Inhalt anschließend als DOM-(Teil-)Baum zur Verfügung steht (einen hierfür geeigneten Inhalt natürlich vorausgesetzt). Dadurch bedarf es keinerlei struktureller Änderungen; Du hast einfach ein XML zunächst innerhalb des JavaScript-Codes vorliegen.

Als Alternative sei noch AJAX genannt.

Auf die Frage bin ich gekommen, weil mir bei anderer Gelegenheit Definitionen mit DL/DT/DD aufegfallen sind und vielleicht kann ich das auch sinnvoll verwenden?

Hm, ja, bedingt. Du kannst die Elementnamen jeweils in ein <dt> verpacken und die Attributnamen und -werte anschließend als <dd class="name">value</dd> strukturieren. Das sieht mir aber eher nach einem Rückschritt aus.

Cheatah

[Ralf]

Hallo,

es ist möglich, einen String so zu verwenden, dass dessen Inhalt anschließend als DOM-(Teil-)Baum zur Verfügung steht (einen hierfür geeigneten Inhalt natürlich vorausgesetzt). Dadurch bedarf es keinerlei struktureller Änderungen; Du hast einfach ein XML zunächst innerhalb des JavaScript-Codes vorliegen.

Du meinst so etwas wie JSON? Das würde zwar den Zugriff ggf. vereinfachen, aber die Definition verkomplizieren. Und letztere wird von unbedarften Anwendern vorgenommen, die damit sicherlich überfordert wären. Daher auch die bisher von mir gewählte "flache" Struktur.

Als Alternative sei noch AJAX genannt.

Ich sehe nicht, was mir das in diesem Zusammenhang bringen könnte. Die Daten liegen bereits in der vom Server gelieferten Seite vor. Es geht lediglich um den Zugriff innerhalb dieser Seite (auch der Javascript Code liegt darin bzw. wird von da aus aufgerufen).

Auf die Frage bin ich gekommen, weil mir bei anderer Gelegenheit Definitionen mit DL/DT/DD aufegfallen sind und vielleicht kann ich das auch sinnvoll verwenden?

Hm, ja, bedingt. Du kannst die Elementnamen jeweils in ein <dt> verpacken und die Attributnamen und -werte anschließend als <dd class="name">value</dd> strukturieren. Das sieht mir aber eher nach einem Rückschritt aus.

Nicht unbedingt. Ich war bisher noch nicht auf die Idee gekommen, zu einem <dt> mehrere <dd> zu definieren. Über das class-Attribut hatte ich zwar nachgedacht, aber eher bei <dl>. Ich bin aber eher geneigt, dafür das title-Attribut zu verwenden.

Wenn ich deine Anregung weiter verfolge, käme ich auf folgende Definition:

  
<dl>  
  <dt>REPORT</dt>  
  <dd title="typ">TABELLE</dd>  
  <dd title="from">ARTIKEL</dd>  
  <dt>SPALTE</dt>  
  <dd title="header">Packliste</dd>  
  <dd title="table">border=2 cellspacing=0 cellpadding=5</dd>  
  <dd title="format=">font:10pt ...</dd>  
  <dt>SPALTE</dt>  
  <dd ...  
  ... </dd>  
  <dt>DETAIL</dt>  
  ...  
  <dt>SUMME</dt>  
  ...  
  <dt>GESAMT</dt>  
  ...  
</dl>  

Gefällt mir gar nicht mal schlecht und sollte auch für einen Laien kaum schwerer zu definieren sein als meine bisherige Lösung.
Durch die Einfassung mit <dl> entfällt die Notwendigkeit des Bezugs bei den Einzeldefinitionen zum REPORT.
Zwar ist das auch eine "flache" Definition, aber valide und per DOM sogar einfacher im Zugriff als meine bisherige Definition.
Auf jeden Fall bräuchte ich die Struktur der Verarbeitungsroutinen nicht großartig umzustellen.

Vielleicht hat aber noch jemand eine bessere Idee?

Ralf

[Cheatah]

Hi,

es ist möglich, einen String so zu verwenden, dass dessen Inhalt anschließend als DOM-(Teil-)Baum zur Verfügung steht (einen hierfür geeigneten Inhalt natürlich vorausgesetzt). Dadurch bedarf es keinerlei struktureller Änderungen; Du hast einfach ein XML zunächst innerhalb des JavaScript-Codes vorliegen.
Du meinst so etwas wie JSON?

nein, ich meine exakt den XML-Code, den Du bereits verwendest. Nur halt zunächst als String verpackt.

Als Alternative sei noch AJAX genannt.
Ich sehe nicht, was mir das in diesem Zusammenhang bringen könnte.

Nun, Du kannst ein XML erhalten, wenn auch auf einem etwas umständlichen Weg.

Ich bin aber eher geneigt, dafür das title-Attribut zu verwenden.

"This attribute offers advisory information about the element for which it is set."

Ich weiß nicht, eine Klassifizierung finde ich da doch passender, um einen Attributnamen zu simulieren (gewissermaßen). Aber wie gesagt, ich bin der Ansicht, Du kannst mit dem XML weiterarbeiten, welches Du bereits einsetzt. Du musst es nur anders verpacken.

Cheatah

[Ralf]

Hallo,

es ist möglich, einen String so zu verwenden, dass dessen Inhalt anschließend als DOM-(Teil-)Baum zur Verfügung steht (einen hierfür geeigneten Inhalt natürlich vorausgesetzt). Dadurch bedarf es keinerlei struktureller Änderungen; Du hast einfach ein XML zunächst innerhalb des JavaScript-Codes vorliegen.
Du meinst so etwas wie JSON?

nein, ich meine exakt den XML-Code, den Du bereits verwendest. Nur halt zunächst als String verpackt.

Dann verstehe ich es nicht. Kannst du mir mal ein Beispiel geben?

Als Alternative sei noch AJAX genannt.
Ich sehe nicht, was mir das in diesem Zusammenhang bringen könnte.

Nun, Du kannst ein XML erhalten, wenn auch auf einem etwas umständlichen Weg.

Da kann ich dir leider auch nicht folgen. Ist aber auch nicht so wichtig, weil ein Zugriff per AJAX ohnehin nicht möglich wäre. Wie erwähnt befinden sich Definitionen, auszuwertende Daten und Javascript Code in der gleichen Seite. Da muss nichts geladen werden.

Ich bin aber eher geneigt, dafür das title-Attribut zu verwenden.

"This attribute offers advisory information about the element for which it is set."

Ich weiß nicht, eine Klassifizierung finde ich da doch passender, um einen Attributnamen zu simulieren (gewissermaßen).

Grundsätzlich gebe ich dir da schon Recht. Für die Daten (die ich hier nicht erwähnt habe) würde ich vermutlich sogar id-Attribute mit angehängter Nummerierung wählen.

Aber wie gesagt, ich bin der Ansicht, Du kannst mit dem XML weiterarbeiten, welches Du bereits einsetzt. Du musst es nur anders verpacken.

Wenn ich es verstehe und die Verpackung so einfach ist, dass sie auch für einen unbedarften Anwender transparent ist (denn der erzeugt die Definition), wäre das vielleicht eine Lösung.

Ralf

[Cheatah]

Hi,

nein, ich meine exakt den XML-Code, den Du bereits verwendest. Nur halt zunächst als String verpackt.
Dann verstehe ich es nicht. Kannst du mir mal ein Beispiel geben?

ja, kann ich. Hui, das war ja 'ne leichte Frage ;-)

Okay, ernsthaft: Was ich meine ist, dass Du eine JavaScript-Variable in den Code schreibst, die als _Text_ den XML-Code enthält. Anschließend nutzt Du einen der vielfältigen Browser-Mechanismen, um aus einem Text einen DOM-Baum zu erzeugen. Und schwupps, schon hast Du exakt die Situation, in der Du sein möchtest, nur mit validem Code.

Als Alternative sei noch AJAX genannt.
Ich sehe nicht, was mir das in diesem Zusammenhang bringen könnte.
Nun, Du kannst ein XML erhalten, wenn auch auf einem etwas umständlichen Weg.
Da kann ich dir leider auch nicht folgen.

Selbes Prinzip wie oben, nur dass Du statt der String-Bearbeitung einen AJAX-Request machst. In beiden Fällen hast Du das XML lediglich aus dem Dokument-Baum woanders hin ausgelagert.

Wenn ich es verstehe und die Verpackung so einfach ist, dass sie auch für einen unbedarften Anwender transparent ist (denn der erzeugt die Definition), wäre das vielleicht eine Lösung.

Wenn Du den <script>-Block richtig erzeugst, muss der Anwender lediglich die Zeichenkette "]]>" vermeiden und das XML so erzeugen, wie Du es gerne hättest.

Cheatah

[Ralf]

Hallo,

ja, kann ich. Hui, das war ja 'ne leichte Frage ;-)

Wissen sie wie spät es ist? Ja!

Okay, ernsthaft: Was ich meine ist, dass Du eine JavaScript-Variable in den Code schreibst, die als _Text_ den XML-Code enthält. Anschließend nutzt Du einen der vielfältigen Browser-Mechanismen, um aus einem Text einen DOM-Baum zu erzeugen. Und schwupps, schon hast Du exakt die Situation, in der Du sein möchtest, nur mit validem Code.

Also müsste der Anwender etwas in der folgenden Art definieren:

  
<script type="text/javascript">  
var report = '  
<REPORT  
  id="packliste"  
  typ="TABELLE"  
  from="ARTIKEL"  
  ></REPORT>  
<TABELLE  
  report="packliste"  
  header="Packliste"  
  table="border=2 cellspacing=0 cellpadding=5"  
  format="font:10pt verdana;background-color:ThreeDLightShadow;"  
  ></TABELLE>  
<SPALTE  
  report="packliste"  
  header="Menge"  
  data="[[[Menge]]]"  
  sum="0"  
  format="text-align:right;"  
  ></SPALTE>  
<SPALTE  
  report="packliste"  
  header="Bezeichnung"  
  data="[[[Artikelbeschreibung]]]"  
  sort="A"  
  ></SPALTE>  
<DETAIL  
  report="packliste"  
  suppress="y"  
  format="background:#eeffee;"  
  alt="background:#ccffcc;"  
  ></DETAIL>  
<SUMME  
  report="packliste"  
  format="background:white;"  
  alt="background:InfoBackground;"  
  suppress=""  
  ></SUMME>  
<GESAMT  
  report="packliste"  
  format=""  
  suppress="Y"  
  ></GESAMT>  
';  
</script>  

Und wie komme ich dann zum DOM? Einfach per innerHTML irgendwo einhängen? Irgendwie stehe ich noch immer auf dem Schlauch :(

Selbes Prinzip wie oben, nur dass Du statt der String-Bearbeitung einen AJAX-Request machst. In beiden Fällen hast Du das XML lediglich aus dem Dokument-Baum woanders hin ausgelagert.

Wie schon erwähnt, ist da nichts auszulagern, weil alles in einem Dokument steht. Es gibt also keine Adresse für einen AJAX-Request.

Wenn Du den <script>-Block richtig erzeugst, muss der Anwender lediglich die Zeichenkette "]]>" vermeiden und das XML so erzeugen, wie Du es gerne hättest.

Selbst wenn der Anwender das hinbekommt, kann nicht ausgeschlossen werden, dass diese Zeichen in Variablen stehen, die vom Server für die Generierung der Daten verwendet werden.

Ralf

[Cheatah]

Hi,

ja, kann ich. Hui, das war ja 'ne leichte Frage ;-)
Wissen sie wie spät es ist? Ja!

"Wissen Sie, wie es zum Bahnhof geht?" :-)

Also müsste der Anwender etwas in der folgenden Art definieren:

Ja, etwas Ähnliches schwebte mir vor.

Und wie komme ich dann zum DOM? Einfach per innerHTML irgendwo einhängen? Irgendwie stehe ich noch immer auf dem Schlauch :(

Was passiert denn, wenn Du es per innerHTML irgendwo einhängst, im Vergleich zu der Methodik, den Code direkt ins HTML-Dokument zu schreiben?

Wenn Du den <script>-Block richtig erzeugst, muss der Anwender lediglich die Zeichenkette "]]>" vermeiden und das XML so erzeugen, wie Du es gerne hättest.
Selbst wenn der Anwender das hinbekommt, kann nicht ausgeschlossen werden, dass diese Zeichen in Variablen stehen, die vom Server für die Generierung der Daten verwendet werden.

Dann wird es ein ganz klein wenig schwieriger, weil ein Escaping notwendig ist. Allerdings kann der generierende Mechanismus dies übernehmen - bisher klang es für mich so, als würde ein Mensch direkt in den JavaScript-Code schreiben müssen.

Cheatah

[Ralf]

Hallo,

Was passiert denn, wenn Du es per innerHTML irgendwo einhängst, im Vergleich zu der Methodik, den Code direkt ins HTML-Dokument zu schreiben?

Das sollte gleichbedeutend sein. Dann habe ich mein Anliegen aber noch nicht richtig rüberbringen können. Mit "valide" meinte ich nicht zwangsläufig HTML, welches sich validieren lässt (der Server produziert da ohnehin Murks), sondern vielmehr eine Struktur aus gültigen HTML tags. Und leider verhalten sich die Browser durchaus unterschiedlich, wenn man ihnen etwas unterschiebt, was sie nicht kennen. Daher hat meine vorgegebene Definition auch keine hierarchische Struktur, sondern stellt die Verbindung über das report-Attribut her.
Mit gültigen tags hätte ich das Problem nicht.

Dann wird es ein ganz klein wenig schwieriger, weil ein Escaping notwendig ist. Allerdings kann der generierende Mechanismus dies übernehmen - bisher klang es für mich so, als würde ein Mensch direkt in den JavaScript-Code schreiben müssen.

Die Definitionen für die Auswertung (also mein Beispiel) kommen nach meiner Vorgabe vom Anwender. Die auszuwertenden Daten wurden bisher ähnlich festgelegt, werden aber vom Server generiert (ist jetzt schwer zu erklären). Jedenfalls können dabei prinzipiell beliebige Zeichenfolgen auftreten und die sind dann im Dokument drin. Eine Kapselung mit escape("...") wäre natürlich denkbar.

Irgendwie denke ich aber noch über eine vollständige HTML-Lösung nach, wobei ich auch dort das Problem bestimmter Zeichen hätte. Mir missfällt aber an der Lösung mit DL/DT/DD, dass ich dort nicht direkt auf Werte per getAttribute() zugreifen kann, sondern mich durch die Liste der <dd> tags hangeln muss. Vielleicht kann ich aber auch den Attributnamen als Teil des id-Attributes vom <dd> tag setzen und habe dann einen direkten Zugriff auf den Wert.

Vielleicht fällt mir ja noch eine HTML-Struktur ein, die den Daten besser entspricht.

Ralf

[wahsaga]

hi,

Es gibt in dieser Definition eine gewisse Hierarchie, welche durch Verwendung des report-Attributes hergestellt wird.
Definiert wird im Beispiel ein REPORT vom Typ TABELLE mit bestimmten Eigenschaften (SPALTE(n), DETAIL, SUMME GESAMT).

Welche anderen Typen wären neben TABELLE noch möglich?

Auf die Frage bin ich gekommen, weil mir bei anderer Gelegenheit Definitionen mit DL/DT/DD aufegfallen sind und vielleicht kann ich das auch sinnvoll verwenden?

Das kommt auf die Struktur der Daten an - auf alle Strukturen, die zu erwarten sind.

Wenn ja - wie sollte ich die Definition gem. obigem Beispiel strukturieren?

Dein Beispiel ist mir noch zu unaussagekräftig, um erkennen zu können, welche Daten wie zueinander in Verhältnis stehen.
Erst, wenn das klar definiert ist, könnte man überlegen, wie man das in HTML abbilden könnte.

Wenn nein - gibt es Alternativen?

XML schiene mir, ohne die kompletten Anforderungen deiner Datenstruktur zu kennen, vermutlich die bessere Wahl zu sein - wenn du das nicht ausschlissen würdest:

Um Fragen vorzubeugen: Es kommt ausschließlich HTML für die Definition in Frage und es handelt sich um ein Definition innerhalb einer generierten Seite, auf die ich außerhalb der Definition keinen Einfluss nehmen kann.

Wenn das Anwendungsgebiet beschränkt ist, bspw. auf IE im Intranet, würden sich evtl. XML Data Islands anbieten.

Ansonsten würde ich obiges Beispiel, welches ja wohl wirklich tabellarische Daten abbilden soll, in HTML auch wirklich als Tabelle umsetzen.

gruß,
wahsaga

[Ralf]

Hallo,

Welche anderen Typen wären neben TABELLE noch möglich?

Das ist noch offen. Jedenfalls hätten weitere Typen völlig andere Eigenschaften, die nichts mit dem Typ TABELLE zu tun hätten.

Das kommt auf die Struktur der Daten an - auf alle Strukturen, die zu erwarten sind.

Grundsätzlich geht es um Daten, die abhängig/hierarchisch definiert sind. Im obigen Beispiel gibt es also einen REPORT vom Typ TABELLE mit bestimmten Eigenschaften, die durch SPALTE etc. näher beschrieben sind.
Eine Erweiterung wäre z.B. ein REPORT vom Typ EXPORT, welcher dann eine Beschreibung für CSV-Daten enthalten würde (dort könnten dann natürlich auch wieder SPALTE(n) auftauchen).
Oder eine grafische Auswertung vom Typ GRAPH mit entsprechenden Definitionen für eine Darstellung (TITELX, TITLEY etc.)

Dein Beispiel ist mir noch zu unaussagekräftig, um erkennen zu können, welche Daten wie zueinander in Verhältnis stehen.
Erst, wenn das klar definiert ist, könnte man überlegen, wie man das in HTML abbilden könnte.

Die Sache ist noch in der Entwicklung und soll einfach zu erweitern sein. Der von mir angeführte Teil ist nur die Definition für eine Auswertung. Die Daten selbst liegen in ähnlicher Form vor (bzw. ich habe sie so strukturiert, um damit einfach per DOM zugreifen zu können).

XML schiene mir, ohne die kompletten Anforderungen deiner Datenstruktur zu kennen, vermutlich die bessere Wahl zu sein - wenn du das nicht ausschlissen würdest:

Ich will es mal so ausdrücken: Vom Server wird eine HTML-Seite geliefert und der BODY besteht aus DIV-Containern, deren Inhalt ich frei bestimmen kann.

Wenn das Anwendungsgebiet beschränkt ist, bspw. auf IE im Intranet, würden sich evtl. XML Data Islands anbieten.

Sagt mir nichts, aber es muss unabhängig vom Browser sein.

Ansonsten würde ich obiges Beispiel, welches ja wohl wirklich tabellarische Daten abbilden soll, in HTML auch wirklich als Tabelle umsetzen.

Vielleicht hätte ich noch erwähnen sollen, dass es nicht um die optische Darstellung geht (das steht alles in einem Container mit display:none), sondern allein um den möglichst einfachen Zugriff per Javascript.

Ralf