PyLucid - CMS - Forum :: View topic - neuer SyntaxParser -- Ideen, Vorschläge

FAQ

Memberlist

Usergroups

Profile

neuer SyntaxParser -- Ideen, Vorschläge
Goto page 1, 2 Next

PyLucid - CMS - Forum Forum Index -> system

View previous topic :: View next topic

Author

Message

EnTeQuAk

Joined: 22 Nov 2006
Posts: 171
Location: Berlin

Posted: Thu 08 Mar, 2007 16:22 Post subject: neuer SyntaxParser -- Ideen, Vorschläge

Ich wollte mit dir mal in die Disskussion kommen, was wir für eine "Sprache" anwenden wollen.

Der SyntaxParser, den dauCMS verwendet wird ja gerade umgeschrieben und darauf getrimmt, möglichst portabel zu sein, wodurch sich nicht nur Wiki-Markup implementieren lässt.

Also... hier besteht sehr viel Handlungsfreiraum... und man könnte auch deine tinyTextile Syntax als Plugin später wieder realisieren, um die Portabilität, zu PyLucid 0.7xx wieder zu erreichen.

Doch als Standard Markup würde ich gerne etwas anderes benutzen.

Als Beispiel sei mal die Wiki-Markup-Version von dauCMS zu sehen:

Bold, Italic, Underlined Text:

Code:

** bold ** __ underlined __ // italic //

Diese lassen sich genauso, wie alle anderen Syntaxen verschachteln und die Leerzeichen hinter den Markup-Definierern (z.B. ' ** ') sind nicht zwingend.

Noparse/Code-Blöcke
Würde ich an MoinMoin anlehnen.

Code:

{{{
hier mit lassen sich Syntaxen zeigen, da sie nicht angezeigt werden
__**// dadada //**__
}}}

Auch hier ist der Zeilenumbruch nach dem Tag nicht zwingend.

Syntaxen hervorheben... Pygments ;) --> so wie bei MoinMoin

Code:

{{{#!html
<table>
<tr>
<td>Dies wird als HTML hervorgehoben, durch Pygments</td>
</tr>
</table>
}}}

Und auch hier... der Zeilenumbruch ist nicht zwingend.
Wobei... wenn man ihn zwingend macht, kommt automatisch ne gute Struktur in das Seiten-Layout (auf der Redakteur Seite).

was gibts nocht...

Listen

Code:

* liste stufe eins
* weiter eingerückte Liste
* wieder zurück eingerückte Liste
* Liste Stufe drei (eine Stufe mehr, als die zweite)
und so weiter

Dies wird automatisch als Liste gerendert.
Mit den Zeichen, vor der Listendefinition lässt sich dann das Listen-Layout regeln. ( z.B. '-', '*' usw.)

Überschriften

Code:

= Kapitel =
== Unterkapitel ==
= Kapitel =
== Unterkapitel ==
=== Unterunterkapitel ===
==== Ebene 4 ====
===== Ebene 5 =====
====== Ebene 6 ======

Ich denke, selbsterklärend.

Wo ich mir noch nicht sicher bin, ob wir das Layout von Links und Image-Tags übernehmen wollen. Diese schauen unter dauCMS so aus:

Code:

#link[http://www.toller-link.de klickmich]

wird als

Code:

<a href="http://www.toller-link.de">klickmich</a>

gerendert.

Code:

#image[pfad/zum/Bild.jpg optionaler Alt-Text]

wird als

Code:

gerendert.

Die Links, bei 'Image' und 'Link' können sowohl absolut als auch relativ als auch eine Internet URL sein.

Im Text selber, werden einfach nur dahingeschriebene Links natürlich auch erkannt ;)

Um wieder die 'Lucid'-Tags ins Spiel zu bringen.

Mein Vorschlag währe:

Code:

#pyltag[IncludeRemote scr="http://members.ebay.de/aboutme/eBayUserName"]

zwischen den Parametern, die dem Tag übergeben werden, wird ein Semikolon genutzt. (oder einfach nur nen Leerzeichen?)

joa... Ideen, Vorschläge, Wünsche sind immer willkommen!

jens
Administrator

Joined: 12 Oct 2005
Posts: 972
Location: duisburg, germany

Posted: Thu 08 Mar, 2007 16:37 Post subject: Re: neuer SyntaxParser -- Ideen, Vorschläge

