inEx - information explorer

Wissen + Projekt + Archiv  Management

Face the Age of Information



  Übersicht
 
   Letzte News
   Hinweis Homepage
 
   Screenshots
   Demo Videos
 
   Auf einen Blick

  2 - Konzepte
 
   Grundlagen
 
   Undo / Redo
   Edit Recorder
   Item-Info
   Die inEx-Datei
 
   Einträge
   Linken
   Clonen
   Icons
 
   Dateieinträge
   targetBox
   backupCopy
 
   Suche Funktionen
   Label Konzepte
   keyManager
   iSocExplorer
 
   Datenaustausch
   Download Funktion
   feedReader
   TLS (SSL)
 
   HTML Exporte
     
   Weitere Funktionen
   Zusätzliche Tools

  3 - Standard GUI
 
   treeView
   listView
   headTree
   Text-/Image-View
   Item-Info
 
   Auswahllogik
 
   iconBar
   iconManager
 
   targetBox
 
   Sucheeingabe
   Elementesuche
   Suchergebnisse
 
   hotNotes
   Tools
   Einstellungen

  4 - padWin GUI
 
   padWindow
   Auswahllogik
   padWin-Menü
 
   listMode
   iconMode
   imageMode
 
   historyBar
   imageBar
 
   MP3 Archive
   virtual DIR-Lists
 
   Einstellungen

  5 - Datei Support
 
   Dateieinträge
   File or DIR open
   File Rename / Del
   File Move / Copy
   pasteAsFile
 
   backupCopy
 
   MP3 File Support
   MP3 Play Lists
 
   Download Funktion
   feedReader
 
   Text File Support
   Image File Support
   virtual DIR-Lists
 
   inEx Datenbank
   inEx Dateien
   inEx Verzeichnisse

  6 - HTML Exporte
 
   Einfach und Flexibel
 
   treePage (easy)
   Options Dialog
   Page-Management
   keyPageSystem
 
   pageFab (universal)
   Fab Function
   Layout + Content
   Fab Clichés
   Fab Macros
   Fab Prozess
   Fab Komposition
   Fab Objekte
   HTML-Partikel
   Praxis-Beispiele
 
   Multi Page Fab
   Blog Fab

  7 - Diverses
 
   Workshop
   Reportlisten
   hotNotes memo
 
   Kassenfunktion
   Value Funktionen
 
   phoneCall
 
   Image Windows
   Image Collections
   SaveAs imageShow
   Image Shows
   Show Verzeichnisse
   Show Dialog
 
   imageMap
 
   colorPecker
   Vokabel Trainer



  Freeware Edition
 
   News
   Download
   Description

  Licence Edition
 
   Subscription Offer
   Delivery



.

video new mods language rss feed index
- Homepage -
 
(1) Übersicht   -   (2) Konzepte   -   (3) Standard GUI   -   (4) padWin GUI
(5) Datei Support   -   (6) HTML Exporte   -   (7) Diverses
(8) Freeware Edition / Licence Edition
 

Aktuelle Programmversion: Release 1.06.1 vom 16. November 2016



   HTML-Exporte

     
    Seitenindex siehe Menüleiste links
     .16.1208 updated




•  

HTML-Export - Einfach und Flexibel

Mit dem inEx-explorer sind HTML-Exporte in zwei verschiedenen Formen möglich. Mit der inEx treePage erfolgt der Export auf einfachste Weise per Knopfdruck. Die Darstellung (Layout) entspricht der Tree-Form der Einträge, und kann bei Bedarf in einer Vielzahl von Details variiert werden. HTML-Kenntnisse sind hierfür nicht erforderlich.

Die zweite Möglichkeit ist die inEx pageFab. Im Gegensatz zur treePage kann das Layout der Darstellung beliebig frei entwickelt werden. Für die Anwendung sind lediglich minimale Grundkenntnisse der HTML erforderlich. Durch das Konzept der pageFab-Makros und der Clichés ist die Anwendung sehr einfach und nach kurzer Einarbeitungszeit möglich.


index^
eng^




•  

Einfach und schnell: Der inEx treePage Export

Mit der inEx treePage-Funktion kann per Knopfdruck (Strg+5 oder im Menü Tools) eine HTML-Browser-Seite der aktuellen Liste im treeView erstellt werden. Spezielle Optionen können bei Bedarf im Optionen-Dialog^ individuell eingestellt, oder sonst einfach die Standard-Einstellungen verwendet werden.

Die Seitenproduktion kann mit oder ohne Eintrags-Icons, mit oder ohne Dot-Lines, und in einer entweder Nodes- oder flatNodes-Version erfolgen. In der Flat-Version werden alle Eintragslisten geöffnet dargestellt. In der Nodes-Version können die einzelnen Listen geöffnet und geschlossen werden (via JavaScript).

Die Zieldatei kann komplett erzeugt werden, oder der Inhalt in ein bestehendes Layout eingefügt werden (siehe: Seiten-Management^). Ist in der zu produzierenden Liste ein Datei-Eintrag (txFile) auf eine .html-Datei vorhanden, wird das erste derartige Vorkommen als Ziel im Speichern-Dialog übernommen (ab Version 1.04.0), und der Eintrag bei der Produktion ignoriert.

Einige weitere Beispiele:

•  Für MP3-Datei-Titel-Einträge existieren spezielle Optionen^.

•  Zwei- und dreiwertige Label (keys / TAGs) werden mit der Option Label Mode^ kursiv:: und kursiv-unterstrichen::: dargestellt, und die Doppelpunkte werden unterdrückt.

•  Mit dem keyPageSystem^ können key-Label (keys / TAGs) als "TAG-Buttons" produziert werden, die von den Produktions-Seiten zu dem key-Index-Seiten und von dort wieder zu den einzelnen Einträgen linken.


Unabhängig von den Optionen kann die Produktion eines Eintrags mit den ixTextMarker (ixTM) in verschiedener Weise modifiziert werden. Mit Start-Marker und End-Marker werden die gewünschten Textbereiche gekennzeichnet. Ein einzelner Marker beginnt und endet mit jeweils einem Space-Zeichen. Der End-Marker ist in allen Fällen " !/ ", kann aber zwei ("//") oder mehr "Closer"-Zeichen enthalten.

- Bold-Bereich: Start-Marker == " !b "
- Roter Text: Start-Marker == " !r "
- Größerer Text: Start-Marker == " !l " (l = larger)
- Zeilen-Umbruch: Einzel-Marker == " !c " (c = CR)
- InterNet-Link: Start-Marker == " !n " (n = 1,2,3 ...) - in der Eintrags-Liste enthaltene InterNet-Link-Einträge (txInterNet) werden in den Bereich eingebunden und bei der weiteren Produktion ignoriert. Die Zahl bestimmt die laufende Nummer der txInterNet-Eintrags-Vorkommen.

Hinweis: Die Erzeugung von Bold-Bereichen kann auch automatisch erfolgen mit der Option autoBold^ im Optionen-Dialog.

Für spezielle Zwecke ist der Einsatz von HTML-Partikel-Dateien^ möglich.

Die Grafiken der Open/Close-Schalter der Nodes können durch andere Varianten im Produktionsverzeichnis ersetzt werden (_bplus0.png / _bminus0.png).


Layout-Beispiele des treePage-Exports



Bild 1:  Ausschnitt aus einem treePage Export (inEx Demo-Blog^)



Bild 2:  Ausschnitt aus dem Export einer MP3-Sammlung



.16.0928 updated ("Einfach und schnell: Der inEx treePage Export")
link:
information-explorer.de/index_6export.html#tpage
index^
eng^




•  

Options Dialog (treePage)

Mit dem Optionen-Dialog kann eine Vielzahl einzelner Export-Optionen den eigenen Vorstellungen entsprechend eingestellt werden, wenn die Standard-Einstellungen nicht ausreichen. Der Dialog wird gestartet mit Shift+Strg+5 (oder im Menü Tools).




Bild 1:  Der treePage Dialog für die Export-Optionen


Die Einstellungen können bei Bedarf gespeichert werden, wenn das Markierungsfeld "save" markiert ist. Wurde eine bereits existierende Optionen-Datei erkannt und deren Einstellungen übernommen, werden dort die neuen Einstellungen gespeichert. Wenn eine Optionen-Datei neu erzeugt wird, wird diese in dem treeView an der aktuellen Position als Datei-Eintrag aufgenommen. Dieser Datei-Eintrag muß als erster Eintrag in der Liste platziert werden, die mit diesen Einstellungen produziert werden soll. Die Datei wird an ihrem Dateityp ".i2h.txt" erkannt. Dubletten dieses Eintrags können für weitere Listen verwendet werden, die in gleicher Weise produziert werden sollen. Sollen Änderungen nicht gespeichert werden, so muß das Markierungsfeld "copy" (dadurch erfolgt eine Kopie der Einstellungen in die Zwischenablage, die mit pasteAsFile als neue Optionen-Datei gespeichert als Variante verwendet oder erprobt werden kann) oder "use" markiert sein.

Zu der Option, die den Auswahl-Fokus hat, werden erklärende Informationen hinsichtlich der jeweiligen Alternativen angezeigt. Die aktuell gewählte Alternative ist durch einen fetten Font gekennzeichnet.

Mit dem Button View wird ein Auswahlfenster gezeigt, in dem eine der acht Grundversionen in einer Art Schnellauswahl gewählt werden kann, statt die entsprechenden drei Optionen einzeln wählen zu müssen.



Beschreibung der Optionen


- Page 1 - Production
- Page 2 - Layout
- Page 3 - Integration
- Page 4 - Macros



Page 1 - Production

...

•  Meta Date (HEAD TAG)
On/Off - ersetzt meta Date mit dem aktuellen Datum (<meta name="date" content="2015-12-31">). Die Ersetzung erfolgt aber nur, wenn keine xChange-Datei^ für metaDate für die Produktion vorhanden ist.


Page 2 - Layout

...


Page 3 - Integration

...


Page 4 - Macros

...

•  Label Mode
On/Off - Zwei- und dreiwertige Label (keys / TAGs) werden kursiv:: und kursiv-unterstrichen::: dargestellt, die Doppelpunkte werden unterdrückt.

•  MP3 Macro
On/Off - Formatierung der wesentlichen Bereiche in Bold-Font

•  MP3 Hide postMur
On/Off - Bereich nach Ranking-Label "mur...." nicht zeigen

