XML code:

---

<WINDOW title="Memory Monitor" undermouse="TRUE" layout="TRUE" RELPTR="g_pic_window">
	<VERT>
		<TITLE text="bitplane" />
		<FRAME style="bevel" hprop="TRUE" vprop="TRUE">
			<PLANEVIEW RELPTR="g_picview" />
		</FRAME>
		<HORIZ spaceprop="FALSE">
			<CHECK senschar="z" hook="zoom_hook" RELPTR="g_zoom_check" />
			<LABEL text="zoom" linechar="1" />
		</HORIZ>
	</VERT>
</WINDOW>

---

M68k Assmbler code:

---

dc.l	OX_WINDOW,.window_001
		dc.l	TAG_END

.window_001	dc.l	oxWA_title,.wa_title_001
		dc.l	oxWA_undermouse,TRUE
		dc.l	oxWA_layout,TRUE
		dc.l	OX_RELPTR,g_pic_window
		dc.l	OX_VERT,.vert_001
		dc.l	TAG_END

.wa_title_001	dc.b	"Memory Monitor",0
		even

.vert_001	dc.l	OX_TITLE,.title_001
		dc.l	OX_FRAME,.frame_001
		dc.l	OX_HORIZ,.horiz_001
		dc.l	TAG_END

.title_001	dc.l	oxTA_text,.ta_title_001
		dc.l	TAG_END

.ta_title_001	dc.b	"bitplane",0
		even

.frame_001	dc.l	oxFrA_framestyle,oxFr_BEVEL
		dc.l	oxFrA_hprop,TRUE
		dc.l	oxFrA_vprop,TRUE
		dc.l	planeview,.planeview_001
		dc.l	TAG_END

.planeview_001	dc.l	OX_RELPTR,g_picview
		dc.l	TAG_END

.horiz_001	dc.l	oxGA_spaceprop,FALSE
		dc.l	OX_CHECK,.check_001
		dc.l	OX_LABEL,.label_001
		dc.l	TAG_END

.check_001	dc.l	oxChkA_senschar,"z"
		dc.l	oxChkA_hook,zoom_hook
		dc.l	OX_RELPTR,g_zoom_check
		dc.l	TAG_END

.label_001	dc.l	oxLabA_text,.laba_text_001
		dc.l	oxLabA_linechar,1
		dc.l	TAG_END

.laba_text_001	dc.b	"zoom",0
		even

---

Hat jemand Lust so einen Compiler zu schreiben?

--
Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux

[ Dieser Beitrag wurde von AGSzabo am 01.06.2011 um 18:24 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

Klingt zwar schön und gut, doch wie soll das Compilat aussehen? Soll es eine eigene GUI Engine werden (wie MUI, Intuition, Boopsi...) oder eine der vorhandenen benutzen?
Etwas eigenes zu machen ist nicht "nur ein Compiler" entwerfen, sondern ein komplettes GUI System. Das ist nicht nur Buttons und Checkboxen malen, sondern auch Hierarchien, Events etc zu implementieren.

Kannst Du hier etwas nährere Infos geben?

Ah ok ich sehe gerade, du hast OX als Beispiel angegeben. Gibt es für OX bereits ein Developer Paket?

[ Dieser Beitrag wurde von Thore am 01.06.2011 um 19:30 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

@Thore:

Nö, so ein Paket existiert nicht, falls du ne guide meinst. Es gibt nur einen Haufen Beispielsources und Includefiles mit vielen Kommentaren. Das Komplilat wäre eine liste mit assembler-daten definitionen die verschachtelte taglists enthalten. ich habe schonmal mit dem konzept für den compiler angefangen. irgendwie will ich das teil halt haben.

die markup sprache heisst jetzt OXML!

es spricht imo auch was dafür so ne markup sprache auch in andere gui systeme übersetzen zu können, zb mui.

--
Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux

[ Dieser Beitrag wurde von AGSzabo am 01.06.2011 um 19:53 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Unter einem Developer Paket versteht man in erster Linie Dateien, die der Programmierer zum direkten Programmieren deiner Programmteile verwenden kann.
Dazu gehört neben einer Anleitung eben auch die Header/Include-Dateien, Beispielcodes, evtl. Linklibs und Shared Libs.
Nach deiner Beschreibung existiert sowas also schon

Das Compilat wäre also nur sowas wie Du da aufgeschrieben hast? Sowas ist wirklich machbar. Um alle Objekte und Möglichkeiten (Events, Verschachtelung, ...) von XML nach ASM zu konvertieren, bräuchte man mehr Hintergrundwissen, z.b. wie die Elemente übersetzt heißen. Das könnte man den Headerdateien entnehmen.

Wie soll die Assemblerliste klarmachen, wie die Objekte liegen (Position) und wie sie hierarchisch verbunden sind? Welche Events hängen an den Objekten?

Für MUI brauchts das meiner Meinung nach nicht, da die defines sehr gut ausgeklügelt sind, um ein Pseudo-Script im Sourcecode zu integrieren. Damit wird MUI in C zu programmieren wie Scripting. Feine Sache

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Thore:
Für MUI brauchts das meiner Meinung nach nicht, da die defines sehr gut ausgeklügelt sind, um ein Pseudo-Script im Sourcecode zu integrieren. Damit wird MUI in C zu programmieren wie Scripting. Feine Sache

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von AGSzabo:
Das GUI direkt durch parsen zu erstellen, wozu soll das gut sein?

---

Zitat:

---

Immerhin muss man (bei mir) die addressen bestimmter erzeugter objekte in globale variablen des programms schreiben können, um später auf diese objekte direkt zugreiffen zu können.

---

Zitat:

---

Die Namen der Attribute und Klassen im Ziel-Code sind einfach das was man im XML code findet plus ein prefix. Das ist einfach. Man muss aber wissen zB wissen ob es sich bei einem Parameter um einen String handelt.

---

Zitat:

---

Im moment ist mir bis zu einem gewissen Punkt klar, wie der Compiler zu coden sei, blos dass manche elemente nicht andere elemente enthalten können, sondern nur)individuelle unterelemente.

---

[ - Antworten - Zitieren - Direktlink - ]

code:

---

ntui_BeginWindow("Demo");
  ntui_Label("Test");
  ntui_Button("myButton","Click me!");
ntui_EndWindow();

---

code:

---

<Window title="Demo">
  <Label text="Test">
  <Button text="Click me!" id="myButton");
</Window>

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Zitat:

---

Die Namen der Attribute und Klassen im Ziel-Code sind einfach das was man im XML code findet plus ein prefix. Das ist einfach. Man muss aber wissen zB wissen ob es sich bei einem Parameter um einen String handelt.

---

Ja, und genau diese Informationen musst Du liefern, wenn Dir jemand so einen Compiler schreiben soll.

---

XML code:

---

<CLASS name="WINDOW" attrprefix="W">
    <ATTRIBUTE name="name" type="string" />
</CLASS>

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

@Kaesebroetchen:

Nett! Btw, ich wollte mal ein GUI für den OS4 port von UADE machen. Gibts schon eins?
--
Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux

[ - Antworten - Zitieren - Direktlink - ]

>Nicht falsch verstehen, dass ganze ist im Rahmen des Möglichen wirklich gut, der Rahmen des Möglichen ist halt leider sehr begrenzt.

Ja es kommt immer drauf an was man machen will. Für komplexere Sachen kannst die defines ja einfach nicht benutzen oder Elemente dynamisch hinzuadden. Das ist mit MUI ebenfalls möglich. Es soll nur eine Erleichtrung sein, eine GUI scriptähnlich aufzubauen. Dafür find ich das wirklich gut.

Zur XML als Script Lösung bin ich zwiegespalten und hab diesbezüglich keine 100%ig feste Meinung:
XML ist zwar eine gute Beschreibung die unendlich Möglichkeiten bietet, allerdings muss der Parser diese Möglichkeiten kennen (logischer Aspekt, XMLs aus anderen Versionen können inkompatibel sein) und das Programm muss immer mit dem passenden XML mitgeliefert sein. Sinn oder Unsinn die GUI zu 100% in Userhand zu legen (als Script) ist sicher ein streitbares Thema. Kommt aufs Programm an würd ich sagen, aber _generell_ ist die Idee nicht so prickelnd. Hier stehen sich Dynamische Änderung und Bequemlichkeit gegenüber mit Programmstabilität und ggf Sicherheit. Kommt also wohl aufs Programm an obs angebracht ist oder nicht.

Feelin hatte ich mir seinerzeit angeschaut, und jetzt weiß ich wieder die die GUI mit dem XML heißt Danke für die Erinnerung.
Fand es auch recht schick, aber dann gings mir sicher wie den meisten Leuten Ich bin zu MUI zurückgekehrt.... es hat mir damals mehr gegeben als Feelin

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von AGSzabo:
Ich weis ja noch nicht, was Deine gebrachten Kürzel wie zB XSLT bedeuten, ich hab mal kurz bei wikipedia geschaut, aber mir es scheint sinnvoll für diese Beschreibungen wieder XML code zu verwenden. ZB hier die Umschreibung für die Fenster-Klasse:

XML code:

---

<CLASS name="WINDOW" attrprefix="W">
    <ATTRIBUTE name="name" type="string" />
</CLASS>

---

---

XSLT code:

---

<?xml version="1.0" encoding="iso-8859-1"?>
<?xml version="1.0" encoding="iso-8859-1"?>
<xsl:stylesheet version="1.0"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:output method="text" encoding="ISO-8859-1" indent="no"/>

  <xsl:template match="/">
    <xsl:apply-templates select="." mode="tags"/>
    <xsl:apply-templates mode="strings"/>
  </xsl:template>

  <xsl:template match="*" mode="tags">
    <xsl:variable name="n" select="name()"/>
.<xsl:value-of select="concat($n,generate-id())"/>
      <xsl:apply-templates select="@*" mode="tags"/>
      <xsl:apply-templates mode="ref"/>
	dc.l	TAG_END
      <xsl:apply-templates mode="tags"/>
  </xsl:template>
  <xsl:template match="@*" mode="tags">
	dc.l	ox<xsl:apply-templates select="parent::node()" mode="prefix"/>_<xsl:value-of select="concat(name(),',',.)"/>
  </xsl:template>
  <xsl:template match="@senschar" mode="tags">
	dc.l	oxChkA_senschar,"<xsl:value-of select="."/>"
  </xsl:template>
  <xsl:template match="@RELPTR" mode="tags">
	dc.l	OX_<xsl:value-of select="concat(name(),',',.)"/>
  </xsl:template>
  <xsl:template match="@title|@text" mode="tags">
	dc.l	ox<xsl:apply-templates select="parent::node()" mode="prefix"/>_<xsl:value-of select="concat(translate(name(),
        'abcdefghijklmnopqrstuvwxyz','ABCDEFGHIJKLMNOPQRSTUVWXYZ'),
        ',.',name(),generate-id())"/>
  </xsl:template>
  <xsl:template match="*" mode="ref">
	dc.l	OX_<xsl:value-of select="concat(name(),',.',name(),generate-id())"/>
  </xsl:template>
  <xsl:template match="*" mode="strings">
  <xsl:for-each select="@title|@text">