EnTeQuAk wrote:

Bold, Italic, Underlined Text
...
Noparse/Code-Blöcke
...
Listen

Das ist alles OK.

EnTeQuAk wrote:

Überschriften

Code:

= Kapitel =
== Unterkapitel ==
= Kapitel =
== Unterkapitel ==
=== Unterunterkapitel ===
==== Ebene 4 ====
===== Ebene 5 =====
====== Ebene 6 ======

Mit den kann ich mich einfach nicht anfreunden. Finde ich in Moin auch dumm. Meine sind IMHO einfacher:

Code:

h1. Kapitel
h2. Unterkapitel
h3. Unterunterkapitel
...

Aber ok, darüber lasse ich mit mir reden...

EnTeQuAk wrote:

Wo ich mir noch nicht sicher bin, ob wir das Layout von Links und Image-Tags übernehmen wollen. Diese schauen unter dauCMS so aus:

Code:

#link[http://www.toller-link.de klickmich]

...

Code:

#image[pfad/zum/Bild.jpg optionaler Alt-Text]

Ne, also das gefällt mir garnicht! Warum nicht einfach nur das:

Code:

[http://www.toller-link.de klickmich]
[pfad/zum/Bild.jpg optionaler Alt-Text]

Das zusätzliche #link und #image finde ich überflüssig. Die Links kann man nur durch die URL/Dateinamen unterscheiden. Wenn am Ende ein ".jpg", ".jpeg", ".gif" oder ".png" steht, wird es ein Bildlink. Ansonsten ein a-href

EnTeQuAk wrote:

Um wieder die 'Lucid'-Tags ins Spiel zu bringen.

Mein Vorschlag währe:

Code:

#pyltag[IncludeRemote scr="http://members.ebay.de/aboutme/eBayUserName"]

zwischen den Parametern, die dem Tag übergeben werden, wird ein Semikolon genutzt. (oder einfach nur nen Leerzeichen?)

Ne, also ich denke da sollten wir bei den bisherigen Schreibweise bleiben, siehe http://pylucid.org/phpBB2/viewtopic.php?t=124
_________________

http://www.jensdiemer.de | http://www.htfx.de | http://www.python-forum.de

jens
Administrator

Joined: 12 Oct 2005
Posts: 972
Location: duisburg, germany

Posted: Thu 14 Jun, 2007 08:29 Post subject:

Hier will ich nochmal anknüpfen... Ich mach mal eine Liste, was ich in tinyTextile ändern möchte.

Das will ich von dir übernehmen:

Code:

** bold ** __ underlined __ // italic //

Links
Mir schwebt da folgendes vor (Im Grunde die MoinMoin Variante):

Code:

[http://blabla.de Link Text]
[SeitenShortcut Link auf interne Seite]
[#AnkerName Verweis auf Anker]
[pfad/zum/Bild.jpg optionaler Alt-Text]

Also eine Syntax für alle Varianten. Das könnte so aufgelöst werden:
1. Ist fängt es an mit "XY://" ist es ein normaler href-Link.
2. Fängt es mit "#" an, wird es ein Anker-Link (also normaler href)
3. Ist es ein gültiger Pfad zu einer Datei ist es ein img-Tag.
4. Ansonsten wird es ein href-Link mit dem ersten Teil (SeitenShortcut)

Das einzige Problem, wie die internen Links also [SeitenShortcut Link auf interne Seite] bahandeln?
Ich hatte mir mal sowas überlegt:

Code:

http://MeineSeite.de/_goto/SeitenShortcut
http://MeineSeite.de/_permalink/SeitenShortcut

Also das man im MarkupPaser einfach ein Prefix vorgeben kann und er so den Link zusammen setzt.

Listen
Meine Variante sollte weg, die sah so aus:

Code:

* liste stufe eins
** weiter eingerückte Liste
* wieder zurück eingerückte Liste
*** Liste Stufe drei (eine Stufe mehr, als die zweite)

Im Grunde sollte es so wie es Moin gemacht werden (Ist übersichtlicher):

Code:

* liste stufe eins
* weiter eingerückte Liste
* wieder zurück eingerückte Liste
* Liste Stufe drei (eine Stufe mehr, als die zweite)

Wobei Moin den Letzten Punkt nicht drei Stufen einrückt, sondern es auf die zweite Stufe setzt. Kannst du mal testen: http://wiki.python.de/WikiSandkasten
Ich weiß nicht ob das ein Bug ist, oder gewollt.

Sourcecode
Sourcecode einbeziehen in die Seite möchte ich eigentlich so beibehalten wie es ist:

Code:

<code=css>
.xs {font-family:verdana,arial,helvetica,sans-serif;font-size: x-small}
.m {font-size: medium}
</code>

oder:

Code:

<code=.py>
for i in xrange(10):
print "Toll"
</code>

Also es ist egal, ob man ".py" oder nur "py" angibt. Man gibt halt die Dateiendung an...

Die Frage ist allerdings, wie der Sourcecode Dargestellt wird. Also ob Pygments genutzt wird oder nicht. Und wenn ja, wie das gehen soll...
Ich hab Pygments in tinyTextil neuerdings eingebaut: http://trac.pylucid.net/changeset/1042
Aber so super finde ich das nicht.
Die Frage ist:

TOC
Was ich in tinyTextile noch überhaupt nicht habe ist eine "Table Of Content" Funktion. Also das man eine mit Ankern versehene Tabelle mit den Überschriften aus dem Text hat.
Das wollte ich immer mal machen, hab ich aber bisher nicht.
_________________

http://www.jensdiemer.de | http://www.htfx.de | http://www.python-forum.de

EnTeQuAk

Joined: 22 Nov 2006
Posts: 171
Location: Berlin

Posted: Thu 14 Jun, 2007 10:30 Post subject:

jens wrote:

Hier will ich nochmal anknüpfen... Ich mach mal eine Liste, was ich in tinyTextile ändern möchte.

Das will ich von dir übernehmen:

Code:

** bold ** __ underlined __ // italic //

In Wombat (ehemals dauCMS, siehe http://wombat.webshox.org) haben wir noch
^^hochgestelllten Text^^
,, tiefgestellten Text ,,
und mit Backticks (geht hier auf der Tastatur nicht :'( ) monospaced Text.

Jens wrote:

Links
Mir schwebt da folgendes vor (Im Grunde die MoinMoin Variante):

Code:

[http://blabla.de Link Text]
[SeitenShortcut Link auf interne Seite]
[#AnkerName Verweis auf Anker]
[pfad/zum/Bild.jpg optionaler Alt-Text]

Also eine Syntax für alle Varianten.

Gar kein Problem. Syntaxtechnisch bereits genauso in Wombat integriert.

Jens wrote:

Das einzige Problem, wie die internen Links also [SeitenShortcut Link auf interne Seite] bahandeln?
Ich hatte mir mal sowas überlegt:

Code:

http://MeineSeite.de/_goto/SeitenShortcut
http://MeineSeite.de/_permalink/SeitenShortcut

Also das man im MarkupPaser einfach ein Prefix vorgeben kann und er so den Link zusammen setzt.

Das ist quatsch.
In Wombat haben wir das so: Wir haben eine Liste mit allen Seiten, die es gibt. Ist der Link dort zu finden, ist es sofort ein Interner Link. Ist er dort nicht zu finden, ist es ein externer. Die Überprüfung ob mit http anfäng oder nicht etc. ist quatsch, wie ich schon oft im python-forum zu hören bekommen habe, es gibt dafür viel zu viele Protokolle.
Und... nun wirklich es sollte eigentlich *nicht* vorkommen können, das ein Interner Link wie ein Interner ausschaut.
Maximal, wenn man via Apache konfiguration eine URL woanders hinleiten lässt.
Dafür könnte man den Woraround anbieten, das

Code:

[:Link: beschreibung]

*immer* als externer Link gerenddert wird. (auch, wenn es da nicht wirklich einen großen Unterschied im rendern gibt.)

Jens wrote:

Listen
Meine Variante sollte weg, die sah so aus:

Code:

* liste stufe eins
** weiter eingerückte Liste
* wieder zurück eingerückte Liste
*** Liste Stufe drei (eine Stufe mehr, als die zweite)

Im Grunde sollte es so wie es Moin gemacht werden (Ist übersichtlicher):

Code:

* liste stufe eins
* weiter eingerückte Liste
* wieder zurück eingerückte Liste
* Liste Stufe drei (eine Stufe mehr, als die zweite)

Ebenfalls bereits in Wombat drinne. Zwar noch ein wenig experimentell, da hier und da nicht ganz alles funktioniert aber die Syntax ist die gleiche

Jens wrote:

Sourcecode
Sourcecode einbeziehen in die Seite möchte ich eigentlich so beibehalten wie es ist:

Code:

<code=css>
.xs {font-family:verdana,arial,helvetica,sans-serif;font-size: x-small}
.m {font-size: medium}
</code>

oder:

Code:

<code=.py>
for i in xrange(10):
print "Toll"
</code>

Also ich kann da einfach mal wieder von meiner Referenz Wombat erzählen.
Dort lesen wir ganz am Anfang die CSS-Datei(en) ein und speichern sie in einem Dictionary, direkt im Environment (währe bei pyLucid ungefair das Request-Objekt). Dort kann *jedes* Plugin und alle Bereiche, die zugriff auf das Request-Objekt haben darauf zugreifen und eigene CSS-Daten definieren. Dadurch, das es ein Dictionary ist, kann es zu keinen Überschneidungen kommen. (zumindest nicht im CSS-File)

Die Syntax ist ok, ich bevorzuge da aber auch die MoinMoin Syntax. Und als Definition, wie das hervorgehoben werden soll, dürfen *alle* Pygments bezeichner verwendet werden. Die werden ja einfach an Pygments weitergegeben und fertig.
Pygments sehe ich aber als optionale Bibliothek an, sodass wir genau wie Trac, wenn es nicht installiert ist, einfach den Text in einem formatierten '<pre>' Block zurückgeben und gut ist.

Die Frage zum HTML-Grundgerüst verstehe ich nicht.
Hat PyLucid nicht *eine* basis HTML-Datei, die als Basis für alle anderen genommen wird? (â la inheritance etc. ;) )
Im Allgemeinen würde ich das CSS-File direkt an eine URL /static/css/style.css binden. Die CSS wird dann eben entsprechend des Styles etc. verändert, wie oben beschrieben. So hat man für alle HTML-Templates einen direkten Ansprechpunkt.

Jens wrote:

Ist nicht so schwer. Dafür kann man endlich mal die Datenbank schön einsetzen ;)

Und umsetzbar ist es via ein Macro.

Macros
In Wombat gibt es verschiedene Macros. Bilder werden laut der definition oben wie normale Links definiert. Ist kein Problem, Wombat hat sie als Macro eingebunden is aba wie gesagt, pille palle :)

Im Allgemeinen, braucht PyLucid so etwas, wie Macros?
Ich denke ja, denn das währen ja "Befehle", die den LucidTags gleichkommen würden und Sachen wie den TOC etc. erstellen/einbinden könnten.
Ich würde gerne die '{{ LucidTag }}' definition rausschmeißen und diese ebenfalls von der MarkupEngine, als Macros behandeln lassen.
Nur, was für eine Definitionssyntax bekommen die?

bei Wombat werden sie so definiert:

Code:

#MACRONAME[ARGUMENTE]

Das ist eigentlich simpel und einprägsam. So kann man auch noch Argumente übergeben :)

So, und wenn das jetz wieder kein Roman war, weiß ich auch nicht ;)

jens
Administrator

Joined: 12 Oct 2005
Posts: 972
Location: duisburg, germany

Posted: Thu 14 Jun, 2007 11:19 Post subject:

EnTeQuAk wrote:

und mit Backticks (geht hier auf der Tastatur nicht :'( ) monospaced Text.

Backticks mag ich nicht so sehr... Ich kann mir nie merken welches ein Backtick und welches ein Hochkomma ist. Aber egal. Das kann ruhig rein ;)

EnTeQuAk wrote:

Jens wrote:

Links
Ich hatte mir mal sowas überlegt:

Code:

http://MeineSeite.de/_goto/SeitenShortcut
http://MeineSeite.de/_permalink/SeitenShortcut

Also das man im MarkupPaser einfach ein Prefix vorgeben kann und er so den Link zusammen setzt.

OK, das mit dem /_goto/ oder /_permalink/ war quatsch (s.unten).

Das überprüfen mit den Protokollen ist doch ganz einfach: (*.?)://(*.?) (Also nicht explitizt auf z.B. "ftp://" oder "http://" prüfen)

In PyLucid ist das mit den Links aber ein wenig komplizierter. Ich möchte ja möglicht ein Abbild einer Verzeichnis-Struktur in der URL nachbilden.
Es ist ja quasi ein Zwitter aus Wiki-Verfahren und Baumstruktur:
Jede Seite hat eine eindeutige Bezeichnung: Neben der ID ist das der sog. "Shortcut". Darüber kann man jede Seite direkt anspringen.
Auf der anderen Seite, werden die Shortcuts immer nach der Baum-Hirachie in der URL gebildet. Also z.B.:
Hirachie:

http://example.de/Seite1/

http://example.de/Seite1/Seite1-1/

http://example.de/Seite1/Seite1-2/

http://example.de/Seite1/Seite1-2/Seite1-2-1/

http://example.de/Seite1/Seite1-2/Seite1-2-2/

http://example.de/Seite2/

http://example.de/Seite2/Seite2-1/

http://example.de/Seite2/Seite2-2/

http://example.de/Seite2/Seite2-2/Seite2-2-1/

http://example.de/Seite2/Seite2-2/Seite2-2-2/

Alle Seiten sind aber auch direkt Adressierbar, damit man halt Wiki-Like Links in jede Seite bauen kann. Man braucht also nur den Shortcut einzubauen. Denn eigentlich wird immer nur der letzte Teil der URL benutzt. Also funktionieren diese URLs genau so wie in der obrigen Liste:

http://example.de/Seite1/

http://example.de/Seite1-1/

http://example.de/Seite1-2/

http://example.de/Seite1-2-1/

http://example.de/Seite1-2-2/

http://example.de/Seite2/

http://example.de/Seite2-1/

http://example.de/Seite2-2/

http://example.de/Seite2-2-1/

http://example.de/Seite2-2-2/

Klar könnte man auch, wenn der User z.B. [Seite1-2-2] eingibt daraus dann den vollen Link http://example.de/Seite1/Seite1-2/Seite1-2-2/ generieren lassen. Aber z.Z. ist das mit sehr viel DB-Interaktion verbunden :( Liegt am verwendeten Parent-Modell. Ein Caching des Hirachie-Links könnte da helfen.
Aber wie dem auch sei: Der Markup Parser müsste in dem Falle irgendwie an diese Links-Informationen kommen. Das könnte man irgendwie über eine call-back Funktion lösen. Ist aber IMHO alles zuviel Aufwand.
Ich meine, wenn man sagt [Seite1-2-2] wird einfach zu <a href="/Seite1-2-2/"> ist das ruck zuck gemacht. Ganz ohne DB Abfragen...
Wenn der Shortcut ungültig ist, führt der Link zu einem 404 Fehler. OK, man könnte mit einem call-back das prüfen, aber muß das wirklich sein?

EnTeQuAk wrote:

Du wirst Lachen, aber sehr sehr ähnlich ist das auch mittlerweile in PyLucid gemacht ;)
Das ist nicht im Request-Obnjekt, sondern im context-dict:

Code:

self.context["css_data"].append({
"from_info": "tinyTextile",
"data": stylesheet,
})

Es gibt auch statt "css_data" ein "js_data"... Die Inhalte werden zum Schluß ins Template ganz normal mit der django Engine eingebaut. Das sieht dann so aus:

Code:

{% if js_data %}
{% for js in js_data %}
<script type="text/javascript">
/* <![CDATA[ */
/* additional javascript from {{ js.from_info }} */
{{ js.data }}
/* ]]> */
</script>
{% endfor %}
{% endif %}

{% if css_data %}
{% for css in css_data %}
<style type="text/css">
/* <![CDATA[ */
/* additional stylesheets from {{ css.from_info }} */
{{ css.data }}
/* ]]> */
</style>
{% endfor %}
{% endif %}

Pygments sehe ich auch als optional an... z.Z. mache ich das so:
http://trac.pylucid.net/browser/branches/0.8%28django%29/PyLucid/system/tinyTextile.py?rev=1042#L353
Schau mal rein, dann siehtst du auch was ich mit zusätzlichen html-Code meine, nämlich das:

Code:

code = (
'<fieldset class="pygments_code">'
'<legend class="pygments_code">%(lexer_name)s</legend>'
'%(sourcecode)s'
'</fieldset>'
) % {
"lexer_name": lexer_name,
"sourcecode": sourcecode,
}

EnTeQuAk wrote:

Jens wrote:

TOC

Ist nicht so schwer. Dafür kann man endlich mal die Datenbank schön einsetzen ;)