•  keySelectors
Aktuell sind vier Selektor-Typen in Erprobung ("//=" für Parts (unique), "//#" für Index (unique), "//+" für Objekte (multiple) und "//*" für Quellen). Key-Selektoren stehen am Ende eines Eintrags, und kennzeichnen den Beginn zweitrangiger, sekundärer Schlüssel. Mit dieser Option können diese Bereiche bei der Seitenproduktion angezeigt oder abgeschnitten werden.

Beispiel:
Doc Watson  -  *.1923.0303 +.2012.0529  //= pers:: musician:: nc_usa:: nc_north_carolina:: watson_d:::

Hinweis: Außer dieser Option ist mit diesen Selector-Labeln bisher keine weitere Funktionalität verbunden. Darüber hinaus ist ihre Verwendung sinnvoll, da sie selbst als eine Art key verwendet werden können, um die Suche auf bestimmte Vorkommensarten einzuschränken. Zukünftig weitergehende Verwendung im Rahmen des Key-Managements ist denkbar.

•  TAG-Label
Keys als TAG-Label erzeugen: Mit der Version 1.06.0 wurde die erste (Beta-) Version des inEx keyPageSystem^ veröffentlicht. Die Optionen sind:
keyTags: (future property ! ) TAGs erzeugen (ohne keyPage-Links)
tagsAtTop: TAG-Line über dem String / TAGs an das String-Ende
tagsPosAuto: Bis 4 TAGs an das Ende, sonst atTop
keySys: keyPageSystem^ verwenden

•  autoBold
Die Funktion autoBold (ab Version 1.06.0) identifiziert bestimmte Text­bereiche als Start-Stop-Markierungen ("Struktur-Label") für den Bold-Bereich, und verwendet die folgenden Regeln, wenn ein String nicht bereits ixTextMarker^ enthält:

3space label:
- start = at string start if the string contains "   -   " OR "   //"
- stop = left side the label
2 or 1space label:
- start = a first "  -  " (two spaces) OR, if not exists, a first " - " (one spaces); start = right side the label
- stop = a second "  -  " OR "  //" (both two spaces) OR at string end

Hinweis, Stand Version 1.06.0: Diese Funktion wird gestört, wenn asymmetrische Label verwendet werden,
Beispiel: "<space><space>-<space>" oder ähnlich.

•  Data-ID
Die sogenannte inexID (ixi) dient im Datenaustausch der Identifizierung von Eintrags-Listen. Dieser Komplex ist aktuell in Erprobung und ixi-Einträge müssen z.Z. noch manuell erzeugt werden. Mit dieser Option können ixi-Einträge bei der Seitenproduktion integriert oder ignoriert werden.

Erläuterung (vorläufig):
Ein ixi-Eintrag beginnt mit der Kennung "ixi-#" und enthält IDs in der Form "#yy_mmdd_nnn". Es können mehrere IDs kombiniert werden (um Abhängigkeiten zu notieren), getrennt durch "-". IDs mit zwei "#" kennzeichnen einen unikaten Eintrag (Part oder Index) im Unterschied zu objektartigen Einträgen (multiple).
Beispiel:
ixi-#16_0228_012-##16_0228_003




Hinweis: Die Entwicklung der treePage Funktionen ist aktuell noch nicht abge­schlossen. Erweiterungen und Komplettierungen folgen, Detail­änder­ungen sind möglich.


.16.0928 updated ("Options Dialog (treePage)")
link:
information-explorer.de/index_6export.html#odlg
index^
eng^




•  

Seiten-Management

Hinweis: Die hier beschriebenen Erweiterungen sind verfügbar mit der Update-Version 1.04.0. Beispiele für diese Entwicklungen siehe den (experimentellen) ixDemo-Blog^ oder den (praktischen) THB-Blog^.


Es folgt eine Beschreibung für den Fall, wenn der Export nicht einfach mit dem Standard-Layout erfolgen, sondern ein mehrere Seiten umfassendes Projekt realisiert werden soll. In diesem Fall wird für alle Seiten der gleiche Seitenentwurf verwendet, und bei dem Export nur der dort mit CORE bezeichnete Bereich verändert. Hierfür sind zwei Dinge notwendig:

- Optionen-Dialog: Tab "Production", Complete = off
- Im Seiten-Entwurf müssen die Marken <!-- CORE --> und <!-- /CORE --> als jeweils eigene Zeile enthalten sein.


Für das Handling von Multi-Page-Projekten stehen folgenden Erweiterungen zur Verfügung:


- Produktions-Listen (t2hList)
- xChange-Datei (.xcg.txt)
- xChange-Listen (xcgList)
- ixDoc-Datei (.ixd.txt)





•  Produktions-Listen (t2hList)

In einer Produktions-Liste können Links auf Einträge gesetzt werden, die nacheinander mit einem einzigen treePage-Start (Strg+5, siehe Hauptmenü Tools&Views) nacheinander produziert werden. Hierfür muß die Produktions-Liste selektiert sein, und dann die treePage-Produktion gestartet werden.

In dem jeweils zu produzierenden Eintrag muß ein Datei-Eintrag (txFile) vorhanden sein, der als Ziel für die Produktion verwendet wird. Es wird der erste vorkommende txFile-Eintrag mit .html Kennung verwendet.

Hinweis: Zur Zeit sind in Produktions-Listen keine Links auf Produktions-Listen möglich.


Eintrags-Format einer Produktions-Liste

Die Liste muß vom (Icon-) Eintrags-Typ txSigma sein (siehe IconBar im Bereich der Raute) und die Kennung t2hList="aName" enthalten. Die Angabe aName ist beliebig und dient lediglich der Individualisierung des Eintrags selbst.


Abbildung: Beispiel eines Produktions-Listen-Eintrags




•  xChange-Datei (.xcg.txt)

Die xChange-Datei dient der Änderung der HTML-Datei (Design-Vorlage, siehe weiter unten ixDoc-Datei) im Bereich des durch die Produktion nicht betroffenen umgebenden Seitenbereichs nach Abschluss des core-updates. Ein Beispiel für deren Einsatz sind die Menü-Bereiche, die seitenabhängig variieren, oder bei der Design-Entwicklung, so daß nicht jedesmal alle Seiten manuell editiert werden müssen.

Der Änderungs-Prozess setzt sich zusammen aus einem Änderungs-Block in der HTML-Datei, und einer Änderungs-Datei (Datei-Kennung: .xcg.txt). Die Identifikation und Zuordnung erfolgt durch Schlüssel (Keys). Eine Änderungs-Datei wird in der zu produzierenden Liste als Datei-Eintrag angegeben, oder mit weiteren Änderungs-Dateien in Änderungs-Listen (s.u.) zusammengefasst, auf die in der zu produzierenden Liste ein Link gesetzt wird.

Der Änderungsbereich ist in der Design-Vorlage durch einen xChange-Schlüssel-Block definiert. Beispiel:


<!-- xcg=keyName -->
<!-- /xcg -->


Eine xChange-Datei enthält in der ersten Zeile die Schlüssel-Marke, und addressiert damit den entsprechenden Austausch-Bereich (Änderungs-Block):

<!-- xcg=keyName -->
...

gefolgt von dem Inhalt der in dem Block zwischen Anfangs- und Ende-Kennung der Design-Vorlage eingefügt bzw. ausgetauscht werden soll. Eine Ende-Kennung in der xChange-Datei ist nicht notwendig.

Beispiel einer xChange-Datei als Ausgangsbasis (Basis-Datei) für ein Menü, gültig für alle Seiten:

<!-- xcg=keyName -->
<a href="page1.html">Page1</a><br>
<a href="page2.html">Page2</a><br>

Auf der Seite 1 und 2 sollen später jeweils statt der Links lediglich der Seitenname vorkommen. Dazu erweitern wir zunächst diese Basis-Datei wie folgt um weitere Austausch-Blöcke:

<!-- xcg=keyName -->
<!-- xcg=p1key -->
<a href="page1.html">Page1</a><br>
<!-- /xcg -->
<!-- xcg=p2key -->
<a href="page2.html">Page2</a><br>
<!-- /xcg -->
<!-- /xcg -->

Diese Datei ersetzt dann in der Produktion zunächst den Bereich innerhalb der Design-Datei.

Für die beiden konkreten Seiten erzeugen wir entsprechende xChange-Dateien, in denen die jeweiligen Änderungen definiert sind:

<!-- xcg=p1key -->
<b>Page1</b><br>

und

<!-- xcg=p2key -->
<b>Page2</b><br>

In den beiden Listen, die produziert werden sollen, wird die jeweilige Datei als Eintrag referenziert (txFile-Eintag); (siehe aber auch xChange-Listen weiter unten):

Liste 1:

C:\....\pages.xcg.txt
C:\....\page1.xcg.txt

Liste 2:

C:\....\pages.xcg.txt
C:\....\page2.xcg.txt

Falls jetzt das Menü geändert / erweitert werden soll, wird lediglich die Basis-Datei geändert.


Hinweis: Die Registrierung der Schlüssel erfolgt durch die xChange-Datei(en). Schlüssel in der Vorlage, die nicht registriert wurden, werden nicht bearbeitet.




HTML HEAD-Tags

Weiterhin können mit Änderungs-Dateien HEAD-Tags geändert werden. Statt einer xcg-Marke und Ersetzungs-Inhalt enthält die xChange-Datei (nur) einen HEAD-Tag in der zu ersetzenden neuen Form. Bisher werden folgende HEAD-Tags unterstützt (in Orange = Erkennungs-Label):

<title>...</title>
<meta name="date" content="2015-12-31">
<meta name="description" content="...">

Hinweis zu metaDate: ist eine xChange-Datei für metaDate vorhanden, setzt dies die ggf. gesetzte Option metaDate des Optionen-Dialogs^ außer Kraft.


Hinweise:

- Die Position der .xcg.txt Datei-Einträge innerhalb einer Liste sind nicht relevant, jedoch deren Reihenfolge. Die Dateien werden in der Reihenfolge ihres Auftretens am Ende der Produktion ausgeführt.

- In der Zieldatei mehrfach vorkommende identische Schlüssel-Blöcke werden bearbeitet.

- Die Block-Marken müssen am Anfang einer Zeile stehen (keine führende Spaces etc)

- Nach dem Ende aller Austausch-Prozesse werden Sub-Schlüssel-Marken innerhalb eines Blocks entfernt.




•  xChange-Listen (xcgList)