.<xsl:value-of select="concat(name(),generate-id())"/>
	dc.b	"<xsl:value-of select="."/>",0</xsl:for-each>
    <xsl:apply-templates mode="strings"/>
  </xsl:template>
  <!-- tag id prefixes -->
  <xsl:template match="WINDOW" mode="prefix">WA</xsl:template>
  <xsl:template match="HORIZ|VERT" mode="prefix">GA</xsl:template>
  <xsl:template match="FRAME" mode="prefix">FrA</xsl:template>
  <xsl:template match="TITLE" mode="prefix">TA</xsl:template>
  <xsl:template match="PLANEVIEW" mode="prefix">???????</xsl:template>
  <xsl:template match="CHECK" mode="prefix">ChkA</xsl:template>
  <xsl:template match="LABEL" mode="prefix">LabA</xsl:template>
  <!-- ignore text pi and so on -->
  <xsl:template match="node()" mode="ref" priority="-1"/>
  <xsl:template match="node()" mode="tags" priority="-1"/>
  <xsl:template match="node()" mode="strings" priority="-1"/>
</xsl:stylesheet>

---

Assembler code:

---

.WINDOWN65538
	dc.l	OX_RELPTR,g_pic_window
	dc.l	oxWA_layout,TRUE
	dc.l	oxWA_TITLE,.titleN65542
	dc.l	oxWA_undermouse,TRUE
	dc.l	OX_VERT,.VERTN65545
	dc.l	TAG_END
      