Und umsetzbar ist es via ein Macro.

Wieso Macro??? Das sollte vollkommen von Globby erledigt werden. Wozu da DB-Abfragen einbauen?

Generell zu den Lucid-Tag Geschichten: Diese sind total obsolete. Ich nutzte da komplett die django-Engine für, siehe:
http://trac.pylucid.net/browser/branches/0.8%28django%29/PyLucid/defaulttags/lucidTag.py?rev=1042
und
http://pylucid.org/phpBB2/viewtopic.php?p=625#625
_________________

http://www.jensdiemer.de | http://www.htfx.de | http://www.python-forum.de

EnTeQuAk

Joined: 22 Nov 2006
Posts: 171
Location: Berlin

Posted: Thu 14 Jun, 2007 11:55 Post subject:

Quote:

Es ist ja quasi ein Zwitter aus Wiki-Verfahren und Baumstruktur:

Und aus welchem Grund ist das so, wenn ich mal fragen darf?

Quote:

Du wirst Lachen, aber sehr sehr ähnlich ist das auch mittlerweile in PyLucid gemacht ;)
Das ist nicht im Request-Obnjekt, sondern im context-dict:

Gut, dann werde ich hier nicht meckern.
Aber das wird ja alles direkt ins Ausgabe Template (also direkt in den HTML-Code) geschrieben. Das ist unschön. Nein, das ist blöd!