In einer xcg-Liste können mehrere xcg-Datei-Einträge zusammengefasst werden. In den zu produzierenden Einträgen können xcg-Listen auch als Link eingebunden werden. Xcg-Listen können auch selbst Links auf xcg-Listen enthalten. Insgesamt ist auf die korrekte Reihenfolge (Ablauf der Änderungen) zu achten.


Eintrags-Format einer xcg-Liste

Die Liste muß vom (Icon-) Eintrags-Typ txSigma sein (siehe IconBar im Bereich der Raute) und die Kennung xcgList="aName" enthalten. Die Angabe aName ist beliebig und dient lediglich der Individualisierung des Eintrags selbst.


Abbildung: Beispiel eines xcg-Listen-Eintrags





•  ixDoc-Datei (.ixd.txt)

Mit Hilfe der ixDoc-Dateien können mit der treePage-Funktion Projekte realisiert werden, die aus mehreren Seiten bestehen und das gleiche Layout verwenden sollen.

Ist eine ixDoc-Datei als Eintrag (txFile) in einer xcgList (oder der zu produzierenden Liste) eingetragen, dann wird nicht die bereits vorhandene Zieldatei verwendet, sondern die Zieldatei wird unter Verwendung der ixDoc-Datei komplett neu erstellt. Bei Begin einer Produktion wird auf das Vorhandensein einer ixDoc-Datei geprüft und dann als erstes eventuell weitere vorhandene Einfügungen vorgenommen.

Für die komplette Neuerstellung enthält diese Datei den umgebenden <html>...</html> TAG. Hierin können mit dem Label ...

<!-- ixDoc="fullpath/FileName.ixd.txt" -->

... weitere, sekundäre ixDoc-Dateien aufgerufen und eingebunden werden, z. B. der <style>-TAG u.a.


Beispiel:

File: abc_page.ixd.txt

<!DOCTYPE HTML>
<html lang="de">
...
<!-- ixDoc="fullPath\abc_style.ixd.txt" -->
...
</html>



Hinweise:

- Das ixDoc-Label muss an dem Anfang einer Zeile stehen

- Nur in der zuerst geladenen ixDoc-Datei werden ixDoc-Label behandelt. In sekundären ixDoc-Dateien werden keine weiteren Einfügungen ausgeführt.

- Sekundäre ixDoc-Datei-Einträge (txFile) gehören nicht in die zu produzierende Liste bzw. xcgList.

- Als Option für die Produktion muß im Optionen-Dialog "Complete" = false gesetzt sein.



.16.0928 updated ("Seiten-Management")
link:
information-explorer.de/index_6export.html#mpm
index^
eng^




•  

keyPageSystem

ix_keypage::

Die Verwendung von Schlüssel(-worte) (keys / TAGs / Stichworte / Schlagworte) ist eine großartige und produktive Sache. Aber jenseits von mehr als 20...30 Schlüssel wird die Anwendung mehr und mehr unsicher, nebulös. Und die Anzahl möglicher Kombinationen, Alternativen und Ordnungs­variationen steigt rapide an.

Um hier den Überblick nicht zu verlieren, wird ein Key-Management benötigt, das in einfacher Weise die gesamte Schlüsselverwendung überschaubar machen kann. Dies gilt umso mehr, je kontrollierter die Verwendung der Schlüssel sein soll (Stichworte => Schlagworte => Kategoriensystem*).


Der inEx-explorer bietet neben dem keyManager^ mit dem keyPage-System im Rahmen des HTML-Exports eine alternative oder auch ergänzende Möglichkeit, und bietet - gegenüber dem aktuellen Entwicklungstand des keyManagers - zunächst die bessere Übersichtlichkeit.

Die keyPages bieten eine von InterNet-Verbindungen server-unabhängige lokale oder auch publizierbare "solid-state" Lösung. Ein Beispiel dafür ist der experimentelle inEx-Blog^, in dem aktuell ein kategoriales Schlüssel-System entwickelt wird, und Quelle für Anregungen sein kann.


KeyPages erzeugen

Um keyPages zu erzeugen, im Optionen-Dialog^ auf der Tafel "Macros" die Option "keySys" aktivieren. Wird die Produktion einer Seite gestartet, und ist noch kein keySystem vorhanden, wird mit einem Dialog die Position des keySys-Verzeichnisses ausgewählt, das sich auf der Ebene des Produktions-Verzeichnis oder im höheren Teil des Pfades befinden muß.

Bei der ersten Produktion wird in diesem Verzeichnis die Vorlagen-Datei __ix_keytemplate.html erzeugt, die bei Bedarf editiert werden kann, um im Anfangs- und/oder Endbereich Ergänzungen einzufügen.

Am Ende einer Produktion wird abgefragt, ob das keySystem finalisiert werden soll. Die Finalisierung aktualisiert in allen Key-Seiten die Gesamtübersicht aller Schlüssel sowie die seiten-lokalen Links (Register-Links) und löscht in den Key-Seiten nicht mehr aktuelle Notierungen (validate). Werden mehrere Seiten produziert, ist eine Finalisierung nur am Ende notwendig.


Status der keySys-Version

Mit der Version 1.06.1 wird der folgende Teil (1) als ausgereift, und der Teil (2) als noch Beta eingestuft.

1) Wird das keySystem komplett neu erzeugt (nach "Delete keyPages", siehe Hauptmenu "Tools") sollten keine Fehler mehr auftreten.

2) Werden (Quell-) Seiten nach Änderungen neu produziert, könnten Key-Seiten eventuell Fehler enthalten. Diese Einschätzung wird auf Grund der Komplexität der möglichen Situationen getroffen. In praktischer Anwendung sind bisher keine Fehler mehr aufgetreten.

Die Option keyTags, mit der in den Produktionsseiten TAG-Buttons auch ohne ein keySystem und entsprechenden Links erzeugt werden könnnen, ist vorerst noch nicht realisiert.


Variationen

Mit der Option tagsAtTop können die TAG-Buttons vor oder im Anschluss des Textes eines Eintrags dargestellt werden. Mit der Option tagsPosAuto werden mehr als vier TAG-Buttons vor, und wenn weniger, im Anschluss des Textes dargestellt.



Abbildung: Original Eintrag in der Produktionsliste


Abbildung: TAG-Buttons a) nach Text, b) mit Option tagsPosAuto
Die Produktion erfolgte mit der Option autoBold^

Die Darstellung der TAG-Buttons kann in der CSS-Dekla­ration (.tag, .tag2) der Vorlagen-Datei^ (oder der Basis-Datei bei Produktion mit Option Complete= false) beliebig geändert werden, die Farbe, oder ohne Farbe, bold, italic, etc.


Beispiel für eine alternative CSS Deklaration



Abbildung: Alternative TAG-Version

