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/

Ich hab heute PyLucid v0.8.7 fertig gemacht.

Im "Full package" ist ein neuere Version von django enthalten, nicht nicht mehr die kürzlich entdeckte django forms Sicherheitslücke enthält!

Wer nur schnell seine Installation von dem Sicherheitsleck befeien will, braucht eigentlich nur zwei zeilen in eine Datei ändern. Nähre Informationen dazu im PyLucid Blog Artikel "django security vulnerability"

PyLucid v0.8.7 beinhaltet in der lite Version:

• TinyMCE Revision 1250
• python-creole Revision 39

...und im "Full package":

• django trunk Revision 11624
• pygments

↑ Download:  #

• PyLucid_v0.8.7full.zip
• PyLucid_v0.8.7lite.zip

↑ Update info  #

Wer seine installation Updaten möchte, muß in der settings.py eine kleine Änderung vornehmen, siehe:
http://www.pylucid.org/_goto/108/update-PyLucid/#update-to-v0-8-7

Von Haiku gibt es eine erste Alpha. Haiku basiert auf BeOS und BeOS war ja eigentlich sehr nett.

Ich hab es mal in VirtualBox mit den Images für VMWare probiert. Es läuft ohne Probleme und recht flüssig, auch ohne VirtualBox Addons.

Python 2.6.2 ist auch mit dabei ;)

Edit: Damit Netzwerk funktioniert, habe ich die virtuelle Karte "Intel PRO/1000 MT Desktop (82540EM)" gewählt. Die wird von Haiku erkannt und unterstützt.

Edit2: Da Python eh schon dabei ist und es SVN als sog. "Optional Packages" gibt, hab ich mir gedacht, probiere ich mal PyLucid zu "installieren" ;)

Allerings ist auf der VM Platte nicht genug Speicher frei. Also einfach die mitgelieferte blank-bfs-2048mb.vmdk als zweite Platte einhängen und dann darauf alles machen.

Also folgende Schritte habe ich gemacht:

• subversion Optional Packages gezogen, von: http://haiku-files.org/files/optional-packages/
• Auspacken nach /boot
• Klick auf "Deskbar" und mit Mount/Mount All die zweite VM Platte mounten.
• Terminal öffnen
• auf zweite Platte wechseln mit "cd /Blank_BFS"
• PyLucid installieren, wie hier beschrieben: http://www.pylucid.org/_goto/186/v0-9-testing/
• der Hardlink von manage.sh funktionierte nicht, also das machen:

  cp manage.sh ../PyLucid_env/

Und als Beweis:

http://www.flickr.com/photos/jensdiemer/3922670822/

↑ Links  #

• http://www.pro-linux.de/news/2009/14695.html
• http://www.golem.de/0909/69793.html
• http://www.haiku-os.org/
• http://www.haiku-os.org/get-haiku
• http://haiku-files.org/
• http://www.haiku-os.org/slideshows/haiku-tour
• Crosspost: http://www.python-forum.de/topic-20221.html

Es gibt eine öffentliche Testseite, der aktuellen alpha version von PyLucid v0.9:

http://www.pylucid.de/

Ihr könnt es selber ausprobieren. Einfach einloggen als superuser:

• Username: test
• Password: 12345678

Einfach einloggen und ein wenig spielen. Wir resetten die Seite hin und wieder.

Hinweis: Die Seite läuft erstmal nur mit CGI und komplett ohne Caching. Die Perfomance ist somit schlecht.

Feedback willkommen, siehe: Kontakt Seite (en).

Wer selber eine eigene Test Umgebung bauen möchte, sollte sich die Seiten ansehen:

• v0.9 testing (en)
• test v0.9 with CGI (en)

In Django kann man mit UserProfiles für jeden User Daten speichern.

Für PyLucid brauche ich da aber was flexibleres. Jeder Plugin soll auf einfacher weise User spezifische Einstellungen speichern können.

