Es gibt eine aktualisierte Version von PyLucid v0.9.0.RC5.git-87dd033

download unter:

Die normale Source Distribution is auch auf PiPy: http://pypi.python.org/pypi/PyLucid/0.9.0.RC5.git-87dd033

In Anlehnung an dem vorherigen Blog Post git repository aufzuteilen hab ich mir ein bash Skript geschrieben, um ein Plugin aus http://github.com/jedie/PyLucid-Plugins in ein seperates Repository zu clonen:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

#!/bin/bash

PLUGIN=DecodeUnicode

function verbose_eval {
    echo - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    echo $*
    echo - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    eval $*
    echo ---------------------------------------------------------------------
    echo
}

DEST_DIR=PyLucid-${PLUGIN}-plugin

echo "dest dir: ${DEST_DIR}"

if [ -e ${DEST_DIR} ]; then
    echo "Destination directory exist, abort."
    exit 1
fi

verbose_eval git clone git@github.com:jedie/PyLucid-Plugins.git ${DEST_DIR}
#~ verbose_eval git clone --no-hardlinks ~/workspace/PyLucid-Plugins ${DEST_DIR}


cd ${DEST_DIR}

OTHERS=""
for I in * ; do
    if [ "$I" != "${PLUGIN}" ] ; then
        OTHERS+=" $I"
    fi
done

echo "Remove all other directories from git history"
verbose_eval git filter-branch --index-filter \"git rm -r -f --cached --ignore-unmatch ${OTHERS}\" --prune-empty HEAD

verbose_eval git reset --hard
verbose_eval git remote rm origin
verbose_eval rm -r .git/refs/original/
verbose_eval git reflog expire --expire=now --all
verbose_eval git gc --aggressive
verbose_eval git prune
verbose_eval git remote add origin git@github.com:jedie/${DEST_DIR}.git
verbose_eval git config --list

echo "If everything is ok, do this:"
echo "git push origin master"

Das Prinzip:

1. Es wird ein clone vom original Repository erzeugt (Zeile 23 bzw. 24)
2. Alles, außer ein Unterverzeichnis wird aus der git History gelöscht (Zeile 29-37)
3. Es wird eine neue origin URL eingetragen (Zeile 39-46)

Es gibt nun die erste Version des "standalone" Pakets von PyLucid. Den kann man nutzten, wenn man keinen shell Account hat. Denn im "standalone" Archiv ist alles vorhanden, was man braucht, man muß kein virtuelenv erstellen.
Die installation erfolgt über das Web mit einem einfachen CGI-Skript.
Einfach auspacken, per FTP auf den Server kopieren und log geht's.

Im groben läuft es so ab:

1. Download: https://sourceforge.net/projects/pylucid/files/PyLucid_standalone_0-9-0-RC3-git-fbba4c7.7z/download
2. Mit 7-Zip entpacken
3. local_settings.py anlegen, siehe: Beispiel
4. 'default.htaccess' nach '.htaccess' umbenennen und anpassen
5. alles per FTP auf den Webspace packen
6. Installations Seite aufrufen, bsp: deine_domain.tld/install_pylucid.cgi
7. Die ersten drei Punkte von oben nach unten durch gehen: "syncdb", "create superuser" und "loaddata"
8. ganz wichtig: install_pylucid.cgi löschen! (Ansonsten können andere Leute sich einen Account machen!!!)
9. Fertig!

Es liegt auch eine manage.py dabei, somit kann man auch einfach lokal den Django Developer-Server starten:

1

~PyLucid_standalone$ ./manage.py runserver

mehr info: install PyLucid standalone package

Ich hab ein HowTo geschrieben, wie man django-weave in PyLucid mit einem kleinen "glue Plugin" einbinden kann:

• http://www.pylucid.org/permalink/324/howto-support-the-django-weave-app (en)

Django-Weave ist eine "reuseable" Django Applikation, ein Mozilla Labs Weave Server für Django.

Ich hab vom neuen Firefox 'weave' Addon gehört. Dabei dachte ich mir, das es wirklich nett wäre, wenn ein PyLucid Plugin als Server dienen könnte.

Ich habe ein Plugin angefangen: http://trac.pylucid.net/browser/PyLucidPlugins/weave/
Das speichern von Daten geht schon. Aber es ist noch in einem sehr frühem Entwicklungsstadium, noch weint entfernt das man es produktiv nutzten könnte.

Ich hatte zuerst mal gesucht, ob es schon Python implementierungen gibt und bin darauf gestoßen:

• http://majid.info/blog/just-enough-weave/

Das Skript habe ich zum testen modifiziert, sodas es viele Ausgaben ausspuckt. So kann man protokollieren, was 'weave' so macht.

Mehr Informationen im Forum: http://forum.pylucid.org/viewtopic.php?t=313 (en)

