Entwicklung alternatives CMS Auszeichnungsformats

nikosch · 23.02.2009, 20:07

Hallo Leute,

Da ich zur Zeit mehrere Sachen mit einem CMS umsetze, schreibe ich aktuell an einem alternativen Auszeichnungsformat, das an Wikicode und Textile angelehnt ist.

Ich möchte in diesem Thread

1. Die gezeigten Formatierungsregeln zur Diskussion stellen
2. weitere Anregungen sammeln
3. eine kleine Knobelaufgabe stellen (siehe unten)

Bevor Ihr fragt, wozu "noch ein weiterer bbCode-Parser" (obgleich wie gesagt eher Wikicode/Textile-verwandt), hier ein paar Argumente/Features, die in jedem Fall umgesetzt werden:

1. Neue Listenformatierung
Mir fehlte die Möglichkeit, Absätze und beliebige Verschachtelungen in Listen umzusetzen. Imho ist das Wiki-Format inkonsistent und nicht ausschöpfend. Syntax siehe unten. Konkret benutze ich bspw. für Menüs oft:

Code:

<ul>
<li><p>Menüpunkt</p>
    <ul>
    <li>Untermenüpunkt 1</li>
    <li>Untermenüpunkt 1</li>
    </ul>
</li></ul>

, für Inhalte oft (CSS-seitig none-bullet-gestylt):

Code:

<ul>
<li><ul>
    <li>Inhalt</li>
    </ul>
<li><ul>
    <li>Inhalt</li>
    <li>Inhalt</li>
    </ul>
</li></ul>

o.ä. Beide Formate ließen sich bisher nicht hinreichend mit gegebenen Sprachen umsetzen.

2. Userverständliche Überschriftensystematik
Nur mit Grundverständnis für Html ist es imho logisch, dass 1er Überschriften als = Überschrift Ebene 1 = und 2er als == Überschrift Ebene 2 == dargestellt werden. In einem Textkontext ist das imho keineswegs intuitiv. Vgl.:

Code:

== Vorspeisen ==
=== Rote Grütze ===
==== traditionelle Art ====

vs.

Code:

===== Vorspeisen        ===================
 ==== Rote Grütze       =========
  === traditionelle Art ===

(die verlängerten End'tags' sind Teil meiner Syntax.)

3. Inline Formate
Das Wikiformat ist umständlich (Zähl' die Hochkommata!)

4. Erweiterbarkeit und Parameterisierbarkeit (konkrete Angabe erlaubter Tags).

5. Korrekte Absatzbildung
<p> um Fließtext, keine <p> um Blockelemente wie Listen ...

Momentan wurde folgende Basissyntax umgesetzt, reduzierte aber imho sehr intuitive Auszeichnungselemente. Die erzielte Syntax ist darauf angelegt, semantisches Html zu erzeugen, Tabellen und Bilder wurden bisher nicht umgesetzt.

Inline (nicht blockübergreifend):

Code:

// beliebiger Text //       betonter Text (<em>, i.A. kursiv)

-- beliebiger Text --       gestrichener Text (<del>, i.A. durchgestrichen) 

++ beliebiger Text ++       ergänzter Text (<ins>)

__ beliebiger Text __       untergestrichener Text (Ich weiß, das ist nicht semantisch :))
 
** beliebiger Text **       besonders betonter Text (strong) 
 
"" beliebiger Text  ""      Zitat

Links:

Code:

"freier Linktext":http://...     auch andere Protokolle

in Kombination mit obigen Inline-Tags:

**freier Text**:http://...       <a href=""><strong>freier Text</strong></a>

URI's werden als erstes im Quelltext (aber erst nach preformats) geparst, somit wäre per Parsereinstellung auch eine automatische Verlinkung möglich.

Blöcke:

Code:

2 Leerzeilen bilden einen Absatz

 =====Headline=====   big    (h2)      für alle: Endzeichen beliebig verlängerbar
 ====Headline====     large  (h3)
 ===Headline===       medium (h4)
 ==Headline==         normal (h5)
 
 ====  (fette Trennlinie, Zeichen 4+)
 ----  (dünne Trennlinie, Zeichen 4+)


Liste als Kombination aus:

* Bullet Aufzählung
# num. Aufzählung
> Absatz eines Listenelements / Fortführung einer Unterstruktur

Bsp.

*   Käfer
>*    Borkenkäfer
>*    Gelbrandkäfer
>>    Vorwiegend in wasserreichen Gegenden beheimatet
>>    Der Gelbrandkäfer ist der zweitgrößte Käfer unserer heimischen...
*   Fische
>*    Barsch
>>    In heimischen Gewässern findet man u.a.
>>#     Rotbarsche
>>#     Flussbarsche

Vergl. Wikisyntax:

*   Käfer
**    Borkenkäfer
**    Gelbrandkäfer<br>Vorwiegend in wasserreichen Gegenden beheimatet<br>Der Gelbrandkäfer ist der zweitgrößte Käfer unserer heimischen...
*   Fische
**    Barsch<br>In heimischen Gewässern findet man u.a.
**#     Rotbarsche
**#     Flussbarsche

Code

Code:

 ##   Inline Text, vorformatiert, nicht blockbildend   ##
 
 ##:php   Inline Code, hier PHP, andere Sprachen wenn parser vorhanden    ##
 
 
 [[

 Vorformatierter Text

 ]]


 [[:php

 formatierter php Code 
 dito andere Sprachen wenn parser vorhanden

 ]]

Blocksyntax ist theoret. für beliebige Zwecke einsetzbar.

Last but not least was zu knobeln für den gelangweilten, aber motivierten Programmierer. Die obige Listensyntax ist m.E. nicht trivial (Euer Anspruch kann sein, mich Lügen zu strafen). Letzten Endes habe ich das Problem aber gelöst (mehrfach, eine Variante, die nur einen Bulletstil unterstützt, war noch relativ einfach, Kombination von ul und ol Listen, dann nicht mehr). Wer sich dran versuchen möchte - ich habe etwa ein Wochenende gebraucht - hier die Syntax:

jedes * oder # erzeugt ein Listenelement, das jeweils erste der Tiefe natürlich auch die Liste (* eine ul, # eine ol Liste)
jede kürzere Zeile (im Vergleich zum Vorgänger) schließt die entspr. Tiefenstrukturen
jedes > erzeugt einen Absatz oder verlängert das Listenelement
jeder Offset des Quelltextes entspricht der Tiefenschachtelung des Elements
jede Zeile erzeugt ein neues Listenelement, einen neuen Absatz oder eine neue Tiefenstruktur
Schwer zu beschreiben, hier ein Beispiel:

Code:

*  A
*  B
>  B Absatz2
>* B Unterlement
>  zurück in B
>* B Unterlement 1
>* B Unterlement 2
>> B Unterlement 2, Absatz 2
># B Unterlement 1 neue Liste
>  B Fortsetzung
*  C
# A numerisch

erzeugt (händisch eingerückt):

Code:

<ul><li><p>A</p></li>
    <li><p>B</p>
        <p>B Absatz2</p>
        <ul>
          <li><p>B Unterlement</p></li>
        </ul>
        <p>zurück in B</p>
        <ul>
          <li><p>B Unterlement 1</p></li>
          <li><p>B Unterlement 2</p>
              <p>B Unterlement 2, Absatz 2</p>
          </li>
        </ul>
        <ol>
          <li><p>B Unterlement 1 neue Liste</p></li>
        </ol>
        <p>B Fortsetzung</p>
    </li>
    <li><p>C</p></li>
</ul>
<ol><li><p>A</p></li>
</ol>

Ach ja, 2 spezielle Fälle:

1. Alle > tiefer als ihr Vorgänger in der letzten Zeile werden zu *

2.

Code:

*  A
** B

erzeugt auch zwei in sich verschachtelte Listen (anders als in der Wikisyntax), also:

Code:

<ul><li>A</li>
    <li>
    <ul><li>B</li></ul>
    </li>
</ul>

Ist ne schöne Knobelaufgabe, wäre gespannt, wie jemand das alternativ lösen würde...

agrajag · 23.02.2009, 22:03

Ehrlich gesagt finde ich deine Syntax für Überschriften sehr unglücklich gewählt. Nicht nur, dass ich es andersrum viel intuitiver finde, es ist auch praktischer. Möchte ich bei dir ein h1 muss ich erst überlegen wieviele "=" ich nun tippen muss. Warum es für jemanden ohne HTML-Background nun logischer sein soll

Code:

======Headline======

statt einfach nur

Code:

 = Überschrft =

zu tippen erschließt sich mir nicht. Wie soll derjenige ausgerechnet auf 6 Gleicheitszeichen kommen?

Ich finde das in Markdown oder Textile schöner gelöst:

Code:

h1. Headline
# Headline
# Headline #

Headline
=========

Klappt alles.

Ansonsten sieht das schon ok aus. Ich weiß nicht ob das jetzt wirklich mehr kann als Textile/Markdown. Die beiden verstehen sich ja auch eher als Ergänzung zu HTML und nicht als Ersatz....

Und für die Kobelaufgabe bin ich zu faul, da würde ich ewig dransitzen

Manko10 · 23.02.2009, 22:15

Bei den Headlines kann ich agrajag zustimmen, die herkömmliche Wikisyntax ist da klarer. Zum einen ist es schnell ersichtlich, dass eine Überschrift erster (!) Ordnung auch ein (!) = bekommt und nicht sechs (letzteres widerspricht jeglicher Logik und ist schwer zu merken). Des Weiteren sieht eine Hierarchie mit dieser Syntax schon wie ein Outline aus:

Code:

= H1 =
== H2 ==
=== H3 ===
==== H4 ====
===== H5 =====
====== H6 ======