.tag { font-size:0.9em; color:#777; background:#E0EDEB; border:1px solid #D3E4DF; border-radius:3px; line-height:200%; padding:1px; padding-left:3px; padding-right:3px;}

.tag2 { font-size:0.9em; color:#777; background:#FAEAE2; border:1px solid #F3D2C0; border-radius:3px; line-height:200%; padding:1px; padding-left:3px; padding-right:3px;}



Die keyPages

Am Beginn einer keyPage steht - nach einem ggf. in die Vorlage eingefügten Titel - die Gesamtübersicht aller Schlüssel, die durch die Finalisierung aktualisiert wird. Die Notierungen sind in zwei verschiedenen Bereichen vorhanden, zuerst der alpha-numerisch, top-down sortierte Teil der Einträge, und dann der nach den Schlüsseln sortierte Teil (key sorted).




Abbildung: Ausschnitt Kopfbereich einer keyPage,
die Gesamtübersicht der Schlüssel (siehe Original^)

Im zweiten Teil sind 2-key und 3-key Links und Ziele enthalten (Register-Links), die nicht nur dem schnelleren Auffinden dienen, sondern auch recht nützlich für das Key-Management konzeptioneller Kategorien sind, denn sie geben - insbesondere die 3-key Links - Aufschluss über die verwendeten Kombinationen und Hierarchien.


ixKm pop-up2

Abbildung: Ausschnitt keyPage WP (Wikipedia) zeigt
die 2-key und 3-key Seiten-Indexe (siehe Original^)

Hinweis: Der in der Abbildung sichtbare WP-Eintrag enthält im Original zwei WP-Links und hat die Form:

WP::  -  Areva   /// Wikipedia  (en) + (de)  // bus:: nc_france:: energy:: nuclear::


Tips und Tricks

Wie in der vorherigen Abblidung zu sehen ist, verwende ich Wikipedia-Einträge um damit eine Art Stichwort-Register zu bilden, ohne damit das keySystem aufzublähen, und gleichzeitig wird auch noch durch die Option tiefergehender Recherche die Informations-Dichte in den einzelnen Fällen erhöht. Wikipedia-Einträge (als Links oder Dubletten) als Childs in Listen fungieren wie eine Stichwort-Notierung zu dem Listen-Eintrag.

Die Übersichtlichkeit in der sortierten Gesamt-Übersicht der Schlüssel kann verbessert werden, wenn für spezielle Kategorien besondere Formulierungen der Schlüssel verwendet werden. In dem oben bereits genannten Experimental-Blog verwende ich für Länder-Angaben den Prefix "nc_" (nc = name space "Country", "nc_usa", ...), für Media-Typen "md_" ("md_video", ...). Weitere Beispiel sind zu finden in dem News-Blog zu meiner privaten Musik Anthologie "theHyperBox.de".

Welche Art der Indexierung gewählt wird, hängt von der jeweiligen Aufgabenstellung ab. Zu Begin einer Indexierung sollte zunächst eine Menge von Fällen bearbeitet werden, um ein Gefühl für den "Space" des Bereiches zu bekommen. Mit dem inEx-explorer ist es einfach, das "keySystem" im Laufe der Zeit immer weiter zu optimieren. Zumal mit Ockham als geistigen Begleiter.


.16.1208 updated ("keyPageSystem")
link:
information-explorer.de/index_6export.html#keysys
index^
eng^




•  

Flexibel und schnell: Die inEx pageFab

Die inEx pageFab ermöglicht im Unterschied zur inEx treePage den Export definierbarer Daten von inEx-Einträgen in ein beliebiges HTML-Layout.

Das Konzept der inEx pageFab trennt die beiden Bereiche Seitenlayout einerseits und Content (Inhalte) andererseits. Daraus resultieren entscheidende Vorteile. In HTML-Editoren sind alle Inhalte ungetrennt mit dem jeweiligen Layout verbunden. Mit CSS können hier zwar Details mit globaler Auswirkung variiert werden, aber wenn es sich um substantielle Änderungen im Layout handelt, müssen alle einzelnen Inhalte-Vorkommen bearbeitet werden. In der inEx pageFab dagegen wird das Layout durch einzelne Cliché-Teile (Vorlagen) bestimmt, und Änderungen an einem Cliché wirken sich bei einer erneuten Produktion logischerweise auf alle davon betroffenen Inhalte aus.

Um mit der inEx pageFab arbeiten zu können, sind lediglich minimale Kenntnisse der HTML-Sprache(*) notwendig. Layout-Entwürfe werden mit einem HTML-Editor(*) erstellt, und dann in Teile (Clichés) zerschnitten, entprechend der gewünschten Daten-Exporte. Eine erste fertige Produktion kann auf korrekte HTML-Codierung beim W3C(*) getestet werden.

*) Zur HTML-Sprache siehe Self-HTML^^, HTML-Editor siehe z. B. Kompozer^^, HTML-Validierung via W3C-Validator^^


Entwickelte sogenannte pageFab-Kompositionen können anderen inEx-Anwendern zur Nutzung und Weiterentwicklung zur Verfügung gestellt werden. Dies können auch Teil-Lösungen für spezielle Aufgaben sein, die dann in anderen Entwürfen integriert werden können.

Als in der Praxis besonders produktiv ist die Möglichkeit sein, in einer Grundorganisation von Seiten, Kapiteln und Artikeln, in jeweils einzelnen Dateien Inhalte-Teile (HTML-Partikel^) isoliert zu erstellen und zu entwickeln, die dann in der Seitenproduktion per Knopfdruck automatisch integriert sind. Handelt es sich dabei um die Beschreibung und Dokumentation eines Projektes, das in der gleichen inEx-Datei gemanaged wird, ergibt sich mit den Vernetzungsmöglichkeiten ein ganzheitlicher und völlig transparenter Zusammenhang von Planung, Entwicklung, Realisationen und Dokumentationen.

Ein Beispiel für die Möglichkeiten der pageFab ist diese inEx-Homepage, deren Seiten damit erstellt werden. Neuerungen oder Änderungen werden während der Programmierung zeitgleich in den entsprechenden Artikel-Dateien beschrieben, auf die in den jeweiligen Arbeits-Einträgen dann auch als Referenz gelinkt wird. Der nächste Seiten-Update per Knopfdruck ist damit automatisch immer aktuell.

Die pageFab-Kompositionen für die folgend abgebildeten Beispiele einer MP3-Datenbank, sowie der einfache Grundentwurf einer Homepage sind in der Starter-Datenbank enthalten (suche dort: "pageFab::"), und können den eigenen Wünschen entsprechend angepaßt werden. Weiterhin sind dort Teillösungen vorhanden, die in einer Art HTML-Baukasten für die Entwicklung eigener Layouts und Strukturen verwendet werden können.



Layout-Beispiel einer MP3-Datenbank




Bild 1:  Ausschnitt aus einer pageFab Produktion


Bild 2:  Ausgangsdaten für die pageFab Produktion der vorherigen Abbildung




Beispiel 2: eine MP3-Ranking-Liste



Bild 3:  Ausschnitt aus einer Ranking-Listen-Produktion


Die MP3-Einträge der Ranking-Listen in inEx sind lediglich Links auf die Original-Einträge in den Musiker-Index-Listen. Die Daten (MP3-Datei und Cover-Image) werden aus den Original-Einträgen übernommen.



Die in den Abbildungen gezeigte MP3-Datenbank ist ^hier online und enthält statt der Datei-Links Links zur Google-Suchmaschine.





Hinweis: Die pageFab ist der aktuelle Schwerpunkt der Beta-Entwicklung. Die Beschreibungen hier sind folgedessen vorläufiger Natur und unvollständig.


index^
eng^




•  

Wie funktioniert die inEx pageFab?

In einem entwickelten Layout werden die einzelnen inEx-Einträge mit Hilfe der sogenannten HTML-Clichés eingefügt. Das Cliché ist Teil einer Makro-Definition in welcher weitere Angaben existieren, z.B. für welche Eintrags-Typen das Makro angewendet werden soll, und welche Eintrags-Inhalte dann auf welche Weise in den Output übertragen werden.

Die Makro-Definition ist ein spezieller inEx-Eintrag, und in der Regel enthält dieser als Unter-Eintrag eine Datei-Referenz, in dessen Datei das zuständige Cliché enthalten ist. Eine Makro-Definition enthält im wesentlichen die drei Angaben Makro-Name, Input-Quellen (sources) und Output-Prozesse (objects).

In dem folgenden Beispiel wird als Input-Quelle (sources) der Pseudo-Typ txDefault verwendet, der alle Eintrags-Typen behandelt (ausschließlich jene, für die eigene Makros angegeben sind) und als Output-Prozesse (objects) sind hier das Eintrags-Icon (txIcon) und der Eintrags-Text (content) angegeben.

 Default-Makro-Definition:


  pf_md="xyz_default" sources= "txDefault" objects="txIcon, content"


Dieses Makro produziert alle Einträge, indem das Cliché des Makro verwendet (kopiert) wird, dort die zwei Ersetzungs-Marken IX_REPLACE mit der Datei-Adresse des Eintrags-Icon und dem Eintrags-Text ersetzt werden, und dann der sich entwickelnden Produktions-Liste angefügt wird.

 Das Cliché des Default-Makro:


<tr>
 <td><img style="width: 16px; height: 16px;" alt="" src=" IX_REPLACE"></td>
 <td> IX_REPLACE</td>
</tr>


Dies ist das einfache Grundprinzip der inEx pageFab. In Verbindung mit dem childsFrame-Makro, das dafür sorgt, daß alle Untereinträge eines jeweiligen Eintrags behandelt werden, und einer Reihe von speziellen Output-Prozessen ("Objekte"), können die Daten der inEx-Einträge gezielt und in variantenreicher Weise "per Knopdruck" als HTML-Seiten exportiert werden.


Varianten-Beispiel

Im folgenden ein Beispiel, wie ein Bild angezeigt wird, das als Dateireferenz als Sub-Eintrag im aktuellen Produktions-Eintrag (vom Typ txImage) enthalten ist, aber das Eintrags-Icon und der Eintrags-Content dabei verborgen bleiben sollen (durch die fehlenden Objekte txIcon und content):

 imagePure-Makro-Definition:


  pf_md="xyz_imagePur" sources="txImage"
objects= "ob_child_firstImageFileName"



 Das Cliché des imagePure-Makro:


<tr>
 <td></td>
 <td><img alt="" src=" IX_REPLACE"></td>
</tr>
 




index^
eng^




•  

Layout und Content

Die Erstellung von InterNet-Seiten teilt sich grundsätzlich auf in die zwei Bereiche der Entwicklung eines Grundkonzeptes (Design und Layout) einerseits, sowie der Erstellung des Contents, also des Inhaltes andererseits.

Sowohl das Seiten-Layout, wie auch das Layout der einzelnen darzustellenden Inhalte werden einmalig definiert, und dann bei der Realisation ggf. wiederholt angewendet (Fab-Tree). Die Content-Teile dagegen sind vielfach (Produktions-Tree) und werden den jeweiligen Inhalte-Layouts mit den  pageFab-Macros^ des Fab-Trees zugeordnet.

Das Layout wird mit einem HTML-Editor entwickelt. Der resultierende HTML-Code(*) wird dann in einzelne Clichés^ (Vorlagen) für die pageFab-Macros zerschnitten und separat gespeichert (Dateikennung .html.txt). Die Inhalte-Teile (Produktions-Tree) existieren als inEx-Einträge und ggf. auch als dort durch Dateieinträge referenzierte HTML-Partikel^ (HTML-Teile) in einzelnen Dateien (ebenfalls Dateikennung .html.txt).

*) Der HTML-Editor Kompozer z.B. bietet unter "Dateien/ Als Text exportieren" eine Funktion, die einen übersichtlich formatierten HTML-Code erzeugt.



index^
eng^




•  

Beispiel einer Cliché-Zerlegung

Eine HTML-Datei (Entwurf) kann in beliebiger Weise in Clichés zerlegt werden, und wird dann durch den Produktions-Prozess entsprechend den vorhandenen inEx-Einträgen wieder zusammengefügt.

Im folgenden Beispiel ist der gesamte variable Teil in einer Tabellen-Zeile(<tr>...</tr>) enthalten. In der ersten Spalte(<td>...</td>) ist ein vertikales Menü vorgesehen, in der zweiten ein horizontales Menü, und dann folgen repetativ die eigentlichen Content-Einträge.

Die Zerlegung erfolgt am besten so, daß sie sich (falls möglich) an den einzelnen öffnenden und schließenden HTML-Tags orientiert. Hilfreich für die Zerlegung wie auch zur besseren Orientierung bei weiteren Entwicklungen ist die Einfügung von Start- und End-Marken in Form von HTML-Kommentaren im Entwurf, mit denen die Cliché-Anfänge und -Enden markiert werden (z.B. <!-- xyz_p1 --> ... <!-- /xyz_p1 -->).

Die einfachste Vorgehensweise ist eine schrittweise Zerlegung "von innen nach außen" mit jeweils entsprechenden Tests. So würde in dem folgenden Beispiel zunächst der innerste Teil entwickelt und getestet. Das Cliché des Start-Macros enthält dabei zunächst noch den gesamten umgebenden Inhalt und wird dann Schritt für Schritt in die weiteren Teile zerlegt.


<!DOCTYPE ....
...
<tr>
<td>
...
</td>
<td>

<...>
...
</...>

<...>
...
</...>

...
</td>
</tr>
...
</html>


Legende:

HTML-Rahmen Clichè der Datei mit den konstanten Inhalten
Vertikal Menu Clichè des vertikalen Menüs
Content Cliché-Rahmen der zu produzierenden Inhalte
Horizontal Menu Cliché des horizontalen Menüs
Content-Items Cliché(s) einer oder mehrerer Inhalte-Varianten


index^
eng^




•  

pageFab Macros

Welcher Content (inEx-Einträge im Produktions-Tree) nun welchen Layout-Teilen (Clichés im Fab-Tree) zugeordnet wird, das wird mit den pageFab-Macros definiert. Ein pageFab-Macro hat die Aufgabe drei Aspekte zu verbinden:

- welches Cliché soll verwendet werden? (= Cliché-Datei)
- welche Eintrags-Typen sollen das Cliché verwenden? (= Sources)
- welcher Inhalt der Source wird eingefügt? (= Objects)