.VERTN65545
	dc.l	OX_TITLE,.TITLEN65547
	dc.l	OX_FRAME,.FRAMEN65550
	dc.l	OX_HORIZ,.HORIZN65559
	dc.l	TAG_END
      
.TITLEN65547
	dc.l	oxTA_TEXT,.textN65548
	dc.l	TAG_END
      
.FRAMEN65550
	dc.l	oxFrA_hprop,TRUE
	dc.l	oxFrA_style,bevel
	dc.l	oxFrA_vprop,TRUE
	dc.l	OX_PLANEVIEW,.PLANEVIEWN65555
	dc.l	TAG_END
      
.PLANEVIEWN65555
	dc.l	OX_RELPTR,g_picview
	dc.l	TAG_END
      
.HORIZN65559
	dc.l	oxGA_spaceprop,FALSE
	dc.l	OX_CHECK,.CHECKN65562
	dc.l	OX_LABEL,.LABELN65567
	dc.l	TAG_END
      
.CHECKN65562
	dc.l	OX_RELPTR,g_zoom_check
	dc.l	oxChkA_hook,zoom_hook
	dc.l	oxChkA_senschar,"z"
  
	dc.l	TAG_END
      
.LABELN65567
	dc.l	oxLabA_linechar,1
	dc.l	oxLabA_TEXT,.textN65569
	dc.l	TAG_END
      
.titleN65542
	dc.b	"Memory Monitor",0
.textN65548
	dc.b	"bitplane",0
.textN65569
	dc.b	"zoom",0

---

[ - Antworten - Zitieren - Direktlink - ]

Nachtrag:
Ich hab's natürlich auch mal auf nem Amiga getestet, Systemunabhängigkeit hin oder her

Hiermit: http://aminet.net/package/text/misc/xsltproc funktioniert es. Es werden zwar im Vergleich zu anderen Prozessoren ein paar zusätzliche Zeilenumbrüche generiert, aber die tun ja nicht weh.

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Thore:
XML ist zwar eine gute Beschreibung die unendlich Möglichkeiten bietet, allerdings muss der Parser diese Möglichkeiten kennen ... und das Programm muss immer mit dem passenden XML mitgeliefert sein.

---

Zitat:

---

Sinn oder Unsinn die GUI zu 100% in Userhand zu legen (als Script) ist sicher ein streitbares Thema. Kommt aufs Programm an würd ich sagen, aber _generell_ ist die Idee nicht so prickelnd. Hier stehen sich Dynamische Änderung und Bequemlichkeit gegenüber mit Programmstabilität und ggf Sicherheit.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von AGSzabo:
@Holger:

Wow, so compliziert hatte ich mir das garnicht vorgestellt.

---

Zitat:

---

Aber wenn es funktioniert ... es sieht sehr vielversprechend aus und man kann das "kompilieren" mit schon bestehender software erledigen, wenn ich das richtig verstanden habe.

---

Ja, das hab ich, glaube ich, dreimal erwähnt

Zitat:

---

an den attributen muss noch etwas geschraubt werden. so soll es zb nicht

oxhook,zoom_hook

heissen, sondern

oxChkA_hook,zoom_hook

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Zitat:

---

Im moment ist mir bis zu einem gewissen Punkt klar, wie der Compiler zu coden sei, blos dass manche elemente nicht andere elemente enthalten können, sondern nur)individuelle unterelemente.

---

Dann solltest Du die Art und Weise, wie Du den Compiler schreiben wolltest, noch mal überdenken.

---

XML code:

---

<CLASS name="MENU" prefix="M" allowobjects="false">
	<ATTR name="popup" type="bool" />
	<ATTR name="hook" type="label" />

	<!-- erzeugt eine Zeile "dc.l oxMA_separator,0",
	     "noclose" steht dafür dass dieses element nicht geschlossen werden braucht -->

	<SUB name="separator" type="noclose" /></SUB>

	<SUB name="ITEM" prefix="MI">
		<ATTR name="text" type="string" />
		<ATTR name="ID" type="number" />
		<ATTR name="exclude" type="words" />
		<SUB name="separator" type="noclose" /></SUB>

		<!-- allow recursive from allready defined entity named "ITEM" -->

		<RECUR name="ITEM" />
	</SUB>
</CLASS>

---

XML code:

---

<MENU popup="TRUE" hook="menu_hook">
	<ITEM text="Datei">
		<ITEM text="laden"></ITEM>
		<ITEM text="speichern"></ITEM>
		<SEPARATOR />
		<ITEM text="beenden"></ITEM>
	</ITEM>
	<ITEM text="Ansicht">
		<ITEM text="Vollbild"></ITEM>
		<ITEM text="klein"></ITEM>
		<ITEM text="groß"></ITEM>
	</ITEM>
	<ITEM text="Optionen">
		<ITEM text="Opt 1" id="1" exclude="2, 3"></ITEM>
		<ITEM text="Opt 2" id="2" exclude="1, 3"></ITEM>
		<ITEM text="Opt 3" id="3" exclude="1, 2"></ITEM>
	</ITEM>
</MENU>

---

asm code:

---

dc.l	OX_MENU,.menu_001
		dc.l	TAG_END

.menu_001	dc.l	oxMA_popup,TRUE
		dc.l	oxMA_hook,menu_hook
		dc.l	oxMA_item,.item_001
		dc.l	oxMA_item,.item_002
		dc.l	oxMA_item,.item_003
		dc.l	TAG_END

.item_001	dc.l	oxMIA_text,.mi_text_001
		dc.l	oxMIA_item,.item_001_001
		dc.l	oxMIA_item,.item_001_002
		dc.l	oxMIA_separator,0
		dc.l	oxMIA_item,.item_001_002
		dc.l	TAG_END

.item_002	dc.l	oxMIA_text,.mi_text_002

		...

		dc.l	TAG_END

.item_003	...

		dc.l	oxMIA_item,.item_003_001

		...

		dc.l	TAG_END

.item_003_001	dc.l	oxMIA_text,.mi_text_00x
		dc.l	oxMIA_exclude,.mi_exclude_001
		dc.l	TAG_END

.mi_exclude	dc.w	2,3
		dc.w	0	; exclude list end

.mi_text_001	dc.b	"Datei",0
.mi_text_002	dc.b	"Ansicht"

		...

.mi_text_00x	dc.b	"Opt 1",0

		...

		even

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von AGSzabo:
@Holger:
Und aus hook="zoom_hook" wird dc.l oxChkA_hook,zoom_hook mit label für den code ganz unten nach den strings?