Quote:

Schau mal rein, dann siehtst du auch was ich mit zusätzlichen html-Code meine, nämlich das:

War das irgentwo als Problem gemeldet? Ansonsten ist das ja kein Problem, wird ja so oder so direkt mit dem Markup-Tag ersetzt.

Quote:

Wieso Macro??? Das sollte vollkommen von Globby erledigt werden. Wozu da DB-Abfragen einbauen?

Macros sind (in meinen Augen) Geschichten, die zusätzliche Features einbauen. Genau das gleiche, wie die LucidTags. Nur halt, das mir der Name Macros besser gefällt.
Macros stellen sozusagen eine Verbindung zwischen Kern und der Seite her. So ließe sich die TOC einbauen, und viele andere schöne Sachen.
(halt wie gesagt: es ist nur ein anderer Name. Du nutzt dafür den Namen LucidTags)

jens
Administrator

Joined: 12 Oct 2005
Posts: 972
Location: duisburg, germany

Posted: Thu 14 Jun, 2007 12:27 Post subject:

EnTeQuAk wrote:

Quote:

Es ist ja quasi ein Zwitter aus Wiki-Verfahren und Baumstruktur:

Und aus welchem Grund ist das so, wenn ich mal fragen darf?

Das hat mehrere Vorteile:

1. Man kann Seiten statt nur mit der ID mit einem Namen Adressieren. So könnte man Permanent-Links anbieten.

2. Wenn man die Seiten Struktur (die Hirachie) ändert, die Seite aber den selben Shortcut hat, funktionieren Links aber immer noch ;)
ein Beispiel: Der richtige Link ist eigentlich: http://pylucid.de/ExamplePages/Contact/ Es geht aber auch http://pylucid.de/XXX/Contact/ oder http://pylucid.de/1/2/3/Contact/

3. Da die Shortcuts immer URL-Safe sind, brauch man kein Escaping zu machen und kann dennoch einen Kryptischen Seitennamen wählen. OK, Seitennamen mit Sonderzeichen kann man mit urllib.quote() auch behandeln, aber dann hat man super lange Kryptische URLs...
z.B. hatte ich eine Seite die hieß "<lucidTag:search/>". Mit quote, sieht das dann so aus: "%3ClucidTag%3Asearch/%3E" Mit dem Shortcut sieht es so aus: "LucidTagSearch"...
Siehe:
http://pylucid.org/index.py/Documentation/LucidTagLucidFunction/LucidTagS/LucidTagSearch/

Das Automatische Generieren des Shortcuts aus dem Seitennamen ist z.Z. aber noch nicht fertig. Die alte Variante sieht aber so aus:
http://trac.pylucid.net/browser/trunk/PyLucid/system/tools.py?rev=989#L142