Im meinem Projekt django-dbpreferences existierte bisher die Möglichkeit Einstellungen anhand von ein oder mehreren Forms zu speichern. Das ist schon recht flexibel und bequem, weil man im Prinzip nur eine Form definieren muß und fertig. Allerdings werden die Werte nicht mit dem User verknüpft. Somit eignet es sich nur für Projekt übergreifende Einstellungen, die man nicht in der settings definieren muß.

Die neue Komponente, "UserSettings" genannt, arbeitet ohne forms. Somit muß eine andere Instanz für die Validierung sorgen. Im Grunde ist es auch recht einfach gestrickt: Es wird einfach ein dict serialisiert pro User gespeichern und fertig.

Gedacht ist das für alle Einstellungen, die pro User vorgenommen werden können. Ein Beispiel: Beim schreiben eines neuen Blog Artikels kann man im PyLucid Plugin Markups auswählen. Jeder User sollte also sein bevorzugtes Markup voreingestellt haben. Also warum nicht einfach das letzte Benutze Markup für jeden User speichern?

Mit UserSettings geht das super einfach, ungefähr so:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

def create_blog_article(request):
    """
    Use a user settings in a form as initial value.
    If the value was set in the past, this value would be used as initial value.
    So, the form has allways the last used user value ;)
    """
    if request.method == 'POST':
        form = BlogArticleForm(request.POST)
        if form.is_valid():
            # ...
            # Speicher das wirklich genutzte Markup, für später:
            request.user_settings["markup"] = form.cleaned_data["markup"]
            # ...
            return HttpResponseRedirect('/saved/')
    else:
        # Nutzte das zuletzt genutzte Markup. Wenn es kein's gibt, dann wird "creole" genommen
        form = BlogArticleForm(initial={"markup": request.user_settings.get("markup", "creole"})

    return render_to_response('create_blog_article.html', {'form': form})

Um UserSettings zu benutzten, muß man im Prinzip nur eine Middelware einbinden:

1
2
3
4
5
6

MIDDLEWARE_CLASSES = (
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    #...
    'dbpreferences.middleware.DBPreferencesMiddleware',
)

Die DBPreferencesMiddleware packt am Anfang bei process_request() das Objekt "user_settings" an's request Objekt. Am Ende in process_response() werden geänderte Daten automatisch gespeichert.

Damit das ganze schön schnell ist, wird ein einfaches, aber effektives Caching verwendet.

↑ Links  #

• Projekt Webseite: http://code.google.com/p/django-dbpreferences/
• Beispiel: http://code.google.com/p/django-dbpreferences/wiki/UserSettings_example
• PyPi Eintrag: http://pypi.python.org/pypi/django-dbpreferences/

In PyLucid v0.9 werden wir die django user permissions nutzten. (Bisher haben wir nur is_staff und is_superuser genutzt).

Leider ist die django Doku über die user permissions recht dünn, es gibt kein richtiges Beispiel, außer:

1
2
3
4
5
6
7
8

myuser.groups = [group_list]
myuser.groups.add(group, group, ...)
myuser.groups.remove(group, group, ...)
myuser.groups.clear()
myuser.user_permissions = [permission_list]
myuser.user_permissions.add(permission, permission, ...)
myuser.user_permissions.remove(permission, permission, ...)
myuser.user_permissions.clear()

Da user.has_perm() Strings in Form von "<application name>.<lowercased model name>" entgegen nimmt, dachte ich einfach das es bei myuser.user_permissions.add() auch so sein kann.

Erst nach dem ich einen unittest geschrieben hat, zeigte sich, das keine permissions gesetzt werden. Das fatale: Es kommt leider nicht zu einem Traceback :(

Nach langem rumrätseln habe ich die richtige vorgehensweise aus /contrib/auth/tests/auth_backends.py entnehmen können:

1
2
3

content_type=ContentType.objects.get_for_model(MyModelClass)
perm = Permission.objects.get(content_type=content_type, codename="change_mymodel")
user.user_permissions.add(perm)

Danach klappten auch die PyLucid v0.9 Unittests: http://trac.pylucid.net/changeset/2043

Bleibt das Problem, das bei einem myuser.user_permissions.add("Ein String) kein Traceback ausgelöst wird???
Entweder ist das ein Bug, oder ein Fall für: http://code.djangoproject.com/wiki/BetterErrorMessages

Siehe auch:

• Python Forum Thead "django: user.user_permissions.add will nicht?!?!"

Nett, bei sourceforge gibt es neuerdings die sog. Hosted Apps. Das sind u.a. Trac und phpBB.

Leider kann man aber die Daten eines bestehenden phpBB nicht importieren, siehe: http://apps.sourceforge.net/ideatorrent/sourceforge/ideatorrent/idea/7/
Somit bleibt das phpBB für PyLucid erstmal so wie es ist.

Eine recht simple Lösung, hat Martin in seinem Blog vorgestellt:

1

{{ entry.published|date:_("DATETIME_FORMAT") }}

Neben DATETIME_FORMAT gibt es noch: DATE_FORMAT, DATETIME_FORMAT, TIME_FORMAT, YEAR_MONTH_FORMAT und MONTH_DAY_FORMAT

Mehr Info's zum Thema: http://www.mahner.org/weblog/automatisch-lokalisierte-zeitformatierungen/

Sollte ich mal in PyLucid überall nutzten: http://trac.pylucid.net/ticket/261 ;)

Mit PyLucid v0.9 wollen wir von Null anfangen, mal wieder ;)

PyLucid soll i18n auch bei den CMS Inhalten bekommen. Das bisherige Datenbankmodell passt dafür natürlich nicht.
Der Plan für v0.9 soll auch sein, noch näher an django herran zu rücken. u.a. Aufsplittung in mehrere kleinere Apps. Das Plugin System wird wohl auch anders ablaufen...

Es wäre jetzt also ein guter Zeitpunkt mit zu machen. Wir möchten gern unser Team vergrößern und brauch immer Hilfe...

Wer Lust hat, bitte melden:

• im Forum: http://www.pylucid.org/phpBB2/
• im IRC: #pylucid auf freenode.net
• Jabber: pylucid@conference.jabber.org (besser IRC ;) )
• http://groups.google.com/group/PyLucid-general (recht verstaubt)

Seid django changeset 8805 werden mit django.models.BaseModelForm.validate_unique() geprüft ob unique Fehler evtl. in der Datenbank schon existieren. Das ist hilfreich, wenn man neue Datensätze anlegen will. Es stört allerdings, wenn man das nicht tun möchte.
z.B. soll hier nur ein Username eingegeben werden später wird geprüft ob dieser existiert:

1
2
3
4
5
6
7

from django import forms
from django.contrib.auth.models import User

class UsernameForm(forms.ModelForm):
    class Meta:
        model = User
        fields=("username",)

So funktioniert das allerdings nicht, es gibt einen Form Fehler, wenn man diese Form mit einem existierenden Usernamen validieren würde: User with this Username already exists.

Es liegt an validate_unique(). Also müßen wir diese Prüfung irgendwie ausschalten. Meine Lösung z.Z. sieht so aus:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

from django import forms
from django.contrib.auth.models import User


class UsernameForm(forms.ModelForm):



    def validate_unique(self):
        # Keine unique Prüfung
        pass


    class Meta:
        model = User
        fields=("username",)

Andere Möglichkeit wäre es kein ModelForm zu nutzten, sondern die Form selber zu erstellen. Das hatte ich in PyLucid auch getan. Ich finde aber die neue Lösung besser, weil man z.B. bei der ModelForm auch die help_text Daten hat.

siehe auch http://www.python-forum.de/topic-16000.html