vs.

Code:

====== H1 ======
===== H2 =====
==== H3 ====
=== H4 ===
== H5 ==
= H6 =

Bei letzterem ist nicht ersichtlich, warum H6 weiter außen ist, als H1 (Blockmodell).
An der Knobelaufgabe versuche ich mich mal, wenn wider Erwarten Zeit und Lust dazu da sein sollten.

nikosch · 23.02.2009, 22:20

Naja gut Markdown/ReStructuredText ist wieder ne andere Liga, die einerseits zu umfangreich, andererseits zu technisch für den Endanwender ist.

Markdown kannte ich noch nicht, schaue ich mir mal an. Zumindest den Zitate-Block klaue ich vielleicht (die Anlehnung an Email-Zitate ist nachvollziehbar) - obwohl die Syntax mit der Listenlogik nicht ganz kompatibel anmutet, wohl doch eher nicht.
Wie gesagt, mir gehts nicht um einen Ersatz von HTML sondern allenfalls eben Textile. HTML weiter zuzulassen ist ja kein Problem. Aber die konkreten Probleme nerven mich bei Textile. Z.B. kann man da nie (mit Textile-Stil) eine Überschrift in einem Listelement setzen. Nun kann ich schlecht von Kunde Endanwender verlangen, da jetzt html zu benutzen. Finde ich weltfremd.

Aber danke für die Meinung zu den Überschriften. Über die 5-als-Anfang Problematik habe ich noch nie nachgedacht. Da ist natürlich was dran. Aber ich finde, am Ansatz, dass die meisten Pdeudoredakteure von Office kommen, wo mehr auch mehr bedeutet, ist auch nicht ganz von der Hand zu weisen. Zumal optisch die große Überschrift mit vielen = sich auch deutlicher absetzt. Ich schätze wir sind etwas html-verseucht. Muß ich noch grübeln. Aber h1. finde ich jetzt auch nicht so prickelnd.

PS: Auch Dir danke, Manko.

Manko10 · 23.02.2009, 22:30

Andere Möglichkeit: du arbeitest mit Einrückungen:

Code:

= H1 =
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor
invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.

    = H2 =
    At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren,
    no sea takimata sanctus est Lorem ipsum dolor sit amet.
    
        = H3 =
        Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod
        tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua.
        
    = H2 =
    At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren,
    no sea takimata sanctus est Lorem ipsum dolor sit amet.

Aber das ist auch sehr aufwendig und vor allem mit normalen Textareas kaum zumutbar.

P.S. nur zur Info: in beiden Posts dienen die Bezeichner H[1-6] nur zur Verdeutlichung und sind natürlich frei wählbar.

nikosch · 23.02.2009, 22:40

Also das überzeugt jetzt wirklich nicht

Da würde ich eher noch ne Struktur durch Parsen der Nummern von Überschriften erzeugen. Nur leider sind nicht alle Überschriften numeriert.

Man muß auch sehen, dass sich viele dieser "positionsbezogenen" Auszeichnungen - 3 Leerzeichen = Einrücken, etc. - noch sehr an Konsole, 80 Zeichen o.ä. orientieren und zwingend diktengleiche Editorschriftarten quasi erfordern. Davon will ich eigentlich weg, wenn man auf diesem Niveau arbeitet, dann stören einen auch kryptische Tags oder Pseudotags nicht besonders. Natürlich ist das nicht vollends möglich, aber mal sehen, wie weit diese Zielsetzung führt. Letztlich bleibts ja eh ne Krücke für eine Uralt-Technologie namens textarea.

Chriz · 24.02.2009, 00:30

Ich weiß garnicht was Textile ist, aber am einfachsten ist doch immernoch WYSIWYG oder?

Einen anderen Ansatz, den ich einmal verfolgt hatte aber wegen der Komplexität fallen gelassen hatte war ein Template-basierter Aufbau, ähnlich eines DOM-Baumes. Ich habe verschiedene, editierbare, möglicherweise von einander erbende Container. Wenn der Fokus auf einem dieser Container ist, kann das Element bearbeitet werden. Das könnte für einen Text-Container ein <textarea> sein, ebenso wie für eine Headline. Ein Container hat einen bestimmten Typ und in diesem Typ können nur bestimmte andere Typen abgelegt werden. Eine Liste kann beispielsweise nicht in eine Headline gelegt werden. Verliert man den Fokus (blur) wird die editierbare Eingabe in eine starre Ausgabe mit HTML/CSS umgewandelt. So sieht man (fast) direkt was man bearbeitet und hat trotzdem noch die strukturelle Kontrolle über die Eingaben. Um die Eingabe nicht runterzubrechen auf ihren Aufbau in HTML-Knoten könnte man für die Texteingabe einen rudimentären WYSIWYG Editor verwenden, der Texte unterstreichen, kursiv stellen oder fett schreiben kann.