---

Zitat:

---

Kann man das XSLT auf mehrere Dateien aufteilen damit zB jede neue Klasse ihre eigenen Kompilier-Regeln mitbrigen kann?

---

Zitat:

---

Die Benennung mit _001 ... _002 und so weiter hat mir besser gefallen, und zwar nicht global sondern per klasse und per attribut, wie in meinem Eingangsbeispiel. Geht das?

---

Zitat:

---

@holger
Ich verwende mal meine eigene 'regelsprache' um es zu verdeutlichen. Die Frage ist ja, ob das mit dem XSLT auch geht.

---

Zitat:

---

Wir sehen hier, dass das MENU nicht andere objekte (allowobjects="false") sondern nur eigene sub-elemente beinhalten kann (ITEM). Außerdem kann ein ITEM wieder weitere ITEMS rekursiv enthalten (<RECUR name="ITEM" />).

---

code:

---

<?xml version="1.0" encoding="iso-8859-1"?>
<xsl:stylesheet version="1.0"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:output method="text" encoding="ISO-8859-1" indent="no"/>

  <xsl:template match="/">
    <xsl:apply-templates select="." mode="tags"/>
    <xsl:apply-templates mode="strings"/>
  </xsl:template>

  <xsl:template match="*" mode="tags">
    <xsl:variable name="n" select="name()"/>
.<xsl:value-of select="concat($n,generate-id())"/>
      <xsl:apply-templates select="@*" mode="tags"/>
      <xsl:apply-templates mode="ref"/>
        dc.l    TAG_END
      <xsl:apply-templates mode="tags"/>
  </xsl:template>
  <xsl:template match="@*" mode="tags">
        dc.l    ox<xsl:apply-templates select="parent::node()" mode="prefix"/>_<xsl:value-of select="concat(name(),',',.)"/>
  </xsl:template>
  <xsl:template match="@senschar" mode="tags">
        dc.l    oxChkA_senschar,"<xsl:value-of select="."/>"
  </xsl:template>
  <xsl:template match="@RELPTR" mode="tags">
        dc.l    OX_<xsl:value-of select="concat(name(),',',.)"/>
  </xsl:template>
  <xsl:template match="@title|@text" mode="tags">
        dc.l    ox<xsl:apply-templates select="parent::node()" mode="prefix"/>_<xsl:value-of select="concat(translate(name(),
        'abcdefghijklmnopqrstuvwxyz','ABCDEFGHIJKLMNOPQRSTUVWXYZ'),
        ',.',name(),generate-id())"/>
  </xsl:template>
  <xsl:template match="*" mode="ref">
        dc.l    OX_<xsl:value-of select="concat(name(),',.',name(),generate-id())"/>
  </xsl:template>
  <xsl:template match="MENU/ITEM|ITEM/ITEM" mode="ref">
        dc.l    ox<xsl:apply-templates select="parent::node()" mode="prefix"/>_item,.<xsl:value-of select="concat(name(),generate-id())"/>
  </xsl:template>
  <xsl:template match="*" mode="strings">
  <xsl:for-each select="@title|@text">
.<xsl:value-of select="concat(name(),generate-id())"/>
        dc.b    "<xsl:value-of select="."/>",0</xsl:for-each>
    <xsl:apply-templates mode="strings"/>
  </xsl:template>
  <!-- tag id prefixes -->
  <xsl:template match="WINDOW" mode="prefix">WA</xsl:template>
  <xsl:template match="HORIZ|VERT" mode="prefix">GA</xsl:template>
  <xsl:template match="FRAME" mode="prefix">FrA</xsl:template>
  <xsl:template match="TITLE" mode="prefix">TA</xsl:template>
  <xsl:template match="PLANEVIEW" mode="prefix">???????</xsl:template>
  <xsl:template match="CHECK" mode="prefix">ChkA</xsl:template>
  <xsl:template match="LABEL" mode="prefix">LabA</xsl:template>
  <xsl:template match="MENU" mode="prefix">MA</xsl:template>
  <xsl:template match="ITEM" mode="prefix">MIA</xsl:template>
  <!-- ignore text pi and so on -->
  <xsl:template match="node()" mode="ref" priority="-1"/>
  <xsl:template match="node()" mode="tags" priority="-1"/>
  <xsl:template match="node()" mode="strings" priority="-1"/>