Ein pageFab-Prozess setzt sich also aus den folgenden Teilen zusammen:

- den Clichés (Cliché-Dateien)
- den inEx-Einträgen (Sources),
- den Fab-Objekten (Objects),

- und den Fab-Macros, die diese drei Elemente verbinden


Wie zu erkennen ist, ist das Fab-Macro das Element, das alle anderen verbindet, und ist letztlich das einzige Grundelement, aus denen ein pageFab-Prozess zusammengesetzt ist und dessen Ablauf steuert.

Ein pageFab-Macro ist ein inEx-Eintrag mit dem Icon-Typ txSigma, und beginnt mit dem Label "pf_md=", ein Kürzel, das für "pageFab macroDefinition" steht. Als Angabe folgt hier ein Macro-Bezeichner (Macro-Name), der innerhalb eines pageFab-Prozess einmalig sein muß. Weitere Angaben sind notwendig für sources und (mit Ausnahmen) für objects.

Das Cliché eines Macros befindet sich im Macro-Eintrag als Datei-Eintrag an erster Child-Position (Ausnahme siehe z.B. Childs-Macro^, oder wenn das Cliché lediglich eine Ersetzungs-Marke enthalten würde).


Macro-Definitions-Eintrag:


  pf_md="..." sources="..." objects="..."  [key="..."]


pf_md="macroName"  (z.B. "xyz_root", "xyz_vmenu" etc.)

sources="txType[, ...]"  (zugeordnete Eintrags-Typen)

objects="objectName[, ...][macroName[, ...]]"  (Objekte)



Bei den Typ-Bezeichnern in sources wird unterschieden zwischen Original- und Link-Einträgen. Bei Link-Einträgen wird dem Bezeichner ein "L" vorangesetzt (Beispiel: mit sources="txMusicGreen, LtxMusicGreen" werden sowohl Original- als auch Link-Einträge durch das Makro produziert).

Die Bezeichner für die von der pageFab für sources unterstützten Eintrags-Typen (txType) sind in der integrierten inEx-Hilfe notiert. Eine entsprechende Liste ergibt sich durch die Suche nach dem Label "txID:". In den Einträgen ist nach diesem Label der jeweilige Typen-Name angegeben (z.B. "txMusicGreen"). (Hinweis zur BETA-Version: aktuell sind noch nicht alle inEx Eintrags-Typen auf diese Weise gekennzeichnet und nutzbar)

Mit den Eintrags-Objekten^ in objects wird angegeben, welche Inhalte des Eintrags produziert werden sollen. Nur im Sonderfall des Childs-Macro (s.u.) können hier auch Macronamen angegeben werden.

Bei Bedarf kann als zusätzliche Bedingung zutreffender Einträge die optionale Angabe "key=" verwendet werden.

key="ID-String"   (ID-String ist eine beliebige Zeichenkombination, die im Eintrag vorkommen muß, wenn er produziert werden soll)

Existieren auf gleicher Hierarchie-Ebene des Makro-Tree hierdurch zwei (oder mehr) Macros für den gleichen Eintrags-Typ, dann ist das Macro ohne Key-Bedingung nach dem (letzten) Macro mit Key-Angabe anzuordnen, damit eine Key-Prüfung zuerst erfolgen kann.


index^
eng^




•  

pageFab Prozess

Ein pageFab-Prozess bzw. eine pageFab-Komposition besteht aus einem einleitenden Fab-Macro (Start-Macro), dem wurzelartig weitere Fab-Macros untergeordnet sind (der "Fab-Tree"). Die Makros werden im folgenden als Makro-Einträge bezeichnet.

Die zu produzierenden Einträge werden im folgenden als Produktions-Einträge bezeichnet, und befinden sich in einem eigenen Tree, dem "Produktions-Tree". Um einen Produktions-Tree mit einem Fab-Prozess zu verbinden wird am Anfang des Produktions-Tree ein Link auf den Fab-Tree gesetzt.

Die Page-Produktion wird mit der F9-Taste gestartet (oder im Menü Tools), wenn der aktuell selektierte Eintrag einen solchen Link auf einen Fab-Tree als Sub-Eintrag (Child) enthält. Mit Strg+F9 werden auch alle nachfolgenden Einträge produziert.

Die Produktion kann in die Zwischenablage oder als Datei gespeichert werden. Ist keine Zieldatei angegeben, dann ist das Ziel die Zwischenablage. Um eine Zieldatei anzugeben, wird in der zu produzierenden Liste ein pf_target-Eintrag (Typ txSigma) eingefügt, in dem wiederum ein Datei-Eintrag an 1. Position enthalten sein kann, der die Zieldatei benennt.

Die angegebene Zieldatei wird in dem prozess-internen Value-Label .targetFile notiert, und kann z.B. für Case-Entscheidungen verwendet werden.


 pf_target-Eintrag:


 pf_target="..." report="..." [optionen]


pf_target="targetIDName"  (z.B. "xyz_target", "xyz_targ_abc")

report="true[false]"

optional: imgFolder="subfolder" (z. B. "images")
optional: comments="true[false]"
optional: spaces="true[false]"
optional: validate="true[false]"
optional: repairIX_="true[false]"


Der targetIDName dient der Individualisierung des Eintrags. Die Angabe zu report kann "true" oder "false" sein. Hiermit wird der Produktions-Report ein- bzw. ausgeschaltet. Der Produktions-Report ist hilfreich um Fehlermeldungen im Produktionsprozess zu lokalisieren, oder Deklarations-Fehler zu finden.

Die weiteren Angaben sind optional: Ist comments false, werden HTML-Kommentare entfernt; ist spaces false, werden zeilenführende Leerzeichen entfernt. HINWEIS: Diese beiden Optionen sind in der aktuellen Version noch nicht enthalten. validate sucht nach unersetzten Referenz-Marken. repairIX_ entfernt ein nach IX_folgendes Leerzeichen in Prozessmarken, das in beschreibenden HTML-Partikel-Texten eingefügt wurde, damit diese nicht selbst Teil des Prozesses werden.



Der Fab-Prozesses beginnt mit dem

- Start-Macro, dann folgt das erste

- Childs-Macro, wodurch die einzelnen

- Content-Macros ausgeführt werden. Bei Bedarf zum Schluß die

- Referenz-Macros





1.) Start-Macro

Das erste Macro des Prozesses enthält den Eintrag einer Cliché-Datei, in der der HTML-Datei-Rahmen, also von <!DOCTYPE html ... bis </html >, sowie alle konstanten Inhalte im weiteren Anfangs- und Endbereich der Seite gespeichert sind, die vor und nach außerhalb des varianten Produktionsbereiches liegen.


An der Position in dem Cliché, ab der die Inhalte produziert werden sollen, steht in einem einzeiligen HTML-Kommentar eine pageFab-macroMarke ("PF_M=") mit der Angabe eines Childs-Macro, das hier die weitere Produktion so lange übernehmen soll, wie Einträge in der zu produzierenden Liste vorhanden sind. Wurde für das Start-Macro beispielsweise der Name "xyz_root" gewählt, empfiehlt sich für das folgende Childs-Macro der Name "xyz_root_childs".


Beispiel einer macroMarke im Cliché:

<!-- PF_M="xyz_root_childs" -->


Macros, die durch eine macroMarke für die Produktion verlangt werden (oder im Ausnahmefall durch Angabe unter objects (s.u.)), müssen entweder innerhalb der Liste des jeweiligen Macro deklariert werden, oder schon durch Deklaration an einer vorherigen Stelle des Prozesses bekannt sein! Identische Macros an verschiedenen Stellen eines Prozesses müssen also nicht mehrfach deklariert werden. Eine für einen Prozess gültige Makro-Deklaration kann auch durch einen Link erfolgen, der auf eine Deklaration außerhalb der Komposition verweist. Einmal entwickelte Macros sind also, wenn passend, in verschiedenen Kompositionen einsetzbar.



2.) Childs-Macro (txChildsFrame)

Wie der Name bereits andeutet, behandelt dieses zweite Macro Childs, also in diesem Falle zunächst die Einträge der Liste, durch die der Prozess gestartet wurde. Macros, die nicht nur einen einzelnen Eintrag, sondern die gesamte Liste von (Sub-) Einträgen ("Childs") eines Eintrags behandeln, unterscheiden sich generell von diesen, und haben als source-Angabe immer und nur den Pseudo-Typ "txChildsFrame". Dieser spezielle Macro-Typ ist notwendig, da die pageFab nicht nur rein seriell arbeitet (entlang einer Liste), sondern auch wurzelartig in die Tiefen einzelner Einträge und deren Sub- und Sub-Sub-Einträge etc. (=Tree) wandern können muß. Nur wenn einem (Eintrags-) Macro ein Childs-Makro untergeordnet ist, wird "in die Tiefe" gearbeitet. Ansonsten werden die ggf. vorhandenen Unter-Einträge ignoriert.

Ein Childs-Macro hat die Aufgabe für jeden einzelnen Child-Eintrag zu prüfen, ob hierfür ein spezielles Macro, und wenn nicht, ein allgemein gültiges sogenanntes Default-Macro (source="txDefault") verfügbar ist, das den Eintrags-Content produzieren kann (ist kein Makro mit txDefault zugeordnet, werden nur die deklarierten Eintragstypen produziert). Ist ein dem Eintragstyp zugeordnetes Makro gefunden worden, wird der Eintrag zur weiteren Produktion an dieses übergeben. Im anderen Falle wird der Eintrag ignoriert, und der nächste Listeneintrag behandelt. Sind alle Einträge abgearbeitet, gibt das Macro die weitere Produktion wieder an das aufrufende Macro zurück.

Welche Macros ein Childs-Macro verwenden kann, wird, wie bereits oben erläutert in dem Cliché des Macros in einer macroMarke angegeben. Werden hier mehrere Macro-Namen angegeben, werden diese durch Komma und Leerzeichen getrennt notiert. Childs-Macros benötigen oftmals aber gar keine eigenen Clichés, und statt einer Aufzählung der zulässigen Macros in der macroMarke können diese unter objects angegeben werden. Andererseits benötigen Childs-Macros mit Cliché als Ausnahmefall keine Angabe für objects(*).