Natürlich verliere ich durch dieses Baukastenprinzip eventuell den Schreibfluß, *klick* Überschrift anlegen, *klick* Textblock anlegen, *klick* Media-Daten hinzufügen .. aber stehts bleibt die Kontrolle bei dir und wenn du Seiten-Templates anlegst, also verschachtelte Blöcke klickst du eigentlich auch nur relativ wenig herum.

Weil ich langsam etwas fitter im Umgang mit YUI werde werde ich die Sache vielleicht bald selbst mal angeben, mit Drag & Drop und ein paar onmouseover-Effekten läßt sich da denke ich schon ein halbwegs vernünftiger Word-Baukasten erstellen.

Grafisch denke ich da an soetwas:
YAML Builder | A tool for visual development of YAML based CSS layouts

Mir persönlich ist diese erfundene Wiki-Syntax zu kompliziert (man mags kaum glauben) was auch der Grund ist, warum ich ganz ganz selten im Wiki editiere. Und Drag & Drop und ein bißchen getippe, ja da wären wir bei Word und den DAUs (wie mir) die andere Sachen einfach nicht kapieren. Schliesslich musst du ja noch Fehlerkontrolle oder eine Art Tidy einbauen und das könnte ja relativ haarig werden. Und beim Baukasten-Prinzip a la Visual Basic ich klick mir meine Fensterapplikation zusammen waren wir doch alle unglaublich fasziniert und glücklick oder? Natürlich nicht auf Dauer, weil wir uns vielleicht weiterentwickeln wollten - aber ich glaube nicht dass die Bürotante bald VBSkripte schreibt um ihre Dokumente zu generieren. Das heißt hier könnte man wirklich DAUs (nicht mal im negativen Sinne) glücklich machen.

nikosch · 24.02.2009, 00:39

Und wieder den Accent verwendet. Menno!

Das beschriebene Konzept finde ich auch toll (v.a. zum Editieren). Das Blockprinzip finde ich gar nicht so problematisch. Ich stelle mir (habe das auch schon mal auf dem Plan gehabt, na Coop eingehen?) da eine Ersteingabe als Fließtext vor, die dann manschinell geparst und in sinnvolle Brocken zerlegt werden würde.

Allerdings gehts mir hier konkret um eine Sprache für ein (fremdes) CMS und einen entspr. Texteditor. Wysiwyg finde ich total untoll, weil dem Nutzer da jede Menge Spielerchen an die Hand gegeben werden, die man per CSS nicht mehr sinnvoll vordefinieren kann. Gib einem Nutzer einen Wysiwyg-Editor und Du kannst Deine Layout vergessen, während er sich in seinen ganzen Pseudoauszeichnungen verheddert und nicht mehr weiß, warum der untersrichene Text eben kein Link mehr ist. Überschriften werden als bold mißbraucht, eingerückt wird per Leerzeichen. Nee danke, dann lieber etwas begrenztes, wo manches dann halt einfach nicht geht. Insgesamt strebe ich ein semantisches Konzept an, wo weniger mehr ist. Gerade Listen benutze ich sehr oft, weshalb auf ihnen auch das Hauptaugenmerk des neuen Formats liegt. Ob ich überhaupt Tabellen benutze oder notfalls die Auszeichnung nur als Pre-Hack für Textile verwende, entscheide ich je nach dem, wie weit sich das entwickelt.

Btw: Was ist ein Tidy?

[edit]
Oh Chriz, denke ich an JS und Blockediting schwebt mir da gerade ein wunderschönes Interface im Kopf rum. Schade dass ich gerade wenig Zeit habe. Mal sehen ob ich wenigstens mal einen Prototyp oder eine graph. Skizze hinbekomme.
Interesse, da irgendwann mal wieder einzusteigen?

Chriz · 24.02.2009, 10:51

Ich leb in meiner eigenen Sprachwelt - sorry

Ich meinte soetwas:
HTML Tidy – Wikipedia

Zitat:

HTML Tidy ist ein Computerprogramm, das dabei hilft, ungültige HTML-Tags zu erkennen und diese Fehler durch Entfernen bzw. Einfügen der fehlenden Tags zu beheben.

Das als Gemeinschaftsprojekt mal anzugehen fänd ich ne feine Sache, im Moment hab ich sogar etwas Luft, Klausuren rum, Projektdeadline gemeistert. Können ja mal ein SVN-Repository aufmachen. Wäre sogar halbwegs einfach zu trennen in JavaScript-, PHP- und Datenbank-Bereich. Ich schick dir mal meine ICQ Nummer.

Chriz · 26.02.2009, 00:19