Der Shortcut wird also Automatisch aus dem Seitennamen erzeugt und mit einer Nummer versehen, falls es den Namen schon gibt. Man kann aber auch selber den Text bestimmten ;)

EnTeQuAk wrote:

Quote:

Du wirst Lachen, aber sehr sehr ähnlich ist das auch mittlerweile in PyLucid gemacht ;)
Das ist nicht im Request-Obnjekt, sondern im context-dict:

Gut, dann werde ich hier nicht meckern.
Aber das wird ja alles direkt ins Ausgabe Template (also direkt in den HTML-Code) geschrieben. Das ist unschön. Nein, das ist blöd!

Ja, aber wie sonst machen??? Die Daten liegen in der DB. Wenn man sie durch z.B. das Hauptstyle <link rel="stylesheet" type="text/css" href="/index.py/_command/1/page_style/sendStyle/main.css" /> Dann sind das immer extra Requests, die zusätzliche Last bedeuten.
So hat man zwar einen höheren Traffic, aber weniger Last, was IMHO besser ist.

Man sollte die Dateien nur dann extern einbinden, wenn diese auf Platte liegen und von Apache ausgeliefert werden können. Dann macht das Sinn.

Die Stylesheets von Pygments müsste man also auch auf Platte bringen.
_________________

http://www.jensdiemer.de | http://www.htfx.de | http://www.python-forum.de