*) Ist ein Cliche notwendig, und wird eine Cliché-Datei für unterschiedliche Childs-Macros verwendet, kann durch zusätzliche Angaben unter objects eine abweichende Verwendung festgelegt werden, da Makro-Angaben in objects einen insgesamt ausschließenden Vorrang vor den Angaben in der macroMarke des Childs-Clichés haben. Auf diese Weise kann ohne Dateiänderung in einseitig oder wechselseitig Inhalte auschließenden Variationen produziert werden.



3.) Content Macros

In Unterscheidung zum speziellen Typ des Childs-Macros können wir alle anderen Macros zusammenfassend als Content-Macros oder Eintrags-Macros bezeichnen. Ihre Aufgabe ist es, den Inhalt eines Eintrags zu produzieren, wenn dieser den im Macro angegebenen Bedingungen entspricht.

Dazu gehört auch, falls der Eintrag selbst wiederum (Sub-) Einträge enthält, zu prüfen, ob für dieses Content-Macro ein Childs-Macro deklariert wurde, und die weitere Produktion für die Sub-Einträge an dieses zu übergeben, wenn dies der Fall ist, und von dem Macro-Cliche verlangt wird (s.o.: macroMarke). Ist dies nicht der Fall, werden vorhandene Sub-Einträge ignoriert.

Die eigentliche Content-Produktion erfolgt, indem die eine oder auch mehrfach vorkommen könnende Ersetzungsmarke IX_REPLACE in einer Kopie des Clichés des Macros durch Eintrags-Content (-Teile) ersetzt, und das Ergebnis zum Page-Produkt hinzugefügt wird.

Cliché-Beispiel eines Content-Makros:

<a name=" IX_REPLACE"></a><br><br> IX_REPLACE<br><br>


Was als Content des Eintrags genau verwendet wird, das wird durch die objects-Angaben des Macros gesteuert (siehe Beschreibung im übernächsten Artikel).



4.) Referenz Macros

Als Referenz-Makros werden Makros bezeichnet, die (nur oder in Verbindung mit weiteren Objekten) in objects das Objekt ob_ref notiert haben. Das Objekt ob_ref sammelt die Angabe von Referenz-Marken und deren Ersetzungswerte. Nach Ende der (primären) Seitenproduktion werden die Referenz-Marken in der HTML-Seite mit den jeweiligen Werten ersetzt.


.15.0505 updated
index^
eng^




•  

pageFab Komposition

Es folgt ein konkretes Beispiel, mit dem gezeigt wird, wie die Anordnung des Einträge-Trees der aus Macro-Einträgen und Cliché-Datei-Einträgen zusammengesetzen pageFab-Komposition sich darstellt (Fab-Tree).

Im zweiten Teil wird ein zu dieser Anordnung passender sehr einfacher HTML-Entwurf gezeigt, und wie dieser in die einzelnen Cliché-Dateien zu zerlegen ist.

Dieser Entwurf kann verwendet werden, um einerseits mit einem HTML-Editor das Layout weiter zu entwickeln, und andererseits durch Einfügung neuer pageFab-Macros und Clichés die Content-Produktion weiter zu differenzieren.

Die eigentliche Content-Produktion und deren Möglichkeiten mittels den pageFab-Objekten wird dann in dem nächsten Aritkel beschrieben.



1.) Macro-Einträge-Tree

Die folgende Tabelle zeigt den Einträge-Tree einer einfachen pageFab-Komposition:


Start-Macro
Cliché-Datei (1) mit HTML-Rahmen und makroMarke mit "x_cm1"
Childs-Macro "x_cm1" mit soures="txChildsFrame"
ggf. Cliché-Datei (2) mit makroMarke mit "x_m1" (sonst Macro in "x_cm1" unter objects benennen, s.o.)
Content-Macro "x_m1" mit sources="txDefault" (behandelt hier alle Eintragstypen)
Cliché-Datei (3) mit IX_REPLACE und makroMarke mit "x_cm1"
da das Macro "x_cm1" schon oben deklariert wurde ist hier keine weitere Deklaration notwendig


Mit dieser Komposition werden alle Einträge der zu produzierenden Liste durch das Content-Macro "x_m1" produziert, das von dem Child-Macro x_cm1 für jeden einzelnen Eintrag aktiviert wird. Hat ein Listen-Eintrag selbst wieder Sub-Einträge (Childs), wird von dem Content-Macro wieder das Child-Macro "x_cm1" aufgerufen.Auf diese Weise wird die gesamte Tiefe eines Tree-Komplexes durchlaufen und produziert.



2.) HTML-Entwurf

Im folgenden ein einfacher HTML-Entwurf für die o.a. Struktur, der an denCliché-Marken in die einzelnen Cliché-Dateien zerschnitten werden kann.


----   Entwurf-Datei   (pf_x.html) -----

<!DOCTYPE html>
<html><head></head>
<body>

<table><tbody>
<!-- PF_M="x_cm1" -->
durch diese macroMarke wird das Cliché_2 von x_cm1 aktiviert =>

<!-- cliche_2 -->
Cliché_2 ist Teil eines Childs-Macro (txChildFrame)
     <td>&nbsp;&nbsp;</td><td>
     <table><tbody>
     <!-- PF_M="x_m1" -->
     durch diese macroMarke wird für jeden Eintrag
     das Cliché_3 von x_m1 aktiviert =>


     <!-- cliche_3 -->
     Cliché_3 ist Teil eines Content-Macro, gültig für alle Einträge (txDefault)
         <td> &nbsp;&nbsp;</td><td> IX_REPLACE</td>
         <!-- PF_M="x_cm1" -->
         falls der Eintrag Sub-Einträge hat, repetativ wieder Cliché_2 von x_cm1

     <!-- /cliche_3 -->

     </tbody></table>
     </td>
<!-- /cliche_2 -->

</tbody></table>
</body>
</html>




3.) Die resultierenden Clichés

Die Zerlegung ergibt dann die folgenden drei Cliché-Dateien:


----   Clichè-Datei 1   (pf_x_c1.html.txt) -----

<!DOCTYPE html>
<html><head></head>
<body>

<table><tbody>
<!-- PF_M="x_cm1" -->

</tbody></table>
</body>
</html>



----   Clichè-Datei 2   (pf_x_c2.html.txt) -----

<!-- cliche_2 -->
     <td>&nbsp;&nbsp;</td><td>
     <table><tbody>
     <!-- PF_M="x_m1" -->

     </tbody></table>
     </td>
<!-- /cliche_2 -->



----   Clichè-Datei 3   (pf_x_c3.html.txt) -----

     <!-- cliche_3 -->
         <td> &nbsp;&nbsp;</td><td> IX_REPLACE</td>
         <!-- PF_M="x_cm1" -->

     <!-- /cliche_3 -->



Mit diesem minimalen Aufwand sind beliebig komplexe Einträge-Trees als HTML-Seite produzierbar. Das Beispiel ist in der Starter-Datenbank enthalten (suche dort: "pageFab::").

Soll ein einzelnes Cliché verändert werden, oder als Grundlage für eine neue Variation dienen, das Cliché kopieren und in einem HTML-Editor mit der Funktion "HTML Code Einfügen" (Kompozer: Menü Einfügen / HTML) einfügen. Über die gleiche Funktion kann die markierte neue Version dann kopiert und verwendet werden.


index^
eng^




•  

pageFab Objekte

Mit den in einem fabMakro in objects angegebenen fabObjekten werden jeweils bestimmte Inhalte (content) des jeweils aktuellen Produktions-Eintrages (Eintrags-Objekte^) oder seiner Sub-Einträge (Childs-Objekte^) für die Produktion ausgewählt und durch die Objekte produziert.

Bei der Produktion werden die Inhalte in einer Arbeitskopie des jeweiligen Cliché eingearbeitet, und zwar durch die Ersetzung an der hier jeweils nächsten Ersetzungs-Marke IX_REPLACE. So wird beispielsweise bei einem normalen Eintrag mit dem Objekt ob_content eine Ersetzungs-Marke durch den Content des Eintrags, also dessen Text, ersetzt.

Wenn in einem Makro mehrere Objekte in objects angegeben sind, dann müssen in der Regel auch entprechend viele Ersetzungs-Marken in dem Cliché enthalten sein. Die Ersetzungen erfolgen entsprechend der Reihenfolge der angegebenen Objekte.

Eine Sonderrolle spielen die MP3-Objekte (m3m-Objekte^), die sich speziell nur auf MP3-Titel-Einträge beziehen. Weiterhin gibt es einige Objekte mit speziellen Aufgaben (Diverse Objekte^).

Eine weitere Gruppe von Objekten steht im Zusammenhang mit den HTML-Pratikeln (Partikel-Objekte^).

Eine aktuell noch nicht realisierte Form der Objekte sind die sogenannten User-Objekte.



Liste der verfügbaren Objekte:



.14.1122 updated
index^
eng^




•  

Eintrags-Objekte


content in work

... entsprechend der Reihenfolge ...



Eintrags-Objekte

ob_content
ob_txIcon
ob_imageSize
ob_value
ob_stack








  ob_content


Ersetzung der Ersetzungs-Marke bei:


- Standard-Einträgen: mit HTML-konvertierten Eintrags-Text

- txFile oder txInterNet: mit entsprechenden HTML-Link

- HTML-Partikel (.html.txt^): mit dem Datei-Inhalt



Im Falle eines HTML-Partikel^ können Veränderungen an dem einzufügenden HTML-Partikel vorgenommen werden. Siehe hierzu die entsprechenden Anmerkungen in der Beschreibung des ähnlichen Objekts ob_child_htmltxtContent^.

Im Falle eines txFile ist die relative oder absolute Addressierung abhängig von dem angegebenen Produktions-Target. Siehe hierzu das Beispiel zu ob_child_firstFileLink^.

Im Falle eines HTML-Links siehe bezüglich des Link-Attributs target die Beschreibung zu ob_child_firstFileLink^.




  ob_txIcon

Ersetzung der Ersetzungs-Marke mit dem Dateinamen der Icon-Datei des Eintrags-Typs. Erfolgt die Produktion in eine Datei, werden auch die entsprechenden Icon-Dateien erzeugt, falls nicht schon vorhanden. Das Zielverzeichnis für die zu speichernden Icon-Dateien enstpricht der Angabe des Produktions-Targets^. In dem Cliché kann vor der Ersetzungs-Marke auch eine relative Pfadangabe stehen (z.B. "icons/" oder "../imgs/" etc.).

Beispiel:


<img style="width: 16px; height: 16px;" src=" IX_REPLACE">

   wird ersetzt zu beispielsweise

<img style="width: 16px; height: 16px;" src="_icx112.png">