Mini Prototyp mit ein bißchen Drag & Drop:
http://www.antiphp.de/test/template/

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
cms	Anti	Beitragsarchiv	0	31.01.2009 22:10
Bildupload in CMS funktioniert nicht	soffi	PHP Tipps 2009	18	10.01.2009 18:24
Was stellt Ihr euch bei einem CMS an funktionen vor???	djscaleo	PHP Tipps 2009	4	05.01.2009 21:28
CMS mit Framework	KeKs0r	PHP-Fortgeschrittene	11	27.12.2008 23:03
für privat: PHP Entwicklung in Indien ?	mrmojo	Off-Topic Diskussionen	5	23.11.2008 18:38
Projekt sucht für Teilbereiche Schüler o.ä. für PHP OOP Entwicklung gegen Bezahlung	mrmojo	Beitragsarchiv	0	20.11.2008 23:41
HTML/CSS Page als CMS	diamond_t	PHP Tipps 2008	22	02.10.2008 17:02
CMS Entwickler gesucht!	dellyd	Beitragsarchiv	9	18.09.2008 16:40
CMS bearbeiten-script funktioniert nicht	soffi	PHP Tipps 2008	19	11.09.2008 11:42
CMS: Ordnerstruktur(en)	myPages	HTML, Usability und Barrierefreiheit	4	11.09.2008 11:29
Literatur zur Entwicklung von Enterprise Projekten gesucht	Nadir	PHP-Fortgeschrittene	20	18.06.2008 21:46
WEB Entwicklung &amp; mehrere Programmierer		Server, Hosting und Workstations	6	02.12.2006 22:48
Suche Partner zur Entwicklung eines Portals		Beitragsarchiv	3	03.04.2005 19:05