</xsl:stylesheet>

---

[ - Antworten - Zitieren - Direktlink - ]

m68k include code:

---

STRUCTURE	oxmlEntity,0
	STRUCT	oxmlE_Node,MLN_SIZE
	APTR	oxmlE_TagName
	STRUCT	oxmlE_AttrList,MLH_SIZE
	STRUCT	oxmlE_EntitiesList,MLH_SIZE
	LABEL	oxmlE_SIZEOF

 STRUCTURE	oxmlAttr,0
	STRUCT	oxmlA_Node,MLN_SIZE
	APTR	oxmlA_Name
	APTR	oxmlA_Data
	LABEL	oxmlA_SIZEOF

---

XML code:

---

<ENTITY name="MENU" prefix="M" allowobjects="false" allow="MENU/SEPARATOR, MENU/ITEM">
	<ATTR name="popup" type="bool" />
	<ATTR name="hook" type="label" />
</ENTITY>

<ENTITY name="MENU/SEPARATOR" type="noclose"></ENTITY>

<ENTITY name="MENU/ITEM" prefix="MI" allow="MENU/SEPARATOR, MENU/ITEM" allowobjects="false">
	<ATTR name="text" type="string" />
	<ATTR name="ID" type="number" />
	<ATTR name="exclude" type="words" />
</ENTITY>

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von AGSzabo:
...ich glaube, daß es der Einfachkeit halber für meine Zwecke völlig ausreicht, das einfache Schema wie ich darstellte zu verwenden. Imo wird das ebenso von gewissen tools unterstützt, glaube ich.

---

Zitat:

---

Sowohl für das Schema als auch für die GUI definitionen kann ich, bevor ich die Inhalte auswerte, alles in strukturen lesen, ...

---

Zitat:

---

Dafür gibts vielleicht sogar schon ne library?

---

[ - Antworten - Zitieren - Direktlink - ]

XML code:

---

<ENTITY name="MENU" prefix="M" objects="0">  <!-- false=0=none, yes=true=-1, 1-n -->
	<ATTR name="popup" type="bool" />
	<ATTR name="hook" type="label" />
	<ENTITY name="SEPARATOR" private="true" close="false"></ENTITY>
	<ENTITY name="ITEM" private="true" prefix="MI" objects="none" recursive="true">
		<ATTR name="text" type="string" />
		<ATTR name="ID" type="number" />
		<ATTR name="exclude" type="words" />
	</ENTITY>
</ENTITY>

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Thore:
Du kannst auch ein Parent Parameter einführen, z.B.
<ENTITY name="ITEM" parent="MENU" ....

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von AGSzabo:

XML code:

---

<ENTITY name="MENU" prefix="M" objects="0">  <!-- false=0=none, yes=true=-1, 1-n -->
	<ATTR name="popup" type="bool" />
	<ATTR name="hook" type="label" />
	<ENTITY name="SEPARATOR" private="true" close="false"></ENTITY>
	<ENTITY name="ITEM" private="true" prefix="MI" objects="none" recursive="true">
		<ATTR name="text" type="string" />
		<ATTR name="ID" type="number" />
		<ATTR name="exclude" type="words" />
	</ENTITY>
</ENTITY>

---

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

XML code:

---

<ENTITY name="VERT" RULES="HORIZ">

---

[ - Antworten - Zitieren - Direktlink - ]