Bei einem Eintrags-Typ txFile, der eine HTML-Partikel-Datei referenziert (.html.txt^), wird statt einem txFile-Icon das nicht sichtbare txBlankLine-Icon verwendet.




  ob_value

Mit dieser Funktion können Ersetzungsmarken mit Inhalten ersetzt werden, die in den produzierenden Einträgen deklariert wurden.

Diese Funktion wird in objects^ nicht wie die anderen Objekte direkt benannt, sondern wird hier durch die Angabe von Value-Label vermittelt aktiviert.

Als Value-Label werden Bezeichner mit führendem Punkt erkannt. Die Bezeichner dürfen keine Leerzeichen enthalten.

Sind in objects Value-Label notiert, sucht die Funktion ob_value nach der entsprechenden Werte-Deklaration in dem produzierenden Eintrag.

Die Werteangaben der Value-Label innerhalb der pageFab unterscheiden sich in der Form von denen der Value-Label der inEx-Funktion valueTotal. Im Gegensatz zu diesen muß die Wertangabe hier in Anführungszeichen gesetzt werden.

Beispiel einer Value-Label-Deklaration:

.valueName="Wertangabe"





  ob_stack

Für jeden Produktions-Eintrag enthält das jeweils zugeordnete Makro einen Stack ("Stapel", einen Zwischenspeicher mit first in / first out (FIFO, i.e. eine Schlange (Queue))), in dem Sub-Einträge (Childs) Ersetzungen ablegen können.

Sind alle Untereinträge des Produktions-Eintrag produziert worden, und der Stack ist nicht leer, müssen im zugeordneten Cliché weitere Erstetzungs-Marken entsprechend der Anzahl der Ablagen im Stack vorhanden sein.

Dieses einfache Verfahren ist nur dann möglich, wenn die Anzahl der Ablagen im Voraus bekannt, und in allen Fällen konstant ist. Wenn dies nicht der Fall ist, müssen die Ablagen durch ein zusätzliches Makro produziert werden, das unter sources den Pseudo-Typ txStack notiert hat. In diesem Fall enthält das Cliché nur eine Ersetzungs-Marke, und in der Makro-Marke^ des Clichés muß das Marko zur Produktion der Ablagen mit angegeben sein. In dem Cliché, mit dem die Ablagen produziert werden, müssen so viele Ersetzungs-Marken enthalten sein, wie durch jeweils einen einzelnen Sub-Eintrag in den Stack abgelegt werden.

Ein Anwendungsbeispiel ist die MP3-Ranking-List^, in der zunächst die untergeordneten MP3-Einträge produziert werden, die jeweils die Bild-Datei des Covers auf den Stack der Liste ablegen, und zum Schluß übernimmt das txStack-Makro die Produktion der Image-Tags entsprechend der Anzahl der Ablagen.

Bei der Produktion eines Sub-Eintrags werden Ersetzungen in den Stack durch das Objekt ob_stack abgelegt, das in objects des Makros des Sub-Eintrags notiert ist. Die Ergebnisse aller Objekte, die nach der Angabe ob_stack in objects eingetragen sind, werden durch ob_stack auf den Stack abgelegt.

Das Makro mit dem Pseudo-Typ txStack in sources benötigt als ein weiterer Ausnahmefall wie bei dem Pseudo-Typ txChildsFrame keine objects-Angabe.


index^
eng^




•  

Childs-Objekte


content in work

... entsprechend der Reihenfolge ...



Childs-Objekte

ob_child_firstNetName
ob_child_firstFileName
ob_child_firstNetLink
ob_child_firstFileLink
ob_child_firstImageFileName
ob_child_firstTxImageFileName
ob_child_htmltxtContent
ob_child_liftUp








  ob_child_firstNetName

Diese Funktion ist im Grunde identisch mit der als nächstes beschriebenen ob_child_firstFileName und bezieht sich auf txInterNet- statt auf txFile-Einträge.




  ob_child_firstFileName

Mit dieser Funktion kann die Datei-Adressierung eines in dem Eintrag enthaltenen Sub-Eintrags vom Typ txFile (Datei-Eintrag) ermittelt werden. Gesucht wird ein erster vorkommender txFile-Eintrag.

Ist der produzierende Eintrag ein Link, der ja keine Sub-Einträge enthalten kann, wird statt dessen der mit diesem Link referenzierte Original-Eintrag zu Ermittlung verwendet. Diese Umlenkung erfolgt auch dann, wenn in sources keine txLink-Angabe für den Eintragstyp angegeben wurde.

Der gefundene Sub-Eintrag wird in einer ignorList notiert, ebenso wie ein eventuell folgender txBlankLine-Eintrag, wenn dieser der letzte Child-Eintrag ist. Folgt eine Behandlung der Sub-Einträge des Eintrags, werden die in der ignorList notierten Einträge nicht noch einmal produziert. Das Ergebnis der Ignorierung kann auch sein, daß die Liste der Sub-Einträge leer wird, und keine Childs-Behandlung ausgeführt wird.

Beispiel:


IX_REPLACE

   wird ersetzt in:

<a href=" IX_REPLACE">

   zu beispielsweise:

<a href= "FILE:///D:/test/seite1.html">


Die relative oder absolute Addressierung ist abhängig von dem angegebenen Produktions-Target.




  ob_child_firstNetLink

Diese Funktion ist im Grunde identisch mit der als nächstes beschriebenen ob_child_firstFileLink und bezieht sich auf txInterNet- statt auf txFile-Einträge.




  ob_child_firstFileLink

Mit dieser Funktion kann die Datei-Adressierung eines in dem Eintrag enthaltenen Sub-Eintrags vom Typ txFile (Datei-Eintrag) ermittelt werden. Gesucht wird ein erster vorkommender txFile-Eintrag.

Ist der produzierende Eintrag ein Link, der ja keine Sub-Einträge enthalten kann, wird statt dessen der mit diesem Link referenzierte Original-Eintrag zu Ermittlung verwendet. Diese Umlenkung erfolgt auch dann, wenn in sources keine txLink-Angabe für den Eintragstyp angegeben wurde.

Wurde ein entsprechender Sub-Eintrag gefunden, dann führt diese Funktion keine Ersetzung durch, sondern umhüllt die Ersetzungsmarke mit einem Link-Tag auf die entsprechende Datei. Die Ersetzungsmarke steht danach an der Stelle des sichtbaren Teiles des Links, und wird in der Praxis dann in einem zweiten Vorgang ersetzt, z.B. mit dem Text des produzierenden Eintrags (ob_content).

Der gefundene Sub-Eintrag wird in einer ignorList notiert, ebenso wie ein eventuell folgender txBlankLine-Eintrag, wenn dieser der letzte Child-Eintrag ist. Folgt eine Behandlung der Sub-Einträge des Eintrags, werden die in der ignorList notierten Einträge nicht noch einmal produziert. Das Ergebnis der Ignorierung kann auch sein, daß die Liste der Sub-Einträge leer wird, und keine Childs-Behandlung ausgeführt wird.

Beispiel:


IX_REPLACE

   wird umhüllt mit beispielsweise:

<a href="seite1.html"> IX_REPLACE</a>

   oder:

<a href= "FILE:///D:/test/seite1.html"> IX_REPLACE</a>


Die relative oder absolute Addressierung ist abhängig von dem angegebenen Produktions-Target.

Das Link-Tag-Attribut target="_blank" bewirkt, daß der Browser das Ziel in einem neuem Browserfenster darstellt (sofern er die Zieldatei darstellen kann). Wenn dies der Fall sein soll, kann zusätzlich das Objekt ob_linkBlank unter objects angegeben werden, daß die Angabe dieses Attribut hinzufügt. - HINWEIS: ob_linkBlank ist in der aktuellen Version noch nicht enthalten!




  ob_child_firstImageFileName

Mit dieser Funktion wird die Ersetzungs-Marke mit der Datei-Adressierung eines in dem Eintrag enthaltenen Sub-Eintrags vom Typ txFile (Datei-Eintrag) ersetzt, der eine Grafik-Datei referenziert. Gesucht wird ein erster vorkommender entsprechender txFile-Eintrag.

Beispiel:


<img style="width: 16px; height: 16px;" alt=""
src=" IX_REPLACE">

   wird ersetzt zu beispielsweise:

<img style="width: 16px; height: 16px;" alt=""
src="../imgs/test.png">


Die relative oder absolute Addressierung ist abhängig von dem angegebenen Produktions-Target. Siehe hierzu das Beispiel zu ob_child_firstFileLink.

Der gefundene Sub-Eintrag wird in einer ignorList notiert. Siehe hierzu die Beschreibung unter ob_child_firstFileLink.




  ob_child_firstTxImageFileName

Dies ist die gleiche Funktion wie ob_childs_firstImageFileName, mit dem Unterschied, daß zunächst nach einem ersten Sub-Eintrag vom Typ txImage gesucht wird, und dann dessen untergeordneter Bild-Datei-Eintrag verwendet wird.




  ob_child_htmltxtContent

Mit dieser Funktion wird der Inhalt einer .html.txt-Datei (HTML-Partikel) eingefügt, die an der ersten Child-Position des Produktions-Eintrags mit einem txFile-Eintrag referenziert wird.

Ist der produzierende Eintrag ein Link, wird statt dessen der mit diesem Link referenzierte Original-Eintrag zu Ermittlung verwendet. Die Umlenkung erfolgt durch dieses Objekt jedoch nur dann, wenn unter sources zusätzlich eine txLink-Angabe für den Eintragstyp angegeben wurde.

Wurde ein entsprechender Eintrag aufgefunden, wird dieser in der ignorList notiert (siehe hierzu die Beschreibung zu ob_child_firstFileLink).

Sind keine weiteren Objekte angegeben, die den Text oder Textteile des Eintrags produzieren, bleibt der Produktionseintrag unsichtbar.

In objects können zusätzlich die folgenden (Pratikel-) Objekte angegeben werden, die vor der Einfügung Veränderungen an dem einzufügenden HTML-Partikel vornehmen:

- ob_anchorTarget
- ob_text2html (noch nicht verfügbar)
- ...


index^
eng^




•  

Diverse und MP3-Objekte



content in work

... entsprechend der Reihenfolge ...


Diverse Objekte

ob_ref
ob_fileCopy
ob_inexString
ob_linkAddBlank


MP3-Objekte

ob_m3m
ob_m3m_starIcon
m3m_cutLead
m3m_cutPost1 + 2
m3m_cutBi1 + 2
m3m_starIcon
m3m_webSearch





