Zitat:

---

Original von hjoerg:
Kein Mensch wird dort seine wichtigen Daten speichern ohne Kopien zu besitzen.

---

Zitat:

---

Original von _PAB_:
Was soll denn diese "Cloud" in der Realität überhaupt sein, fragt sich das niemand?
Letztenendes sind es Web-Applikationen, wie wir sie schon aus dem letzten Jahrtausend kennen!

---

Zitat:

---

Original von _PAB_:
Ist aber auch überflüssig, weil Lottokugeln schlicht kein Gedächtnis haben und sich nicht merken können, wie oft sie schonmal gezogen wurden oder ob sie in einer Reihe mit anderen Zahlen auf dem Schein stehen würden...

---

Zitat:

---

Letztlich ist aber auch völlig klar, dass man im Mittel nur verlieren kann, denn Lotto ist ein großer magischer Kasten in den eine Summe von XYZ Millionen pro Spielrunde reingesteckt wird und wovon nur ca. XYZ/2 Millionen wieder ausgezahlt werden.

---

Zitat:

---

Original von _PAB_:
Ich habe mit 16 mal ausführliche Simulationen zu dem Thema gemacht und versucht ein Lotto-System und Roulette-System zu programmieren.

---

Zitat:

---

Original von AGSzabo:
Was genau muß ich lernen und in welcher Reihenfolge?

---

Hey, wer hat denn was von „müssen“ gesagt?

Sind doch nur Empfehlungen und die sind auch frei von irgendeiner Reihenfolge. Ich hab sie auch schon genannt.

Das eine Thema ist XSL(T), um XML-Dateien mit bestehenden Tools umwandeln zu können. Dokumentation und Tutorials findet man zuhauf, wenn man sucht, z.B. auch hier: http://de.selfhtml.org/xml/darstellung/index.htm

Ein mögliches Zwischenziel könnte es sein, die von mir geposteten Beispiele verstehen zu können. Ab da kann man sie auch für eigene Zwecke erweitern. (Natürlich auch gerne hier Fragen stellen)

Interessant dürfte das vielleicht auch insofern für Dich sein, dass Du dann auch bemerkst, wo Dein XUI-API Design die Komplexität bei der Umwandlung in die Höhe treibt. Diese Komplexität trifft Dich teilweise auch dann, wenn Du den Prozess in einem eigenen Programm abbilden wolltest, statt einen XSLT-Prozessor zu verwenden.

Das zweite Thema ist, wie man seine eigene XML-Sprache formal deklariert. Da gibt es zwei Möglichkeiten, DTD und Schema. Ersteres ist weniger komplex und auch weniger mächtig, hat aber vor allem den Nachteil, nicht XML zu sein. Schema ist dagegen äußerst leistungsfähig, dementsprechend komplexer, entspricht aber, wie bereits gesagt, in Grundzügen dem, wie Du es auch selbst gemacht hättest.

Ich denke, Du findest schon passendes Material, wenn Du danach googlest.

Zitat:

---

Und steht es mir frei kleine Abwandlungen vor zu nehmen, wenn mit dem gegebenen etwas nicht so möglich ist wie ich es brauche?

---

Zitat:

---

Original von AGSzabo:
Aber schau mal: wenn meine Mutter ein Kreutzworträtsel macht, schaut sie dann gleich in der Lösung nach?

---

Zitat:

---

Und wenn es schon zwei Bibliotheken zum parsen von xml gibt, warum nicht auch noch eine dritte?

---

Zitat:

---

In 68k Assembler zu programmieren und noch tools dafür zu entwickeln ist sowieso eine brotlose kunst.

---

Zitat:

---

So eine konformität zum autocomplete wäre aber nett. Ich weiss leider nicht bescheid.

---

Zitat:

---

Original von AGSzabo:
Namen sind imo nicht so wichtig. Ich sehe nicht ein, warum ich mich da an Schema halten soll.

---

Zitat:

---

Original von cgutjahr:

Zitat:

---

...
Vorschlag Nummer 4: Anonyme Kommentare werden grundsätzlich erst nach Sichtung durch Moderator freigeschaltet

---

Zu Punkt vier wäre allerdings noch zu ergänzen, dass das für anonyme Poster vermutlich deutlich Verzögerungen geben würde, da die beiden verbliebenen Moderatoren nicht gerade über zu viel Zeit verfügen.

---

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>

---

---

Zitat:

---

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

---

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?

---

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>

---

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

---

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.

---

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

---

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.

---

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

---

Zitat:

---

Original von schluckebier:
Ich weiß, dass tploetz ein Problem mit aussagekräftigen Fehlerbeschreibungen hat, ...

---

Zitat:

---

Original von Honitos:
Unter Windows läuft hier übrigens auch ein Widget und nicht der Browser...

---

Zitat:

---

Original von _PAB_:
Ebenso ist diese Äußerung auch volkswirtschaftlich richtig, wenn man bedenkt, dass es mehr auszuzahlen gibt, wenn länger eingezahlt wird. (Angenommen die Anhebung erhöht tatsächlich die Einzahlungen.)

---

Zitat:

---

Original von Bluebird:
@Holger: Ab 3.5 oder 3.1 mit Deficons sollte das kein Problem sein, die Deficons liegen ja im ENV auch fuer Volumes , wenn man da den Icon fuer eine Position speichert bleibt er immer am selben Platz wenn ein zb CD1 gemountet wird ...

---

Zitat:

---

Aber wie gesagt ich hab nur Kick/WB 2.1 ob Deficons damit schon laeuft ...

---

Zitat:

---

k.a, aber verschiedene CDFS moechte ich shcon wegen dem Ram Verbrauch und vielleicht Leistungsverlust der CPU vermeiden ...

---

Zitat:

---

PS: der 6 byte Cache des 68010 kann man nicht wirklich nutzen oder ? C:CPU meint mein nur Inst NoCache

---

Zitat:

---

Original von Honitos:
gibt es eigentlich einen bracuhbaren Facebook-Client für OS3.x/4.x ?

---

Zitat:

---

Original von thomas:
@Bluebird:
AmigaDOS unterscheidet überhaupt nichts anhand des Dateisystems.

---

Zitat:

---

Original von _PAB_:
@Maja:
Es ist unumstößlicher Fakt, dass man mehr Rente bekommt, wenn man bis 67 arbeitet, als wenn man mit 65 aufhören würde.

---

Zitat:

---

Nichts anderes hat der Politiker (bei genauem Hinsehen) gesagt.

---

Zitat:

---

Das ist eben die "Kunst" in der Politik (=Leute verarschen).

---