EnTeQuAk

Joined: 22 Nov 2006
Posts: 171
Location: Berlin

Posted: Thu 14 Jun, 2007 12:56 Post subject:

Quote:

Hmm... da hast du recht. Ich werde trotzdem mal drüber nachdenken, wie das anders zu lösen ist. Muss ja nicht gleich morgen sein.

Wegen der Baumstruktur:
Ich wollte eigentlich auf etwas anderes hinaus.

Wozu braucht man zwei oder drei URLs, für *eine* Seite?
Warum nicht wie bei fast jedem anderen CMS, wie bei MoinMoin etc. und einfach *nur* den Seitennamen als URL nehmen.
Man kann maximal noch wie bei MoinMoin Kategorien einführen.

Oder reden wir grad aneinander vorbei?

MfG EnTeQuAk

jens
Administrator

Joined: 12 Oct 2005
Posts: 972
Location: duisburg, germany

Posted: Thu 14 Jun, 2007 13:15 Post subject:

EnTeQuAk wrote:

Wozu braucht man zwei oder drei URLs, für *eine* Seite?
Warum nicht wie bei fast jedem anderen CMS, wie bei MoinMoin etc. und einfach *nur* den Seitennamen als URL nehmen.

Naja, der einfachste Weg ist zweifellos: example.com?page=12 Aber das sieht extrem unschön aus ;)

Ich möchte einfach schöne URLs haben. Da ist es doch auch schön, wenn die Hirachie der Seiten sich in der URL wiederspiegelt.

Auf der anderen Seite ist PyLucid aber robuster, wenn sich die Hirachie mal ändert, weil im Hintergrund eben nur der letzte Teil einer URL ausgewertet wird.

Und die ganze Baum Geschichte über Board zu werfen möchte ich nicht. Denn dann hab ich ja mehr oder weniger ein Chaotisches Wiki ;)
_________________

http://www.jensdiemer.de | http://www.htfx.de | http://www.python-forum.de

EnTeQuAk

Joined: 22 Nov 2006
Posts: 171
Location: Berlin

Posted: Thu 14 Jun, 2007 14:40 Post subject:

Quote:

Denn dann hab ich ja mehr oder weniger ein Chaotisches Wiki ;)

Wobei du da ja auch recht hast :)

Quote:

Naja, der einfachste Weg ist zweifellos: example.com?page=12 Aber das sieht extrem unschön aus ;)

Sag das nicht! --> Du must die Zahlen auch erstmal einer Seite zuordnen. Ist im prinziep genauso aufwendig, als wenn du dir "ein chaotisches Wiki" erstellst. :)

Quote:

Ich möchte einfach schöne URLs haben. Da ist es doch auch schön, wenn die Hirachie der Seiten sich in der URL wiederspiegelt.

Was mich hier noch ein wenig interessiert:
Was exakt meinst du mit Hirachrie?

Klar, brauchst mir jetzt nicht mir den URL-Beispielen kommen, die kenne ich. Aber... ist das u.A die Hirarchie vom Menü oder in welchen Hintergründen benötigst du die Hirarchien? (wobei das ganze im prinziep auch das gleiche ist, was ich mit den Kategorien meinte *g* --> interessiert mich aber trotzdem mal)