>

  ob_ref

Das Objekt ob_ref sammelt die Angabe von Referenz-Marken und deren Ersetzungswerte. Nach Ende der (primären) Seitenproduktion werden die Referenz-Marken in der HTML-Seite mit den jeweiligen Werten ersetzt.

Zur Deklaration von Aufgaben für ob_ref wird in dem Makro unter objects einmal oder mehrfach ob_ref angegeben.

In den zum Macro korrespondieren Produktions-Einträgen muß eine oder mehrere Label-Value-Deklarationen entsprechend der Reihenfolge der Notierungen in objects enthalten sein.

Das Objekt sucht nach Ende der (primären) Produktion nach Referenz-Marken in der HTML-Seite, und ersetzt diese mit den in der Deklaration angegebenen Werten.


Beispiel einer Referenz-Marke im HTML-Text:

IX_REF=".abc"


Wie zu sehen ist, enthält die Referenz-Marke die Angabe eines Value-Labels. Das Objekt ersetzt in der HTML-Seite die gesamte Referenz-Marke mit dem jeweils zugewiesenen Wert des Value-Labels. Gibt es mehrfache Vorkommen einer einzelnen Referenz-Marke, werden auch alle Vorkommen ersetzt.


Praxisbeispiel einer HTML-Titel-Setzung:


    Deklaration im Produktions-Eintrag:

.derTitel="Meine erste Seite"

    Die Eintragung in der HTML-Seite:

<title> IX_REF=".derTitel"</title>

    wird ersetzt zu:

<title>Meine erste Seite</title>



Hinweis: In der aktuellen Version dürfen in dem Produktions-Eintrag außer den Value-Label-Deklarationen für ob_ref keine weiteren enthalten sein.




  ob_fileCopy

Werden in HTML-Particles Bild-Dateien verwendet die durch keine anderen Einträge ebenfalls produziert werden, dann können diese mit ob_fileCopy explizit zum dem im pf_target="..."-Eintag angegebenem imgFolder="..." kopiert werden. Die Funktion kopiert lediglich die Datei; der entsprechende Eintrag wird ignoriert und zur Produktion nichts weiter hinzugefügt.

Beispiel: Sie verwenden einen bestimmten Eintrags-Typ als Quelle (z. B. sources="txPhoto, LtxPhoto") dessen erster Sub-Eintrag ein txFile der betreffenden Bild-Datei enthält. Für diesen Eintragstyp geben sie unter objects="ob_fileCopy" an.

Also z. B.:
pf_md="..." sources="txPhoto, LtxPhoto" objects="ob_fileCopy"




  ob_m3m

content in work

... ob_m3m: - im Titel nicht Fett ab öffnender eckiger Klammer ...





  m3m_webSearch

Mit diesem Objekt kann aus den Artist- und Titel-Angaben eines MP3-Eintrags ein InterNet-Link auf eine Suchmaschine oder andere Domainarten erzeugt werden. Die Behandlung der Ersetzungs-Marke IX_REPLACE erfolgt dabei in gleicher Weise wie bei den anderen Web- oder File-Link-Erzeugungen; es wird also für Link und Eintrag nur eine Ersetzungsmarke benötig.

Die Adresserzeugung setzt sich aus zwei Teilen zusammen. Einerseits aus den Artist- und Titel-Angaben des aktuell zu produzierenden MP3-Eintrags, sowie der Domain-Deklaration, die in dem fabMakro erfolgen muss, in welchem das m3m_webSearch-Objekt notiert wird. Wesentlich ist hierbei die Verwendung des Label-Bezeichners ".webSearch".


 pageFab-Makro mit Domain-Deklaration:


  pf_md="..." sources="..." objects="..." Domain-Deklaration


Beispiel:

sources="txMusicGreen, LtxMusicGreen"

objects="m3m_starIcon, m3m_webSearch, ..."

Domain-Deklaration: .webSearch= "google.com/?hl=en&q="






.14.1122 updated
index^
eng^




•  

Partikel-Objekte



ob_case
ob_anchorTarget

ob_repeatList





  ob_case

Hinweis: In der aktuellen Version kann ob_case nur innerhalb von HTML-Partikeln, nicht in Makro-Clichés angewandt werden. Weiterhin werden aktuell lediglich nur jeweils einzeilige Alternativen akzeptiert (Bereich "..." im Bild).

Struktur der Case-Anweisung:


IX_CASE="Bezeichner, Wert[, Wert2, Wert3, ...]"
...
IX_ELSE oder
IX_ELSECASE="Bezeichner, Wert[, Wert2, Wert3, ...]"
...
IX_END


Bezeichner: Bezeichner eines Value-Labels

Wert: Der Wert, dem der deklarierte Wert des Value-Labels entsprechen muß

IX_ELSECASE: Kann in Folge mehrfach vorkommen, IX_ELSE kann danach als letztes vorkommen.



Wenn der aktuell deklarierte Wert mit einer der Wertangaben in CASE übereinstimmt, dann wird die CASE-Variante, sonst die ELSE-Variante verwendet.


Beispiel:


IX_CASE= ".targetFile, index.html"
Startseite
IX_ELSE
<a href= "index.html">Startseite</a>
IX_END


In dem Bespiel wird die interne Prozess-Variable der Zieldatei-Deklaration verwendet. Wird keine interne Variable verwendet, wird die Wert-Deklaration in dem aktuellen Produktions-Eintrag gesucht.




  ob_anchorTarget

Diese Funktion erweitert alle seitenlokalen Links in einem HTML-Partikel um die Angabe einer HTML-Datei und des Tag-Attributs target, wenn diese Dateiangabe nicht dem Produktions-Target entspricht. Die Dateiangabe muß in einem Value-Label ".anchorTarget" in dem produzierenden Eintrag angegeben sein. Die seitenlokalen Links werden durch das Vorkommen von "<a href="#" identifiziert.

Diese Funktion ist wesentlich für Menüs oder andere Partikel, die auf mehreren Seiten verwendet werden sollen.

Beispiel:


.anchorTarget="xyz.html"

   erweitert in dem Partikel

<a href="#abc">...</a>
  zu
<a href="xyz.html#abc">...</a>





  ob_repeatList

Mit ob_repeat können formatierte Listen produziert werden. Die einzelnen Zeilen der Liste sind in einem HTML-Partikel notiert, auf das im Produktions-Eintrag mit einem Datei-Eintrag referenziert wird.

Ist in einem Makro in objects das Objekt ob_repeat notiert, dann muß das Cliché des Makros die folgende Repeat-Struktur enthalten:

Repeat-Struktur:


...
IX_REPEAT
...
...
IX_REPLACE
...
...
IX_ENDREPEAT
...


Der Inhalt der Repeat-Schleife wird so oft produziert, wie in dem HTML-Partikel Zeilen enthalten sind. Die Ersetzungsmarke wird mit der jeweiligen Zeile ersetzt. Hinweis: In der aktuellen Version wird ein Zeilenende durch einen normalen Umbruch (Return-Taste) identifiziert. In folgenden Versionen ist alternativ auch eine Kapselung mit dem div-Tag möglich.


Beispiel einer Liste mit führendem Bullet-Zeichen:


IX_REPEAT
<tr><td> &bull;&nbsp;&nbsp; </td><td>
IX_REPLACE
</td></tr>
IX_ENDREPEAT


Optional kann vor der Repeat-Struktur eine Ersetzungs-Marke vorhanden sein, um z.B. eine Listenüberschrift zu erzeugen. Ist dies der Fall, muß in dem Makro in objects an erster Stelle ein Value-Label benannt sein. In dem Produktions-Eintrag muß die entsprechende Deklaration enthalten sein, und der Wert ist der ersetzende Inhalt.


.14.1023 updated
index^
eng^




•  

HTML-Partikel-Dateien (.html.txt)


HTML-Partikel werden nicht nur von der pageFab, sondern auch schon von der tree2HTML-Funktion unterstützt. Bei Dateieintägen (txFile) mit der Dateikennung (Extension) ".html.txt" wird bei der Produktion statt des Dateieintrags der Inhalt der referenzierten Datei an der Eintragsposition eingefügt.

Der Dateiinhalt muss HTML-konform sein. Als Beispiel für die Einfügung einer horizontalen Linie muss die Datei <hr> enthalten. Angebote von Embedded Codes können kopiert, in inEx als Textdatei eingefügt, und dann durch entsprechende Änderung der Datei-Extension als HTML-Partikel verwendet werden.

Der integrierte Editor für Textdateien enthält einige Hilfsfunktionen, wie z. B. die Umwandlung von Plain-Text nach HTML (lokales Menü: flat2HTML) u. a.

Im Rahmen der pageFab werden die Möglichkeiten mittels HTML-Partikel durch partikel-spezielle Produktions-Objekte erweitert (siehe Partikel-Objekte^).



Partikel-Dateien und inExTreeFile (.itf.txt)

Der Datei-Typ inExTreeFile^ dient dem Datenaustausch. Wurde ein Tree kopiert in dem Partikel-Datei-Referenzen enthalten sind, wird bei der Funktion "Als ITF-Datei einfügen" der Inhalt der Dateien in die zu erzeugende ITF-Datei mit übernommen. Auf diese Weise können bei der späteren Einfügung der ITF-Datei die entsprechenden Partikel-Dateien rekonstruiert werden.



HTML-Baukasten

Für nicht so geübte Anwender, oder sonst auch für seltener vorkommende Fälle könnte ein "HTML-Baukasten" angelegt werden, eine Liste, deren Einträge über ein kurzes Label (z.B. hbk: oder h##) in der Suche gelistet dann die entsprechende Informationen oder auch Code-Vorlagen zum kopieren enthalten.


.15.0622 updated
index^
eng^




•  

Praxis-Beispiele

content in processing


index^
eng^




•  

Multi Page Fab

content in processing


index^
eng^




•  

Blog Fab

content in processing


index^
eng^






Flag Counter
since 2013.06
0.6k / 1,5k / 3,0k






video new mods language rss feed index
- Homepage -
 
(1) Übersicht   -   (2) Konzepte   -   (3) Standard GUI   -   (4) padWin GUI
(5) Datei Support   -   (6) HTML Exporte   -   (7) Diverses
(8) Freeware Edition / Licence Edition
 

Aktuelle Programmversion: Release 1.06.1 vom 16. November 2016





inEx  -  manage the information space

inEx information explorer - © 2008...2016 - Jürgen Viestenz

www.information-explorer.de