23.02.2009, 20:07
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.987 PHP-Kenntnisse: Fortgeschritten	Entwicklung alternatives CMS Auszeichnungsformats Hallo Leute, Da ich zur Zeit mehrere Sachen mit einem CMS umsetze, schreibe ich aktuell an einem alternativen Auszeichnungsformat, das an Wikicode und Textile angelehnt ist. Ich möchte in diesem Thread 1. Die gezeigten Formatierungsregeln zur Diskussion stellen 2. weitere Anregungen sammeln 3. eine kleine Knobelaufgabe stellen (siehe unten) Bevor Ihr fragt, wozu "noch ein weiterer bbCode-Parser" (obgleich wie gesagt eher Wikicode/Textile-verwandt), hier ein paar Argumente/Features, die in jedem Fall umgesetzt werden: 1. Neue Listenformatierung Mir fehlte die Möglichkeit, Absätze und beliebige Verschachtelungen in Listen umzusetzen. Imho ist das Wiki-Format inkonsistent und nicht ausschöpfend. Syntax siehe unten. Konkret benutze ich bspw. für Menüs oft: Code: <ul> <li><p>Menüpunkt</p> <ul> <li>Untermenüpunkt 1</li> <li>Untermenüpunkt 1</li> </ul> </li></ul> , für Inhalte oft (CSS-seitig none-bullet-gestylt): Code: <ul> <li><ul> <li>Inhalt</li> </ul> <li><ul> <li>Inhalt</li> <li>Inhalt</li> </ul> </li></ul> o.ä. Beide Formate ließen sich bisher nicht hinreichend mit gegebenen Sprachen umsetzen. 2. Userverständliche Überschriftensystematik Nur mit Grundverständnis für Html ist es imho logisch, dass 1er Überschriften als = Überschrift Ebene 1 = und 2er als == Überschrift Ebene 2 == dargestellt werden. In einem Textkontext ist das imho keineswegs intuitiv. Vgl.: Code: == Vorspeisen == === Rote Grütze === ==== traditionelle Art ==== vs. Code: ===== Vorspeisen =================== ==== Rote Grütze ========= === traditionelle Art === (die verlängerten End'tags' sind Teil meiner Syntax.) 3. Inline Formate Das Wikiformat ist umständlich (Zähl' die Hochkommata!) 4. Erweiterbarkeit und Parameterisierbarkeit (konkrete Angabe erlaubter Tags). 5. Korrekte Absatzbildung <p> um Fließtext, keine <p> um Blockelemente wie Listen ... Momentan wurde folgende Basissyntax umgesetzt, reduzierte aber imho sehr intuitive Auszeichnungselemente. Die erzielte Syntax ist darauf angelegt, semantisches Html zu erzeugen, Tabellen und Bilder wurden bisher nicht umgesetzt. Inline (nicht blockübergreifend): Code: // beliebiger Text // betonter Text (<em>, i.A. kursiv) -- beliebiger Text -- gestrichener Text (<del>, i.A. durchgestrichen) ++ beliebiger Text ++ ergänzter Text (<ins>) __ beliebiger Text __ untergestrichener Text (Ich weiß, das ist nicht semantisch :)) beliebiger Text besonders betonter Text (strong) "" beliebiger Text "" Zitat Links: Code: "freier Linktext":http://... auch andere Protokolle in Kombination mit obigen Inline-Tags: freier Text:http://... <a href=""><strong>freier Text</strong></a> URI's werden als erstes im Quelltext (aber erst nach preformats) geparst, somit wäre per Parsereinstellung auch eine automatische Verlinkung möglich. Blöcke: Code: 2 Leerzeilen bilden einen Absatz =====Headline===== big (h2) für alle: Endzeichen beliebig verlängerbar ====Headline==== large (h3) ===Headline=== medium (h4) ==Headline== normal (h5) ==== (fette Trennlinie, Zeichen 4+) ---- (dünne Trennlinie, Zeichen 4+) Liste als Kombination aus: * Bullet Aufzählung # num. Aufzählung > Absatz eines Listenelements / Fortführung einer Unterstruktur Bsp. * Käfer >* Borkenkäfer >* Gelbrandkäfer >> Vorwiegend in wasserreichen Gegenden beheimatet >> Der Gelbrandkäfer ist der zweitgrößte Käfer unserer heimischen... * Fische >* Barsch >> In heimischen Gewässern findet man u.a. >># Rotbarsche >># Flussbarsche Vergl. Wikisyntax: * Käfer Borkenkäfer Gelbrandkäfer<br>Vorwiegend in wasserreichen Gegenden beheimatet<br>Der Gelbrandkäfer ist der zweitgrößte Käfer unserer heimischen... * Fische Barsch<br>In heimischen Gewässern findet man u.a. # Rotbarsche # Flussbarsche Code** Code: ## Inline Text, vorformatiert, nicht blockbildend ## ##:php Inline Code, hier PHP, andere Sprachen wenn parser vorhanden ## [[ Vorformatierter Text ]] [[:php formatierter php Code dito andere Sprachen wenn parser vorhanden ]] Blocksyntax ist theoret. für beliebige Zwecke einsetzbar. Last but not least was zu knobeln für den gelangweilten, aber motivierten Programmierer. Die obige Listensyntax ist m.E. nicht trivial (Euer Anspruch kann sein, mich Lügen zu strafen). Letzten Endes habe ich das Problem aber gelöst (mehrfach, eine Variante, die nur einen Bulletstil unterstützt, war noch relativ einfach, Kombination von ul und ol Listen, dann nicht mehr). Wer sich dran versuchen möchte - ich habe etwa ein Wochenende gebraucht - hier die Syntax: jedes * oder # erzeugt ein Listenelement, das jeweils erste der Tiefe natürlich auch die Liste (* eine ul, # eine ol Liste) jede kürzere Zeile (im Vergleich zum Vorgänger) schließt die entspr. Tiefenstrukturen jedes > erzeugt einen Absatz oder verlängert das Listenelement jeder Offset des Quelltextes entspricht der Tiefenschachtelung des Elements jede Zeile erzeugt ein neues Listenelement, einen neuen Absatz oder eine neue Tiefenstruktur Schwer zu beschreiben, hier ein Beispiel: Code: * A * B > B Absatz2 >* B Unterlement > zurück in B >* B Unterlement 1 >* B Unterlement 2 >> B Unterlement 2, Absatz 2 ># B Unterlement 1 neue Liste > B Fortsetzung * C # A numerisch erzeugt (händisch eingerückt): Code: <ul><li><p>A</p></li> <li><p>B</p> <p>B Absatz2</p> <ul> <li><p>B Unterlement</p></li> </ul> <p>zurück in B</p> <ul> <li><p>B Unterlement 1</p></li> <li><p>B Unterlement 2</p> <p>B Unterlement 2, Absatz 2</p> </li> </ul> <ol> <li><p>B Unterlement 1 neue Liste</p></li> </ol> <p>B Fortsetzung</p> </li> <li><p>C</p></li> </ul> <ol><li><p>A</p></li> </ol> Ach ja, 2 spezielle Fälle: 1. Alle > tiefer als ihr Vorgänger in der letzten Zeile werden zu * 2. Code: * A ** B erzeugt auch zwei in sich verschachtelte Listen (anders als in der Wikisyntax), also: Code: <ul><li>A</li> <li> <ul><li>B</li></ul> </li> </ul> Ist ne schöne Knobelaufgabe, wäre gespannt, wie jemand das alternativ lösen würde... __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. -- Geändert von nikosch (23.02.2009 um 21:02 Uhr).


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

23.02.2009, 22:03
agrajag Moderator Registriert seit: 02.10.2006 Beiträge: 3.820 PHP-Kenntnisse: Fortgeschritten	Ehrlich gesagt finde ich deine Syntax für Überschriften sehr unglücklich gewählt. Nicht nur, dass ich es andersrum viel intuitiver finde, es ist auch praktischer. Möchte ich bei dir ein h1 muss ich erst überlegen wieviele "=" ich nun tippen muss. Warum es für jemanden ohne HTML-Background nun logischer sein soll Code: ======Headline====== statt einfach nur Code: = Überschrft = zu tippen erschließt sich mir nicht. Wie soll derjenige ausgerechnet auf 6 Gleicheitszeichen kommen? Ich finde das in Markdown oder Textile schöner gelöst: Code: h1. Headline # Headline # Headline # Headline ========= Klappt alles. Ansonsten sieht das schon ok aus. Ich weiß nicht ob das jetzt wirklich mehr kann als Textile/Markdown. Die beiden verstehen sich ja auch eher als Ergänzung zu HTML und nicht als Ersatz.... Und für die Kobelaufgabe bin ich zu faul, da würde ich ewig dransitzen __________________ Today you...Tomorrow me.

23.02.2009, 22:15
Manko10 Supermoderator HD Registriert seit: 16.03.2008 Beiträge: 8.706 PHP-Kenntnisse: Fortgeschritten	Bei den Headlines kann ich agrajag zustimmen, die herkömmliche Wikisyntax ist da klarer. Zum einen ist es schnell ersichtlich, dass eine Überschrift erster (!) Ordnung auch ein (!) = bekommt und nicht sechs (letzteres widerspricht jeglicher Logik und ist schwer zu merken). Des Weiteren sieht eine Hierarchie mit dieser Syntax schon wie ein Outline aus: Code: = H1 = == H2 == === H3 === ==== H4 ==== ===== H5 ===== ====== H6 ====== vs. Code: ====== H1 ====== ===== H2 ===== ==== H3 ==== === H4 === == H5 == = H6 = Bei letzterem ist nicht ersichtlich, warum H6 weiter außen ist, als H1 (Blockmodell). An der Knobelaufgabe versuche ich mich mal, wenn wider Erwarten Zeit und Lust dazu da sein sollten. __________________ Refining Linux Advent Calendar series “24 Outstanding ZSH Gems”

23.02.2009, 22:20
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.987 PHP-Kenntnisse: Fortgeschritten	Naja gut Markdown/ReStructuredText ist wieder ne andere Liga, die einerseits zu umfangreich, andererseits zu technisch für den Endanwender ist. Markdown kannte ich noch nicht, schaue ich mir mal an. Zumindest den Zitate-Block klaue ich vielleicht (die Anlehnung an Email-Zitate ist nachvollziehbar) - obwohl die Syntax mit der Listenlogik nicht ganz kompatibel anmutet, wohl doch eher nicht. Wie gesagt, mir gehts nicht um einen Ersatz von HTML sondern allenfalls eben Textile. HTML weiter zuzulassen ist ja kein Problem. Aber die konkreten Probleme nerven mich bei Textile. Z.B. kann man da nie (mit Textile-Stil) eine Überschrift in einem Listelement setzen. Nun kann ich schlecht von Kunde Endanwender verlangen, da jetzt html zu benutzen. Finde ich weltfremd. Aber danke für die Meinung zu den Überschriften. Über die 5-als-Anfang Problematik habe ich noch nie nachgedacht. Da ist natürlich was dran. Aber ich finde, am Ansatz, dass die meisten Pdeudoredakteure von Office kommen, wo mehr auch mehr bedeutet, ist auch nicht ganz von der Hand zu weisen. Zumal optisch die große Überschrift mit vielen = sich auch deutlicher absetzt. Ich schätze wir sind etwas html-verseucht. Muß ich noch grübeln. Aber h1. finde ich jetzt auch nicht so prickelnd. PS: Auch Dir danke, Manko. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. -- Geändert von nikosch (23.02.2009 um 22:25 Uhr).

23.02.2009, 22:40
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.987 PHP-Kenntnisse: Fortgeschritten	Also das überzeugt jetzt wirklich nicht Da würde ich eher noch ne Struktur durch Parsen der Nummern von Überschriften erzeugen. Nur leider sind nicht alle Überschriften numeriert. Man muß auch sehen, dass sich viele dieser "positionsbezogenen" Auszeichnungen - 3 Leerzeichen = Einrücken, etc. - noch sehr an Konsole, 80 Zeichen o.ä. orientieren und zwingend diktengleiche Editorschriftarten quasi erfordern. Davon will ich eigentlich weg, wenn man auf diesem Niveau arbeitet, dann stören einen auch kryptische Tags oder Pseudotags nicht besonders. Natürlich ist das nicht vollends möglich, aber mal sehen, wie weit diese Zielsetzung führt. Letztlich bleibts ja eh ne Krücke für eine Uralt-Technologie namens textarea. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. -- Geändert von nikosch (23.02.2009 um 23:08 Uhr).

24.02.2009, 00:30
Chriz Moderator Registriert seit: 11.05.2008 Beiträge: 6.267	Ich weiß garnicht was Textile ist, aber am einfachsten ist doch immernoch WYSIWYG oder? Einen anderen Ansatz, den ich einmal verfolgt hatte aber wegen der Komplexität fallen gelassen hatte war ein Template-basierter Aufbau, ähnlich eines DOM-Baumes. Ich habe verschiedene, editierbare, möglicherweise von einander erbende Container. Wenn der Fokus auf einem dieser Container ist, kann das Element bearbeitet werden. Das könnte für einen Text-Container ein <textarea> sein, ebenso wie für eine Headline. Ein Container hat einen bestimmten Typ und in diesem Typ können nur bestimmte andere Typen abgelegt werden. Eine Liste kann beispielsweise nicht in eine Headline gelegt werden. Verliert man den Fokus (blur) wird die editierbare Eingabe in eine starre Ausgabe mit HTML/CSS umgewandelt. So sieht man (fast) direkt was man bearbeitet und hat trotzdem noch die strukturelle Kontrolle über die Eingaben. Um die Eingabe nicht runterzubrechen auf ihren Aufbau in HTML-Knoten könnte man für die Texteingabe einen rudimentären WYSIWYG Editor verwenden, der Texte unterstreichen, kursiv stellen oder fett schreiben kann. Natürlich verliere ich durch dieses Baukastenprinzip eventuell den Schreibfluß, klick Überschrift anlegen, klick Textblock anlegen, klick Media-Daten hinzufügen .. aber stehts bleibt die Kontrolle bei dir und wenn du Seiten-Templates anlegst, also verschachtelte Blöcke klickst du eigentlich auch nur relativ wenig herum. Weil ich langsam etwas fitter im Umgang mit YUI werde werde ich die Sache vielleicht bald selbst mal angeben, mit Drag & Drop und ein paar onmouseover-Effekten läßt sich da denke ich schon ein halbwegs vernünftiger Word-Baukasten erstellen. Grafisch denke ich da an soetwas: YAML Builder \| A tool for visual development of YAML based CSS layouts Mir persönlich ist diese erfundene Wiki-Syntax zu kompliziert (man mags kaum glauben) was auch der Grund ist, warum ich ganz ganz selten im Wiki editiere. Und Drag & Drop und ein bißchen getippe, ja da wären wir bei Word und den DAUs (wie mir) die andere Sachen einfach nicht kapieren. Schliesslich musst du ja noch Fehlerkontrolle oder eine Art Tidy einbauen und das könnte ja relativ haarig werden. Und beim Baukasten-Prinzip a la Visual Basic ich klick mir meine Fensterapplikation zusammen waren wir doch alle unglaublich fasziniert und glücklick oder? Natürlich nicht auf Dauer, weil wir uns vielleicht weiterentwickeln wollten - aber ich glaube nicht dass die Bürotante bald VBSkripte schreibt um ihre Dokumente zu generieren. Das heißt hier könnte man wirklich DAUs (nicht mal im negativen Sinne) glücklich machen. Geändert von Chriz (24.02.2009 um 00:33 Uhr).

24.02.2009, 00:39
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.987 PHP-Kenntnisse: Fortgeschritten	Und wieder den Accent verwendet. Menno! Das beschriebene Konzept finde ich auch toll (v.a. zum Editieren). Das Blockprinzip finde ich gar nicht so problematisch. Ich stelle mir (habe das auch schon mal auf dem Plan gehabt, na Coop eingehen?) da eine Ersteingabe als Fließtext vor, die dann manschinell geparst und in sinnvolle Brocken zerlegt werden würde. Allerdings gehts mir hier konkret um eine Sprache für ein (fremdes) CMS und einen entspr. Texteditor. Wysiwyg finde ich total untoll, weil dem Nutzer da jede Menge Spielerchen an die Hand gegeben werden, die man per CSS nicht mehr sinnvoll vordefinieren kann. Gib einem Nutzer einen Wysiwyg-Editor und Du kannst Deine Layout vergessen, während er sich in seinen ganzen Pseudoauszeichnungen verheddert und nicht mehr weiß, warum der untersrichene Text eben kein Link mehr ist. Überschriften werden als bold mißbraucht, eingerückt wird per Leerzeichen. Nee danke, dann lieber etwas begrenztes, wo manches dann halt einfach nicht geht. Insgesamt strebe ich ein semantisches Konzept an, wo weniger mehr ist. Gerade Listen benutze ich sehr oft, weshalb auf ihnen auch das Hauptaugenmerk des neuen Formats liegt. Ob ich überhaupt Tabellen benutze oder notfalls die Auszeichnung nur als Pre-Hack für Textile verwende, entscheide ich je nach dem, wie weit sich das entwickelt. Btw: Was ist ein Tidy? [edit] Oh Chriz, denke ich an JS und Blockediting schwebt mir da gerade ein wunderschönes Interface im Kopf rum. Schade dass ich gerade wenig Zeit habe. Mal sehen ob ich wenigstens mal einen Prototyp oder eine graph. Skizze hinbekomme. Interesse, da irgendwann mal wieder einzusteigen? __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. -- Geändert von nikosch (24.02.2009 um 00:55 Uhr).

26.02.2009, 00:19
Chriz Moderator Registriert seit: 11.05.2008 Beiträge: 6.267	Mini Prototyp mit ein bißchen Drag & Drop: http://www.antiphp.de/test/template/