(ich will das ganze System jetz nicht anzweifeln. Bin nur halt neugierig *g*)

MfG EnTeQuAk

jens
Administrator

Joined: 12 Oct 2005
Posts: 972
Location: duisburg, germany

Posted: Thu 14 Jun, 2007 14:55 Post subject:

Mit Hirachie meine ich nur, das alle Seiten in einem Baum sortiert sind. Daraus ergibt sich das Menü und das Sitemap... Momentan benutzt ich dazu ein einfaches Parent-Modell... Siehe Thread im Python-Forum ;) _________________ http://www.jensdiemer.de \| http://www.htfx.de \| http://www.python-forum.de

EnTeQuAk

Joined: 22 Nov 2006
Posts: 171
Location: Berlin

Posted: Sat 07 Jul, 2007 16:56 Post subject:

Ich hätte noch zwei Fragen:

Code

Code:

<code=id>
isch bin code
</code>

'id' entspricht hierbei *jeglicher* Id, die Pygments erkennt. Das macht es für uns einfacher und ich finde auch für den Benutzer gibts keine Unterschied.

Aber Pygments kennt noch das Attribut, eines Styles, in welchem der Code dargestellt werden soll.
Soll der global definiert werden, via Konfiguration oder soll der via <code> Tag auswählbar sein?

Newlines
In Globby handlen wir das so, das optisch *jeder* Zeilenumbruch dargestellt wird. Intern wird das mit <p></p> und <br /> tags realisiert und klappt gut.
Möchtest du das für tinyTextile auch so?
Oder z.B., wie MoinMoin, nur paragraphen erkennen und der Benutzer muss zusätzliche <br /> per hand (via [[BR]]) einfügen?

Ich bin für ersteres, da es den Text im Enddefekt übersichtlicher hält und das Ergebnis besser abschätzen lässt.

Das waren sie, die beiden Fragen Wink

MfG EnTeQuAk

jens
Administrator

Joined: 12 Oct 2005
Posts: 972
Location: duisburg, germany

Posted: Sat 07 Jul, 2007 19:22 Post subject:

Die Pygments Frage ist mir noch nicht ganz klar Was meinst du genau? Zu den <br /> Tags... Auf jeden Fall die erste Variante. Ich finde das Moin Verhalten nicht sehr gut _________________ http://www.jensdiemer.de \| http://www.htfx.de \| http://www.python-forum.de

EnTeQuAk

Joined: 22 Nov 2006
Posts: 171
Location: Berlin

Posted: Sun 08 Jul, 2007 07:00 Post subject:

jens wrote:

Die Pygments Frage ist mir noch nicht ganz klar Smile Was meinst du genau?

http://pygments.org/docs/styles/
http://trac.pocoo.org/browser/pygments/trunk/pygments/styles

Es gibt also verschiedene Styles, die das Endergebnis des Hervorgehobenen Quellcodes optisch verändern.

Das währen: manni, perldoc, borland, colorful, default, murphy, trac, fruity, autumn, emacs, pastie, friendly, native.

Tio Wink

In Globby ist das via globale Konfiguration möglich, das Style einzustellen. Soll das bei PyLucid auch so sein?

MfG EnTeQuAk

jens
Administrator

Joined: 12 Oct 2005
Posts: 972
Location: duisburg, germany

Posted: Mon 09 Jul, 2007 07:35 Post subject:

Jetzt verstehe ich was du meinst... PyLucid kann das in den Preferences speichern, welches Style genommen werden soll. Die Frage ist, wer übernimmt überhaupt das Hightlighting von Code??? Denn dabei muß ja auch das Stylesheet in die Seite eingebaut werden, damit man überhaupt was sieht Da sollten wir also am besten mit einem callback arbeiten. Also PyLucid schmeißt den Markup-Paser an und übergibt dabei eine Funktion der das Sourcecode übernimmt und durch pygments jagt und das Ergebnis wieder zurück schickt. Oder wie hast du dir das gedacht? _________________ http://www.jensdiemer.de \| http://www.htfx.de \| http://www.python-forum.de

Display posts from previous:

	PyLucid - CMS - Forum Forum Index -> system	All times are GMT + 1 Hour Goto page 1, 2 Next
Page 1 of 2

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

<< back to PyLucid CMS Homepage