Ich hab mit Changeset 2500 die alte HeadlineAnchorMiddleware wieder aktiviert, die jede html Überschrift mit einem permalink und Anker versieht. Außerdem habe ich das neue TOC plugin beigepackt. Damit kann man automatisch eine "Table of Contens" liste erstellen.

Mehr Informationen hier: TOC plugin documentation.

Mit dem neuen Plugin kann man recht einfach eine OpenStreetMap direkt in die eigene Seite einbinden.

Mehr Informationen dazu hier: PyLucid OpenStreetMap Plugin

In der alten PyLucid v0.8 gab es schon die möglichkeit das markup einer Seite zu konvertieren. Nun gibt es das auch wieder in PyLucid v0.9 ;)

Man kann alle verfügbaren Markups (html, tinyTextil bzw. original Textile, markdown und ReSt) in html oder creole konvertieren. Und so sieht es aus:

(Auf das Bild klicken für große Ansicht)

Nicht immer klappt das konvertieren Verlustlos. Schließlich kann man in html wesentlich mehr Abbilden als in creole markup. Damit man besser sehen kann, ob es verluste gibt, kann man den "Verbose Mode" einschalten und sieht dann ein Diff des html Codes. Es wird einmal der html code mit dem original markup generiert und dann mit dem html code verglichen, der aus dem konvertierten markup entsteht. Das ganze sieht dann so aus:

(Auf das Bild klicken für große Ansicht)

↑ Links  #

• http://code.google.com/p/python-creole/
• http://trac.pylucid.net/changeset/2477

Der eigentliche Fehler ist oft schnell gefunden. Die Lösung bzw. das Aufspüren des Ursprünglichen Problems dauert meist länger. So auch in diesem Falle.

Erst gestern hatte ich den neuen PyLucid bulk editor programmiert. So sieht's aus:

Bild in 100% größe

Das Problem: Wenn man ein django-tagging Feld bearbeitet, wurden die Tags nicht richtig aktualisiert.

Im bulk editor arbeite ich mit modelformset_factory(). Zuerst dachte ich, das ich irgendwie save_m2m() vergessen hatte. Da mir nicht sofort klar war, wie save_m2m() eigentlich zu benutzten war, habe ich erstmal Zeit damit verschwendet das heraus zu bekommen.

formset.save_m2m() ist erst dann verfügbar, wenn man formset.save(commit=False) macht. Und so kann man das Beispielsweise machen:

1
2
3

instances = formset.save(commit=False) # instances ist eine Liste der geänderten Objekte.
formset.save_m2m()
formset.save()

btw. "commit=False" ist auch interessant, wenn man vor dem eigentlichen Speichern die Objekte nochmal ändern möchte. z.B. ein update timestamp mitgeben...

Zurück zu meinem Tagging Feld Problem: An einem fehlenden save_m2m() lag es allerdings dann doch nicht. Erst nach dem ich einen unittest für tagging schrieb, ist mir das aufgefallen.

Das eigentliche Problem: Man darf das Quellen queryset nicht mit einem .only() einschränken. Denn genau das hatte ich im bulk editor gemacht. Die Idee dahinter: Was soll man alle Felder aus der Datenbank holen, wenn man eh nur eins anzeigen und verändern möchte??? Mit einem .only() spart man halt Ressourcen ein und das im Zeitalter der Klimaerwärmung ;)

Ein .only() klappt hingehen bei allen anderen Feldern, nur nicht beim tagging TagField :(

Man muß wissen, das ein TagField eigentlich ein normales CharField ist und kein m2m. Die Tags werden quasi doppelt gespeichert: Einmal als normalen String im CharField des getaggten Model. Und einmal in den internen tagging Modellen, die von Tagging selber verwaltet werden: tagging.models.Tag und tagging.models.TaggedItem
Das ganze dient natürlich zur Performance Steigerung...

Wenn man also das Formset mit einem queryset = queryset.only("tags") füttert, passiert das: Der Tag String im CharField wird geändert. Die internen tagging Tabellen allerdings nicht (auch mit formset.save_m2m() nicht)! Aber diese werden i.d.R. herangezogen wenn man auf das TagField zugreift.

Nun ist die Frage: Wer hat Schuld?

↑ Links  #

• Monolog im Python-Forum
• Gemeldeter tagging Bug #227
• Tagging unittest zum nachprüfen: tagging_formset_m2m_test.diff

Mit changeset:2465 kann man wieder die Reihenfolge der Menü Einträge auf bequeme Weise ändern.

So kann man updaten:

• Update PyLucid mit: svn up PyLucid09/PyLucid_env/src/pylucid/pylucid_project/
• Wenn du fastCGI benutzt kannst du ein "reload" so veranlassen: touch index.fcgi

Nach dem Update gibt es unter "edit page" den neuen Punkt "change page order" (Für die User, die PageTree verändern dürfen).

Das ganze sieht dann sehr ähnlich aus zu der v0.8 Lösung.

EDIT:
Hier ein Screenshot, mit Erklärungen:
http://www.flickr.com/photos/jensdiemer/4152920434/